Zynq-7000 FSBL


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.

Table of Contents

What is FSBL?

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.

How to create FSBL from Vitis?

  • 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

  • Select File-->New-->Application Project to open "New Project" window, provide name for FSBL project
  • 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.

What are various levels of compilation flags in FSBL?

FSBL supports six levels of compilation flags:

FlagDescription
FSBL_DEBUGSet this flag to enable the logs and message prints.
FSBL_DEBUG_INFOSet this flag to obtain more detailed logs like register and partition header dumps.
FSBL_DEBUG_RSASet 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_SUPPORTSet this flag to enable authentication feature in FSBL.
MMC_SUPPORTSet 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).

On what all processor cores can FSBL run on?

FSBL can only be run from A9_0 (AArch32)

What part of OCM is used by FSBL?

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.

Is there any xfsbl_translation_table.S different from translation_table.S of BSP in ZYNQ?

There is no xfsbl_translation_table.S, FSBL uses the default available translation_table.S of BSP.

What ECC initialization is done by FSBL?

DDR ECC Initialization: Initially it was added in FSBL source code, later moved to ps7_init and removed from FSBL.

Are there any other ways by which FSBL footprint can be further reduced?

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.

What level of optimization used by FSBL?

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.

What are the memory regions and registers reserved for FSBL?

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.

Is there any order in which I have to specify bitstream in BIF file (for boot image creation)?

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.

Is USB boot mode supported in FSBL?

There is no USB boot mode support in FSBL.

What us the FSBL fallback feature and does FSBL support this?

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.

Is early handoff supported in FSBL?

There is no early handoff support in FSBL.

What are the various hooks provided in FSBL code?

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/locationHook function name
Before PL bitstream downloadFsblHookBeforeBitstreamDload()
After PL bitstream downloadFsblHookAfterBitstreamDload()
Before handoff to the applicationFsblHookBeforeHandoff()
During FSBL fallbackFsblHookFallback()

How boot time measurements can be done in FSBL?

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.

What are QSPI modes support added in FSBL and reset requirements for large QSPI?

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.

What are the boot image requirements when using larger than 16MB QSPI and RSA Authentication?

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:

  • Erase the first 32KB of flash and program the boot image at 0x0 + 32KB offset (64KB in the case of dual parallel)
    The BootROM will fail booting from 0x0, will fallback and will boot from 0x0 +32KB offset (see UG585 Zynq-7000-TRM for Boot Partition Search).
  • Program the boot image at 0x0 and Duplicate the Image Header at 0x0 + 16MB offset.
    The BootROM will use the Image Header at 0x0 + 16MB offset and then will boot with the boot image programmed at 0x0.
  • Use only single x1 QSPI mode.

NOTE: If RSA is not used, the boot image can be placed at 0x0 even for larger than 16MB QSPI.

What are the changes required in FSBL for Execute-in-Place (XIP) option for QSPI flash memory?

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.

  • Shows FSBL XIP execution.
  • Provide sample routine to do preloading of the data/code to L2-cache, in FSBL.
  • Shows L2-cache Lockdown feature in Zynq-7000 SOC.
  • Reference design for AXI Timer in PL.
  • Shows Interrupt working concept.
  • C and C++ application to run in L2-cache lock down mode.

What is Secondary Boot mode?

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.

What are the peripherals/IPs required for FSBL?

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.

Revision History

What's new in 2019.2 release?

No changes.

What's new in 2019.1 release?

No changes.

What's new in 2018.3 release?

Added code to check EFUSE_SEC_EN bit and force encryption.

What's new in 2018.2 release?

No changes.

What's new in 2018.1 release?

No changes.

What's new in 2017.3 release?

No changes.

What's new in 2017.2 release?

No changes.

What's new in 2017.1 release?

No changes.

What's new in 2016.3 release?

Fabric Initialization sequence is modified to check the PL power before sequence starts and checking INIT_B reset status twice in case of failure.

What's new in 2016.2 release?

Added symbols to linker script to prevent linking failures in absence of spec file.

What's new in 2016.1 release?

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.