This page provides details on building and customizing the FSBL for Zynq-7000, and important notes on the FSBL. All the information is presented in the format of FAQs.
The First Stage Bootloader (FSBL) for ZYNQ-7000 configures the FPGA with hardware bitstream(if it exists) and loads second stage bootloader or bare-metal application code from the non-volatile memory(NAND/SD/QSPI) to memory (DDR/OCM) and takes A9 out of reset. It supports multiple partition can be a code image or bitstream. Each of these partitions, if required, will be authenticated and/or encrypted. FSBL is loaded into OCM and handed off by BootROM after authenticating and/or decrypting (as required) FSBL.
Launch VITIS with the below command: vitis
Provide path where VITIS workspace and project need to be created. With this VITIS workspace will be created
(Optional step) To work with local repos, Select "Xilinx" (ALT - x) -> Repositories. Against Local Repositories, click on "New..." and provide path of the local repo
In the “Platform” section, click on “Create a new platform from hardware (XSA)” and select pre-defined hardware platform for Zynq(e.g. zc702).
Alternatively, to create a new/custom platform from a .xsa file, click on “+”, browse and select the XSA file and a new hardware platform is created.
In the "Domain" window, select the processor ps7_cortexa9_0/ps7_cortexa9_1, OS as standalone and Language as C
Click Next and select "Zynq FSBL"
Click "Finish" to generate the A9 FSBL. This populates the FSBL code and also builds it (along with BSP)
Debug prints in FSBL are now disabled by default (except for FSBL banner). To enable debug prints, define symbol: FSBL_DEBUG_INFO
In VITIS this can be done by: right click on FSBL application project -> select “C/C++ Build Settings” -> “Tool Settings” tab ->Symbols (under ARM v7-A gcc compiler)
Click on Add (+) icon and Enter Value: FSBL_DEBUG_INFO, click on "OK" to close the "Enter Value" screen
In case any of the source files (FSBL or BSP) need to be modified, browse the file, make the change and save the file, build the project.elf file will be present in the Debug/Release folder of FSBL project.
FSBL supports six levels of compilation flags:
Flag | Description |
---|---|
FSBL_DEBUG | Set this flag to enable the logs and message prints. |
FSBL_DEBUG_INFO | Set this flag to obtain more detailed logs like register and partition header dumps. |
FSBL_DEBUG_RSA | Set this flag to print more detailed intermediate values used in RSA functions. |
NON_PS_INSTANTIATE D_BITSTREAM | Set this flag when the bitstream does not have a PS component. Then the FSBL does not enable level shifters |
RSA_SUPPORT | Set this flag to enable authentication feature in FSBL. |
MMC_SUPPORT | Set this flag to enable MMC support in FSBL. When this flag is set, FSBL reads all the partitions from the eMMC device, instead of the primary boot device (which is set by the boot mode pins). |
FSBL can only be run from A9_0 (AArch32)
192 KB of OCM memory is accessible starting at address 0x0000_0000 for FSBL code memory. while the upper memory which is 64 KB of the OCM is accessible starting at address 0xFFFF_0000 for FSBL program memory.
There is no xfsbl_translation_table.S, FSBL uses the default available translation_table.S of BSP.
DDR ECC Initialization: Initially it was added in FSBL source code, later moved to ps7_init and removed from FSBL.
Debug prints: By default only FSBL banner is printed. If more debug prints are enabled, time takes to print messages will add additional delay to boot time and adds extra code which result in increasing footprint.
Drivers Asserts: Asserts are used within all Xilinx drivers and can be turned off on a system-wide basis by defining, at compile time, the NDEBUG identifier
(adding –DNDEBUG against extra_compiler_flags of drivers). This will help further reduce FSBL footprint.
For 2019.2, FSBL will be built by default to reduce the compilation time level optimization(-O0) in VITIS and we are able to debug FSBL in VItis.
Following are the memory regions and registers reserved for FSBL:
DDR region - 0x100000U (DDR_TEMP_START_ADDRESS) This is the address in DDR where bitstream will be copied temporarily.
OCM region - 0xFFFFFFF8U (BASEADDR_HOLDER) - The address holds the base address for the image boot ROM found.
The first partition must be the FSBL ELF followed by the bitstream partition and then the application ELF. Bitstream is optional. FSBL does a handoff to the first application in the BIF order. The order within the BIF file is important. Bitstream must be the partition after FSBL. The bitstream is required only if the PL must be programmed.
There is no USB boot mode support in FSBL.
To recover from an error condition, FSBL does a Fallback and enables BootROM to load another bootable image (the golden image that was originally present and in a known good state) if that image is present in the flash memory. FSBL updates a multiboot register and does a soft reset so that BootROM executes and loads the next present, valid image. Please refer UG821 for details on the fallback feature.
There is no early handoff support in FSBL.
Hooks are functions which can be defined by users. FSBL provides blank functions, and calls them from certain strategic locations. Below are the hooks available currently:
Hook purpose/location | Hook function name |
---|---|
Before PL bitstream download | FsblHookBeforeBitstreamDload() |
After PL bitstream download | FsblHookAfterBitstreamDload() |
Before handoff to the application | FsblHookBeforeHandoff() |
During FSBL fallback | FsblHookFallback() |
Boot time (or performance) measurement is a way to measure time taken to complete certain time consuming activities (e.g. partition copy,authentication, decryption etc). In addition, overall time taken by FSBL (measured from after ps7_init completion to completion of all partitions/bitstream loading) is also provided. This feature can be enabled by defining macro FSBL_PERF (in fsbl.h). Debug prints should not be enabled when FSBL_PERF macro is defined.
Zynq supports both linear and I/O mode QSPI. FSBL includes the ability to use linear addressing mode for Flash devices ≤128Mb and use IO mode for >128Mb devices. If a larger than 16MB QSPI flash is used, then in order to access data on the portion of the flash over 16MB, the software driver (standalone, u-boot, Linux) needs to extend the 3-bytes address storing the 4th byte into a vendor-specific QSPI register called "extended address register". Please refer AR# 64011 for QSPI reset requirements.
The BootROM uses the Linear mode to access the first 16MB of the QSPI flash to look for the boot image. There are limitations on where the boot image could be placed if larger than 16MB QSPI flash and RSA Authentication are used that the boot image cannot be placed at 0x0 offset in the flash for single x2 or x4, dual-stacked x4 and dual-parallel x4 configurations.
There are three possible work-arounds for this requirement:
NOTE: If RSA is not used, the boot image can be placed at 0x0 even for larger than 16MB QSPI.
Please refer to this tech-tip which intends to show how to make a DDR-Less system using Zynq-7000 SoC. It describes about executing boot loader code and application code without DDR. User can take this framework and use it for their specific applications.
Following points are covered in this tip.
There is a provision to have two boot devices in the Zynq-7000 architecture. The primary boot mode is the boot mode used by BootROM to load FSBL.
The secondary boot mode is the boot device used by FSBL to load all the other partitions. Zynq-7000 AP devices support eMMC flash devices in MLC and SLC configuration as a secondary boot source. FSBL supports loading the partitions from eMMC. This is possible only when the primary boot mode (set through the boot mode pins) is QSPI.
Use this option when there is a small QSPI flash and you would like to store all the other partitions on a larger flash memory like eMMC. In this case, place the FSBL on the QSPI flash and all the other partitions are on eMMC flash.
Secondary boot mode support from PCIe: Initially, BootROM and first stage boot loader (FSBL) are executed, and then u-boot. Loading u-boot from an external source like SD over QSPI is the primary boot mechanism.
The following application note in the link Zynq-7000 AP SOC Secondary Boot Over PCIe Techtip describes the implementation of secondary boot mechanism where the u-boot image will be transferred from an external host machine over PCI Express link to Processing System DDR memory.
ADMA and any one instance of IPI are required IPs for FSBL. Hence these IPs are required in design and also should be not isolated from the processor for which FSBL is being created.
No changes.
No changes.
Added code to check EFUSE_SEC_EN bit and force encryption.
No changes.
No changes.
No changes.
No changes.
No changes.
Fabric Initialization sequence is modified to check the PL power before sequence starts and checking INIT_B reset status twice in case of failure.
Added symbols to linker script to prevent linking failures in absence of spec file.
PS UART code is now referred only when PS UART is present in design. This is since STDOUT_BASEADDRESS is defined even for coresight UART.
Added support for Macronix flash.
Removed the hard coded value of qspi read command and configured to pick from LQSPI_CFG register.
As xilrsa is not mandatory for zynq, remove xilrsa check while creating application in SDK.