Booting L2 from a link - which XE images to use?

[Hooligan]

I've built a board with two L2 devices in a master/slave configuration. The master boots from SPI flash and the slave from the link. This works as expected with the XMOS toolchain using xrun or xflash. However, my application requires that the slave run code that is dependant on the peripherals that are attached. After the master identifies the peripherals, it will fetch the appropriate image and shove it down the link to the slave L2.

Writing a standalone app for the slave yields an xe file containing two images for each core. Based on the ELF descriptors, each core gets a small image to execute which is expected to return at completion. The second image for each core seems to be the actual app code.

So, are the small images necessary for device setup (i.e. PLL and ref clock divider) or are they second stage boot loaders used to load the app?

I've studied the excellent L2 bootloader project from Larry and he discards the small images and performs the set up from his own code. I would prefer to avoid that so the settings from the XN file are used as with the XMOS tools.

[Hooligan]

Experimenting with xmap reveals a command line option which seems to be related to my question:

Code: Select all

--bootstyle=<style>        Build multi-node XE with the special boot style: for sim or codegoblin(default)

Google shows codegoblin is a popular user name on twitter and various forums but shows notihng related to mapping code. Perhaps this is a tool and/or format specific to XMOS. Has anyone encountered this before or have any idea where to find documentation?

[daveg]

I've built a board with two L2 devices in a master/slave configuration. The master boots from SPI flash and the slave from the link. This works as expected with the XMOS toolchain using xrun or xflash. However, my application requires that the slave run code that is dependant on the peripherals that are attached. After the master identifies the peripherals, it will fetch the appropriate image and shove it down the link to the slave L2.

Writing a standalone app for the slave yields an xe file containing two images for each core. Based on the ELF descriptors, each core gets a small image to execute which is expected to return at completion. The second image for each core seems to be the actual app code.

So, are the small images necessary for device setup (i.e. PLL and ref clock divider) or are they second stage boot loaders used to load the app?

The first image is a network setup image, which xgdb will load on each core to allow the network to be in the expected state before the application starts. These shouldn't include the PLL settings as xgdb will set this for you upon connecting (I believe).

The second stage loader is generated by xflash and placed into the flash image (which can be dumped out to a file), and if there is a master core and link-boot slaves then all the network setup code and PLL setup is in the second stage code sent out from the master to the other cores (which are waiting on a chanend to receive a program to write to memory and jump to).


You probably want to use the custom bootloader code in xflash (which will run on the flash booting core) to decide which image to load. There should be examples in the documentation which show how to do such things.

bootstyle option

This option shouldn't be required, as far as I can tell. The 'codegoblin' was an xmos internal name for the boot style which leaked out into the option, and doesn't have anything to do with the twitter account or anything like that :)

[Hooligan]

Thanks Dave. I hadn't considered that the small images would be for the debugger.

I'll be downloading the images for the slave L2 over the network based on which peripherals are attached to the device. I'll have to figure out a little more about how xflash handles chained devices. On the slave L2, core 0 boots from XnLB and core 1 from the internal links. Getting the image on core 0 is straightforward. Core 1 is more difficult. I see two options:

1. Load core 0 which then accepts the core 1 image over XnLB and passes it on using the internal links.
2. Use sswitch messages to set up core IDs and routes so the core 1 image can be passed over a channel on XnLB.

It would be terrifically handy to have the xflash source along with the code for the flash boot sector. That would eliminate a lot of reverse engineering and re-engineering.

Thanks for the help so far.