As background information, the history of our SPI boot scripts is:
the Tools team did not provide the necessary functionality (including the second-stage bootloader) to SPI boot an application on our chip
the loading technique is complex and not customer-friendly
there is an app note that was by originally written by Larry: AN00238; the scripts were later extended to the current functionality
The level of support for testing of SPI boot across our products is varied. This issue is to consider how we can consolidate our support for performing and testing SPI boot, and whether this should be separated into its own repository. Below is a summary of the areas where we know that we have some level of support for SPI boot.
XVF3610
There are tests in the hardware_tests. These tests run on a specific hardware setup consisting of an RPi with a 3610 pi-hat. A Python script extracts the binary image and prepare it to be SPI booted. These tests are run in the sw_xvf3610 Jenkins job.
The automated test does the following:
erase flash and reset processor
check that flash is blank
boot the image over SPI
verify that the sending of the image has completed
issues two commands to start the firmware
gets the firmware version to verify that the expected version is running
This is only tested for the INT build, not UA, because the RPi setup differs between the two: for INT the DUT is a SPI-slave, whereas for UA the DUT is a SPI-master.
XVF3510
SPI boot has been manually tested in the past, but there is currently no automated testing of this feature. There is an issue to extend the automated testing in this area. There is a Python script to extract the binary image and prepare it to be SPI booted, which differs from its XVF3610 equivalent in the involvement of the USB PHY and some address values which are specific to the hardware platform.
Production Tests
Recent work on a production test for XVF3600 revealed that the process for performing production tests on all XS3 chips consists of loading an application image via SPI boot on the chip being tested. There is a Python script, nominally owned by the Silicon team and possibly originally written by Henk, which produces a test pattern that consists of TSET instructions which are fed to the chip to program the image bitwise to perform a SPI-slave boot of the test application. To produce this test pattern, the binary image is extracted from the application executable in what looks to be a similar way to the SPI boot image generation in XVF3610.
Chip Functionality
The current functionality of the chip is:
loads a basic SPI-slave driver
accepts a header containing an address and a length
accepts bytes and stores them in incrementing locations starting at the given address
when it has received the number of bytes given, the driver branches to the given address
There is no multi-tile support, so the xSwitch has to be brought up manually to load a multi-tile image.
As background information, the history of our SPI boot scripts is:
The level of support for testing of SPI boot across our products is varied. This issue is to consider how we can consolidate our support for performing and testing SPI boot, and whether this should be separated into its own repository. Below is a summary of the areas where we know that we have some level of support for SPI boot.
XVF3610
There are tests in the hardware_tests. These tests run on a specific hardware setup consisting of an RPi with a 3610 pi-hat. A Python script extracts the binary image and prepare it to be SPI booted. These tests are run in the sw_xvf3610 Jenkins job.
The automated test does the following:
This is only tested for the INT build, not UA, because the RPi setup differs between the two: for INT the DUT is a SPI-slave, whereas for UA the DUT is a SPI-master.
XVF3510
SPI boot has been manually tested in the past, but there is currently no automated testing of this feature. There is an issue to extend the automated testing in this area. There is a Python script to extract the binary image and prepare it to be SPI booted, which differs from its XVF3610 equivalent in the involvement of the USB PHY and some address values which are specific to the hardware platform.
Production Tests
Recent work on a production test for XVF3600 revealed that the process for performing production tests on all XS3 chips consists of loading an application image via SPI boot on the chip being tested. There is a Python script, nominally owned by the Silicon team and possibly originally written by Henk, which produces a test pattern that consists of
TSETinstructions which are fed to the chip to program the image bitwise to perform a SPI-slave boot of the test application. To produce this test pattern, the binary image is extracted from the application executable in what looks to be a similar way to the SPI boot image generation in XVF3610.Chip Functionality
The current functionality of the chip is:
There is no multi-tile support, so the xSwitch has to be brought up manually to load a multi-tile image.