Recently I was talking to a client about a custom Zynq board they had designed and the issues they were facing with some boards booting OK and others not booting successfully. This got me thinking that a lot of what I have written in these blogs has been based around an already running board (e.g., development boards and system on modules).
Having successfully brought up several Zynq boards, I thought it would be a good idea to outline a few of the available debug options for when trying to boot the device from its boot media (SD card, QSPI etc.) only to find that it stubbornly refuses to configure.
The Zynq boot sequence is straight forward and well explained in chapter six of Xilinx UG585. Briefly however, following power on, resetting the PS begins running its boot ROM code which is within the on-chip ROM. The boot ROM’s purpose is to configure the basic system and then begin loading the FSBL from the configuration device. It identifies the boot image in the configuration device by looking for the boot image header. This header image contains several parameters which guides the boot ROM in its execution, for example, secure / non secure boot, execute in place etc.
In a successful boot, the boot image header will be found and the boot ROM will be able to successfully load the FSBL followed by the remainder of the software. This is regardless of whether it’s a simple bare metal program or a more complex Linux-based system that requires a second stage boot loader.
Of course, once the FSBL is loaded, any issues in the boot process, from simple print statements in the boot to output register values, to debugging using Vitis debugging, can be investigated using standard software debugging techniques.
However, what can we do if the boot image header is not found or is corrupted in the configuration device? In this instance, the device will not boot and since the FBL has not yet run, you have not seen any messages being outputted to a console yet. It can be worrisome if this were to occur on your new custom design, however, there are several steps we can take to determine why we might be experiencing a boot issue.
These steps do change depending if the configuration is secure or not. First, let’s look at what we can do if the configuration is not secure because this is more likely to be the case when bringing up a board for the first time.
Should the boot ROM fail to successfully load the FSBL when performing a non-secure boot, the INIT_B pin will be driven low to indicate an error and JTAG access will be enabled.
Once the JTAG port is enabled, we can use XSCT to connect to the Zynq device and read the slcr.REBOOT_STATUS (0xF8000258). The lower half of this word will present a boot ROM error code that can be investigated using Table 6-20 in UG585.
Reading this error code can easily be achieved using a JTAG pod and XSCT. See the image below where a MicroZed configured for an SD card boot has failed because no SD card was inserted.
This should enable you to find the issue that might be causing the boot ROM to fail and hopefully be able to address it.
Such a failure could also occur at a later stage in the development, perhaps during production when the configuration is secure to protect equipment once deployed to the field. In this case, access via JTAG following a boot ROM error is not possible.
In this case, we can still obtain the boot ROM error code by observing the output of the Init_B pin. This will pulse out the error code three times (LSB first), as shown in the diagram below.
Using these methods, we can determine if there is a boot ROM error and start looking into the root cause.
In a future blog, we will look at the methods we can use for the MPSoC boot and how we can debug if issues should occur.