Boot Device Initialization - 2020.2 English

Zynq UltraScale+ MPSoC Software Developer Guide (UG1137)

Document ID
Release Date
2020.2 English


This stage involves reading boot mode register to identify the primary boot device and initialize the corresponding device. Each boot device driver provides init, copy and release functions which are initialized to DevOps function pointers in this stage.

Figure 1. Primary Boot Device Initialization


Using the copy functions provided, the FSBL reads the boot header attributes and image offset address. It reads the EFUSE bit to check for authentication. It reads the image header and validates the image header table. It then reads the Partition Present Device attribute of image header. A non-zero value indicates a secondary boot device. A zero value indicates that the secondary boot device is the same as the primary boot device.

Figure 2. Validating Header


This function is called in case of a non-zero value of Partition Present Device attribute of image header table. It initializes the secondary boot device driver and the secondary boot device would be used to load all partitions by FSBL.


ATF is assumed to be the next loadable partition after FSBL. It is capable of loading U-Boot and secure OS and hence, it is passed a handoff structure.

The first partition of an application will have a non-zero execution address. All the remaining partitions of that application will have 0 as execution address. Hence look for the non-zero execution address for partition which is not the first one and ensure the CPU is A53.

This function sets the handoff parameters to the Arm Trusted Firmware (ATF). The first argument is taken from the FSBL partition header. A pointer to the handoff structure containing these parameters is stored in the PMU_GLOBAL.GLOBAL_GEN_STORAGE6 register, which the ATF reads. The structure is filled with magic characters 'X', 'L', 'N', and 'X' followed by the total number of partitions and execution address of each partition.