...
Due to the limited amount of internal memory, both in On Chip Memory (OCM) and Block RAM (BRAM) in the PL, users might require more memory for the application and XIP could be a solution. XIP with Zynq 7000 is less common and can be a bit challenging when reviewing the documentation and FSBL image processing. An application is built for XIP by linking the text sections for the linear QSPI flash memory and the data sections for OCM. As illustrated below in the capture from the TRM (UG585), FSBL with both RSA and XIP is not supported by the BootROM such that the prototype system described on this page only supports user applications (not FSBL) built in XIP mode.
...
The tools do not support Position Independent Code such that . As a result, an XIP application must be linked for the address where it will be executing, such as QSPI in linear address mode, with the data being linked for RAM. The memory sections of the application, text and data, are multiple memories such that they are discontinuous and BootGen generates a multi-partition image for the application. The partitions of the multi-partition image are in the order of address such that , so the text partition must be first (using a lower address) to allow a predictable address matched to the linked address.
BootGen allows images to be located at specific offsets in the boot image but it does not allow the individual partitions of a multi-partition image to be individually located. This is not an issue when the text section of the application is at a lower address than the data section, but is a challenge with data memory at a lower address than the text, such as with OCM mapped low or BRAM.
QSPI flash in linear mode starts at address 0xFC00_0000 and OCM can be mapped high in the address space starting at 0xFFFC_0000 such that , so this works nicely for XIP mode. BRAM does not work easily for the data section since because it is mapped at 0x4XXX_XXXX or 0x8XXX_XXXX in the address map. The following illustration shows the memory map when FSBL is executing, followed by the memory map when SSBL is executing to illustrate OCM moving from low addresses to high addresses.
...
RSA processing is done in both the BootROM and FSBL. The FSBL assumes DDR is present such that the image is copied into DDR prior to performing the RSA signature verification. A DDR-less FSBL requires changes to support RSA such , so that it performs the RSA signature verification from QSPI. Security of the system should also be considered by users with the DDR-less system as the CPU spends more time accessing the external memory while performing the RSA algorithm. Boot time may also might be another consideration for fast booting systems and boot time was not a factor in the proposed solution.
FSBL changes to support RSA authentication from the QSPI include using the address of the image in QSPI for the authentication, and removal of the DDR as a temporary buffer for the PL bitstream. These are illustrated in the following code snippet of the image_mover.c source file and the LoadBootImage() function. Note the addition of conditional compilation for when DDR is in the system.
...
The following snippet of code illustrates the change to the GetNAuthImageHeader() function in imageimage_mover.c which causes the DDR-less system to allocate a temporary buffer in OCM rather than DDR for the authentication header.
...
For any security failures, such as a bad RSA signature, the FSBL normally causes a boot failure and makes the BootROM do multi-boot searching for the next valid image in the boot media. This may might not make sense for all systems as it might be valid to boot into a secure application that recognizes the failure and then updates the failing images. The following code snippet illustrates FSBL failing to authenticate an image and doing fallback to the BootROM.
...
Generating the boot image is critical for success. The following BIF file is an example for the prototype system which includes RSA keys, the FSBL, a PL bitstream, the SSBL application, a test application (hello world), and a 2nd second copy of the FSBL in BRAM for CPU warm reset. Images are placed at specific places in flash (offsets) to allow testing as the QSPI can only be erased in 128K sectors.
...
For QSPI flash memory, DDR-less systems with XIP require that the system update software to execute from another memory rather than QSPI. The QSPI memory is addressed in linear address mode for XIP which is a read only mode. The update application uses the QSPI driver and flash example to write to QSPI using I/O mode while running from OCM.
...
When programming flash memory or doing debug , using an FSBL rather than using ps7_init.tcl, the DDR-less FSBL must be used for all Vitis operations that require FSBL. A An FSBL for DDR will fail such that normal operation is not possible, causing failures such as a failure when trying to program flash memory.
RSA Authentication
RSA Without
...
eFuses
It can be useful to test RSA security without the need to program eFuses on the board. This is not a full security test, but it is a useful test prior to programming eFuses and allows the FSBL RSA processing to be tested. A minor change is required to the FSBL to support this feature as illustrated in the code snippet below. The code snippet is inserted at the point in the image_mover.c source file and the LoadBootImage() function where the Efuse eFuse Status Register is being read and . It uses conditional compilation to turn on this feature with RSA_WITHOUT_EFUSES.
...
Resets with the Zynq 7000 architecture include POR and SRST which include rebooting through the BootROM. There are use cases for CPU warm resets without going through the BootROM such as reinitializing the software to a known state while keeping the PL in an operational state. A warm reset causes the CPU to run the FSBL again without going through the BootROM such so that images are reloaded and restarted. A CPU warm reset in of the manner type described in the following paragraphs is most suited for simpler systems which do not include AXI masters in the PL, which may might be accessing PS resources.
...
The Multiboot Register is persistent across CPU and SRST resets, and provides a number of bits for user specific purposes. Assuming an application sets a bit in the Multiboot Register, the FSBL can detect the CPU reset and perform application specific processing, such as not reloading the PL.
...
A bare metal driver is provided for the AWDT in Vitis and is named xscuwdt. An example application in a source file named xscuwdt_polled_example.c is provided to start the AWDT and cause a CPU reset. The application must be altered to configure the CPU reset, rather than a system reset, and allow the AWDT to timeout to cause the CPU reset.
...
The FSBL must reside in OCM for a CPU reset to be performed. DDR-less systems may might require the FSBL to be restored from QSPI to OCM to facilitate the CPU reset. In a non-secure system, the FSBL can be copied by SSBL from QSPI into low OCM. In a secure system, a copy of the FSBL can be loaded by the FSBL into BRAM so that an authenticated FSBL can be reloaded into OCM by SSBL.
Alternative Designs
Another potentially useful method to create a CPU reset appears is to be useful using use the A9_RST0 bit of the slcr.A9_CPU_RST_CTRL Register. More detailed investigation shows that this is not a method that can be used by a CPU to reset itself, but is designed to be used by another CPU such as the other Cortex A9.