We hear periodically of customers using U-Boot as part of their test strategy. Most use U-boot as a Linux OS loader, and once the OS is loaded, they start a test application. Others use the built-in test functions within U-Boot or build an application that is U-Boot compatible for loading/execution. I’d like to peel back this onion, so to speak, on these methods. I always need a practical application to think through the idea, to dissect or expose problems or pitfalls. So, for the sake of discussion, I’ll start on the ZedBoard using the Zynq-7020 SoC from Xilinx
The first area to understand is what is the state of the hardware? I’ll assume for the sake of argument that a good boundary-scan test suite has been applied to the hardware and we can move ahead expecting the SoC to be correctly fitted to the PCB and presumable operational.
Since we are examining a functional test strategy, we need to understand the boot process or when is the U-Boot accessible to operate? If you are not familiar with the Zynq-7000 SoC there is a boot sequence pictured below. This figure starts at the BootROM and completes at the Linux Kernel.
The BootROM is located within the SoC and not configurable by the user. The BootROM determines whether the boot is secure or non-secure, performs some initialization of the system and clean-up. Next the ROM code determines (usually via switch settings) the desired boot mode (NAND, QSPI, JTAG) and loads the First Stage Boot Loader (FSBL) from the selected peripheral/interface into the On-Chip Memory (OCM) and jumps to the starting location of the FSBL.
The FSBL code does the hardware initialization, including the external memory, multiplex IO (MIO) and system clocks. This initialization is necessary to move to stage 2 where U-Boot would be loaded. So, it would appear the first point where the hardware is running from a functional aspect is after the FSBL at the end of Stage 1. However, that is not entirely true. The SoC can operate using the OCM and the JTAG interface only prior to hardware initialization. This does require a JTAG controller and careful management of the 292KB of OCM available.
Note: The use of a JTAG controller is highly recommended for U-Boot development and debug so there shouldn’t be an issue when considering a JTAG controller for test.
Then progressing to Stage 2, U-Boot is finally loaded. I not going to address what is needed to build U-Boot other than to say you will need a cross compiler to match the core (Arm) of the Zynq-7000 architecture and other tools. Getting the environment setup to build U-Boot is not trivial and is time-consuming. The time involved is inversely proportional to your experience with building Open System software. Once U-Boot is in a downloadable format, it can be placed in Non-Volatile storage, like an SD card, for downloading into DRAM.
Here is where I see a dilemma with using U-Boot for test. First I have to build U-Boot, and second have enough of the system operational, DDR (DDR controller/PHY) and SD flash interface etc. before testing can begin. Testing often involves non-operational system or minimally functionally operational hardware. The use of U-Boot expects a significant portion of the target hardware operational.
Second, assuming that you were successful in building U-Boot you now need to load it on the flash of the UUT. Be sure to follow the below warning. If U-Boot is already installed and running on your board, you can use these instructions to download another U-Boot image to replace the current one.
Warning: Before you can install the new image, you must erase the current one. If anything goes wrong your board will be dead. It is strongly recommended that you have a backup of the old, working U-Boot image or you know how to install an image on a virgin system.
Next U-Boot has limited testing capabilities. It has memory commands, flash memory commands, execution control commands, download commands, and miscellaneous commands. Which sounds robust. However, take mtest which is the memory test function within U-Boot. It is a simple RAM test. The command structure is as follows:
mtest [start [end [pattern [iterations]]]]
So with scripting, which is also supported, one could create a sequence of tests with various patterns to test the address and data paths. However, a warning that is within the U-Boot developer guide is that you need to be sure not to test operational space of U-Boot such as exception vectors, heap or stack space or U-Boot’s internal program code. Also, don’t use this in ROM or flash memory regions. You might crash U-Boot. So, the memory test presupposes that I have already tested the memory region where I expect to load and execute U-Boot. I can test memory with JTAG for the U-Boot region/footprint. But if the footprint is large it will impact the production beat rate.
Then there is a question in my mind about the diagnostic error messaging for mtest. It is not documented, but I assume that this is a pass/fail test. If so, the test developer would need to determine the cause of the failure, which might require other test function development, to provide diagnostic messages appropriate for the end consumer.
As I mentioned you could develop a sequence of tests to test memory for address and data (which have already been developed by countless engineering teams) but how would you create situational stress on the memory subsystem? Say induced noise?
So, in summary, the way I see it, some of the drawbacks of a U-boot based strategy are:
- It presumes that the SoC is assembled correctly to the board and operational
- DDR, SD flash, etc. to load U-boot are operational
- It presumes that U-boot has already been developed for the target
- U-boot utilities have their own set of constraints
- Impact on beat rate is high
- Diagnostic messaging and granularity is questionable
Imagine if there were a way to achieve a test coverage better than U-boot, but not need U-boot, and run before the FSBL. This way you could ensure the FSBL hardware initialization worked and if it didn’t it could indicate a problem within the FSBL code. It is not necessary to imagine these capabilities. ScanWorks® PFx tools use the SoC hardware resources like the processor and on chip memory (OCM) to provide memory test access at the bare metal. Great for prototype or production testing.
There are other topics that I hope to address in future blogs on U-Boot as a test strategy.
