XS2 SPI slave booting

[choskin]

We have an dual tile xCORE-200 on a board that needs to be SPI booted by our mainframe for compatibility with our firmware updating system. The xCORE is hardware set to mode 2 "SPI slave, tile 1 channel end 0 boot". I am wondering how one generates the boot image to load in. I'm assuming xflash is the tool to take the .xe to a binary image using the --outfile option, but how does one tell it to build a flashless boot image? The project's .xn file seems to only take either a 'bootFlash' or 'LINK' option , the first which requires a description of the (nonexistent) external flash device attached. Other than the one paragraph in the device data sheet I've not been able to find any other information on the slave SPI boot mode of the XS2 parts, so I'm sure I'm missing some key concept here. Also, do I need to wrap the generated binary with the word length and CRC32 or is that generated automatically?

Thanks

[infiniteimprobability]

Hi, in short I'm afraid this is quite complex. Whereas SPI master boot is very well supported by the tools, SPI slave has only basic support. The boot process for a multi-tile device is quite complex and goes something like this:

There's a first stage bootloader in ROM (set by mode pins) which loads in the second stage bootloader which is provided by the tools as part of the xe binary. The Second stage bootloader sets up the hardware (registers, PLL etc.) and also sets up the switch in case there are other cores (bootees) that need to be communicated with and have thier image sent. This network is described by the xn file. The second stage bootloader needs to fetch and pass on images for all of the bootees, which in turn may also need to pass on further images (where there are more nodes/tiles present). FInally, it loads it's own image and then branches to it. All other tiles branch to their image too and they should all be ready to run and communicate.

To do this, the second stage bootloader needs to be master of the storage device to get bootee images as needed, which is all handshaken. All of this complexity is hidden in SPI master mode by the tools and a custom second stage bootloader is generated for you.

Doing something like is tricky when you are the slave..without some sort of protocol which hasn't been developed yet to back off the data until you need it (for each of the images). The SPI slave mode basically loads an image for that tile (usually tile 0) and branches to it. After that, everything will need to be done by the user. So it might be possible to have a self installing image that runs on tile 0 and boots tile 1, but you'd need to learn about how the links are setup, boot image format and how boot from link works (section 8.4) and think about how to carry the binary of image 1 inside the binary of image 0 and send it across the channel to the bootee (tile 1).

There are ways to extract the files you need from the

Code: Select all

.xe  xobjdump --split --strip

All doable though and there are no technical barriers to doing this (unless the binary size of both tiles exceeds the RAM of the first tile), but not for the feint hearted. It would be easier if it were just a single tile... Another option is to get your host to boot both tiles each with their own slave select. That could make things easier..

[choskin]

ok, thanks for the reply. I guess I was hoping there was support for this mode. I'll modify the hardware to leave the slave boot option available for the future and use a SPI flash for now.

[Ross]

Perhaps you could use some sort of factory upgrade based system - the flash holds some boot loader which has a separate I2C slave. This boot loader takes a boot image from I2C and stores it in the upgrade flash space. A separate I2C command causes the device to reboot into the upgrade image.

As far as the xCORE is concerned it is booting as normal from a flash and you wouldn't have to worry about loaders, setting links etc.

You'd ideally have to allow for some sort of "revert-to-factory" in the case when a bad upgrade image was used of course.

Not strictly "booting from a SPI master" but a means to that end potentially..

[choskin]

The card is controlled over I2C so I was looking at your libflash API to write an update image to the SPI flash when necessary. Fortunately there is enough spare RAM to buffer the image completely and verify it before actually writing it. Still, it would have been so much simpler to just blast a boot image over SPI from our file system like our other cards with coprocessors.

[Ross]

No need to verify the whole image before writing it, the loader won't boot an invalid image (Valid CRC etc). This protects against power loss during DFU.

If that wasn't the case you could have your own running CRC as you write it and simply invalidate/delete the written image data if it turned out to be bad?

[Ross]

Why doesn't the mainframe write directly to the flash if it is SPI master?

[choskin]

Allowing the mainframe to program the xmos flash directly is the direction we decided to go on this product. I'm hoping an old school 1 bit SPI flash part will boot properly with a XS2 part (in mode "1") to match up with our 1 bit SPI master interface.