Boot Image Layout

This section describes the format of the boot image for different architectures.

Building a boot image involves the following steps:

  1. Create a BIF file.
  2. Run the Bootgen executable to create a boot image.
    Note: For the Quick Emulator (QEMU) you must convert the binary file to an image format corresponding to the boot device.

The input files are not necessarily different for each device (for example, for every device, elfs can be input files that can be part of the boot image), but the format of the boot image is different. The following topics describe the required format of the boot header, image header, partition header, initialization, and authentication certificate header for each device.

Zynq-7000 SoC Boot and Configuration

This section describes the boot and configuration sequence for Zynq®-7000 SoC. See the Zynq-7000 SoC Technical Reference Manual (UG585) for more details on the available first stage boot loader (FSBL) structures.

BootROM on Zynq-7000 SoC

The BootROM is the first software to run in the application processing unit (APU). BootROM executes on the first Cortex® processor, A9-0, while the second processor, Cortex, A9-1, executes the wait for event (WFE) instruction. The main tasks of the BootROM are to configure the system, copy the FSBL from the boot device to the on-chip memory (OCM), and then branch the code execution to the OCM.

Optionally, you can execute the FSBL directly from a Quad-SPI or NOR device in a non-secure environment. The master boot device holds one or more boot images. A boot image is made up of the boot header and the first stage boot loader (FSBL). Additionally, a boot image can have programmable logic (PL), a second stage boot loader (SSBL), and an embedded operating system and applications; however, these are not accessed by the BootROM. The BootROM execution flow is affected by the boot mode pin strap settings, the boot header, and what it discovers about the system. The BootROM can execute in a secure environment with encrypted FSBL, or a non-secure environment. The supported boot modes are:

  • JTAG mode is primarily used for development and debug.
  • NAND, parallel NOR, Serial NOR (Quad-SPI), and Secure Digital (SD) flash memories are used for booting the device. The Zynq-7000 SoC Technical Reference Manual (UG585) provides the details of these boot modes. See Zynq-7000 Boot and Configuration AR#52538 for answers to common boot and configuration questions.

Zynq-7000 SoC Boot Image Layout

The following is a diagram of the components that can be included in a Zynq®-7000 SoC boot image.
Figure 1: Boot Header

Zynq-7000 SoC Boot Header

Bootgen attaches a boot header at the beginning of a boot image. The boot header table is a structure that contains information related to booting the primary bootloader, such as the FSBL. There is only one such structure in the entire boot image. This table is parsed by BootROM to get determine where FSBL is stored in flash and where it needs to be loaded in OCM. Some encryption and authentication related parameters are also stored in here. The additional boot image components are:

Additionally, the Boot Header contains a Zynq-7000 SoC Register Initialization Table. BootROM uses the boot header to find the location and length of FSBL and other details to initialize the system before handing off the control to FSBL.

The following table provides the address offsets, parameters, and descriptions for the Zynq®-7000 SoC Boot Header.

Table 1. Zynq-7000 SoC Boot Header
Address Offset Parameter Description
0x00-0x1F Arm® Vector table Filled with dummy vector table by Bootgen (Arm Op code 0xEAFFFFFE, which is a branch-to-self infinite loop intended to catch uninitialized vectors.
0x20 Width Detection Word This is required to identify the QSPI flash in single/dual stacked or dual parallel mode. 0xAA995566 in little endian format.
0x24 Header Signature Contains 4 bytes ‘X’,’N’,’L’,’X’ in byte order, which is 0x584c4e58 in little endian format.
0x28 Key Source Location of encryption key within the device:
  • 0x3A5C3C5A: Encryption key in BBRAM.
  • 0xA5C3C5A3: Encryption key in eFUSE.
  • 0x00000000: Not Encrypted.
0x2C Header Version 0x01010000
0x30 Source Offset Location of FSBL (bootloader) in this image file.
0x34 FSBL Image Length Length of the FSBL, after decryption.
0x38 FSBL Load Address (RAM) Destination RAM address to which to copy the FSBL.
0x3C FSBL Execution address (RAM) Entry vector for FSBL execution.
0x40 Total FSBL Length Total size of FSBL after encryption, including authentication certificate (if any) and padding.
0x44 QSPI Configuration Word Hard coded to 0x00000001.
0x48 Boot Header Checksum Sum of words from offset 0x20 to 0x44 inclusive. The words are assumed to be little endian.
0x4c-0x97 User Defined Fields 76 bytes
0x98 Image Header Table Offset Pointer to Image Header Table
0x9C Partition Header Table Offset Pointer to Partition Header Table

Zynq-7000 SoC Register Initialization Table

The Register Initialization Table in Bootgen is a structure of 256 address-value pairs used to initialize PS registers for MIO multiplexer and flash clocks. For more information, see About Register Intialization Pairs and INT File Attributes.

Table 2. Zynq-7000 SoC Register Initialization Table
Address Offset Parameter Description
0xA0 to 0x89C Register Initialization Pairs: <address>:<value>: Address = 0xFFFFFFFF means skip that register and ignore the value.

All the unused register fields must be set to Address=0xFFFFFFFF and value = 0x0.

Zynq-7000 SoC Image Header Table

Bootgen creates a boot image by extracting data from ELF files, bitstream, data files, and so forth. These files, from which the data is extracted, are referred to as images. Each image can have one or more partitions. The Image Header table is a structure, containing information which is common across all these images, and information like; the number of images, partitions present in the boot image, and the pointer to the other header tables. The following table provides the address offsets, parameters, and descriptions for the Zynq®-7000 SoC device.

Table 3. Zynq-7000 SoC Image Header Table
Address Offset Parameter Description
0x00 Version 0x01010000: Only fields available are 0x0, 0x4, 0x8, 0xC, and a padding

0x01020000:0x10 field is added.
0x04 Count of Image Headers Indicates the number of image headers.
0x08 First Partition Header Offset Pointer to first partition header. (word offset)
0x0C First Image Header Offset Pointer to first image header. (word offset)
0x10 Header Authentication Certificate Offset Pointer to the authentication certificate header. (word offset)
0x14 Reserved Defaults to 0xFFFFFFFF.

Zynq-7000 SoC Image Header

The Image Header is an array of structures containing information related to each image, such as an ELF file, bitstream, data files, and so forth. Each image can have multiple partitions, for example an ELF can have multiple loadable sections, each of which forms a partition in the boot image. The table will also contain the information of number of partitions related to an image. The following table provides the address offsets, parameters, and descriptions for the Zynq®-7000 SoC device.

Table 4. Zynq-7000 SoC Image Header
Address Offset Parameter Description
0x00 Next Image Header. Link to next Image Header. 0 if last Image Header (word offset).
0x04 Corresponding partition header. Link to first associated Partition Header (word offset).
0x08 Reserved Always 0.
0x0C Partition Count Length Number of partitions associated with this image.
0x10 to N Image Name Packed in big endian order. To reconstruct the string, unpack 4 bytes at a time, reverse the order, and concatenate. For example, the string “FSBL10.ELF” is packed as 0x10: ‘L’,’B’,’S’,’F’, 0x14: ’E’,’.’,’0’,’1’, 0x18: ’\0’,’\0’,’F’,’L’ .

The packed image name is a multiple of 4 bytes.
N String Terminator 0x00000000
N+4 Reserved Defaults to 0xFFFFFFFF to 64 bytes boundary.

Zynq-7000 SoC Partition Header

The Partition Header is an array of structures containing information related to each partition. Each partition header table is parsed by the Boot Loader. The information such as the partition size, address in flash, load address in RAM, encrypted/signed, and so forth, are part of this table. There is one such structure for each partition including FSBL. The last structure in the table is marked by all NULL values (except the checksum.) The following table shows the offsets, names, and notes regarding the Zynq®-7000 SoC Partition Header.
Note: An ELF file with three (3) loadable sections has one image header and three (3) partition header tables.
Table 5. Zynq-7000 SoC Partition Header
Offset Name Notes
0x00 Encrypted Partition length Encrypted partition data length.
0x04 Unencrypted Partition length Unencrypted data length.
0x08 Total partition word length (Includes Authentication Certificate.) See Zynq-7000 SoC Authentication Certificate. The total partition word length comprises the encrypted information length with padding, the expansion length, and the authentication length.
0x0C Destination load address. The RAM address into which this partition is to be loaded.
0x10 Destination execution address. Entry point of this partition when executed.
0x14 Data word offset in Image Position of the partition data relative to the start of the boot image
0x18 Attribute Bits See Zynq-7000 SoC Partition Attribute Bits
0x1C Section Count Number of sections in a single partition.
0x20 Checksum Word Offset Location of the corresponding checksum word in the boot image.
0x24 Image Header Word Offset Location of the corresponding Image Header in the boot image
0x28 Authentication Certification Word Offset Location of the corresponding Authentication Certification in the boot image.
0x2C-0x38 Reserved Reserved
0x3C Header Checksum Sum of the previous words in the Partition Header.

Zynq-7000 SoC Partition Attribute Bits

The following table describes the Partition Attribute bits of the partition header table for a Zynq®-7000 SoC device.

Table 6. Zynq-7000 SoC Partition Attribute Bits
Bit Field Description Notes
31:18 Reserved Not used
17:16 Partition owner
  • 0: FSBL
  • 1: UBOOT
  • 2 and 3: reserved
15 RSA signature present
  • 0: No RSA authentication certificate
  • 1: RSA authentication certificate
14:12 Checksum type
  • 0: None
  • 1: MD5
  • 2-7: reserved
11:8 Reserved Not used
7:4 Destination device
  • 0: None
  • 1: PS
  • 2: PL
  • 3: INT
  • 4-15: Reserved
3:2 Reserved Not used
1:0 Reserved Not used

Zynq-7000 SoC Authentication Certificate

The Authentication Certificate is a structure that contains all the information related to the authentication of a partition. This structure has the public keys, all the signatures that BootROM/FSBL needs to verify. There is an Authentication Header in each Authentication Certificate, which gives information like the key sizes, algorithm used for signing, and so forth. The Authentication Certificate is appended to the actual partition, for which authentication is enabled. If authentication is enabled for any of the partitions, the header tables also needs authentication. Header Table Authentication Certificate is appended at end of the header tables content.

The Zynq®-7000 SoC uses an RSA-2048 authentication with a SHA-256 hashing algorithm, which means the primary and secondary key sizes are 2048-bit. Because SHA-256 is used as the secure hash algorithm, the FSBL, partition, and authentication certificates must be padded to a 512-bit boundary.

The format of the Authentication Certificate in a Zynq®-7000 SoC is as shown in the following table.

Table 7. Zynq-7000 SoC Authentication Certificate
Authentication Certificate Bits Description
0x00 Authentication Header = 0x0101000. See Zynq-7000 SoC Authentication Certificate Header.
0x04 Certificate size
0x08 UDF (56 bytes)
0x40 PPK Mod (256 bytes)
0x140 Mod Ext (256 bytes)
0x240 Exponent
0x244 Pad (60 bytes)
0x280 SPK Mod (256 bytes)
0x380 Mod Ext (256 bytes)
0x480 Exponent (4 bytes)
0x484 Pad (60 bytes)
0x4C0 SPK Signature = RSA-2048 (PSK, Padding || SHA-256 (SPK))
0x5C0 FSBL Partition Signature = RSA-2048 (SSK, SHA256 (Boot Header || FSBL partition))
0x5C0 Other Partition Signature = RSA-2048 (SSK, SHA-256 (Partition || Padding || Authentication Header || PPK || SPK || SPK Signature))

Zynq-7000 SoC Authentication Certificate Header

The following table describes the Zynq®-7000 SoC Authentication Certificate Header.
Table 8. Zynq-7000 SoC Authentication Certificate Header
Bit Offset Field Name Description
31:16 Reserved 0
15:14 Authentication Certificate Format 00: PKCS #1 v1.5
13:12 Authentication Certificate Version 00: Current AC
11 PPK Key Type 0: Hash Key
10:9 PPK Key Source 0: eFUSE
8 SPK Enable 1: SPK Enable
7:4 Public Strength 0:2048
3:2 Hash Algorithm 0: SHA256

Zynq-7000 SoC Boot Image Block Diagram

The following is a diagram of the components that can be included in a Zynq®-7000 SoC boot image.
Figure 2: Zynq-7000 SoC Boot Image Block Diagram

Zynq UltraScale+ MPSoC Boot and Configuration

Introduction

Zynq® UltraScale+™ MPSoC supports the ability to boot from different devices such as a QSPI flash, an SD card, USB device firmware upgrade (DFU) host, and the NAND flash drive. This chapter details the boot-up process using different booting devices in both secure and non-secure modes. The boot-up process is managed and carried out by the Platform Management Unit (PMU) and Configuration Security Unit (CSU).

During initial boot, the following steps occur:

  • The PMU is brought out of reset by the power on reset (POR).
  • The PMU executes code from PMU ROM.
  • The PMU initializes the SYSMON and required PLLs for the boot, clears the low power and full power domains, and releases the CSU reset.

After the PMU releases the CSU, CSU does the following:

  • Checks to determine if authentication is required by the FSBL or the user application.
  • Performs an authentication check and proceeds only if the authentication check passes. Then checks the image for any encrypted partitions.
  • If the CSU detects partitions that are encrypted, the CSU performs decryption and initializes OCM, determines boot mode settings, performs the FSBL load and an optional PMU firmware load.
  • After execution of CSU ROM code, it hands off control to FSBL. FSBL uses PCAP interface to program the PL with bitstream.

FSBL then takes the responsibility of the system. The Zynq UltraScale+ Device Technical Reference Manual (UG1085) provides details on CSU and PMU. For specific information on CSU, see "Configuration Security Unit" in the Zynq UltraScale+ MPSoC: Software Developers Guide (UG1137).

Zynq UltraScale+ MPSoC Boot Image

The following figure shows the Zynq® UltraScale+™ MPSoC boot image.

Figure 3: Zynq UltraScale+ MPSoC Boot Image

Zynq UltraScale+ MPSoC Boot Header

About the Boot Header

Bootgen attaches a boot header at the starting of any boot image. The boot header table is a structure that contains information related to booting of primary bootloader, such as the FSBL. There is only one such structure in entire boot image. This table is parsed by BootROM to get the information of where FSBL is stored in flash and where it needs to be loaded in OCM. Some encryption and authentication related parameters are also stored in here. The boot image components are:

BootROM uses the boot header to find the location and length of FSBL and other details to initialize the system before handing off the control to FSBL. The following table provides the address offsets, parameters, and descriptions for the Zynq® UltraScale+™ MPSoC device.

Table 9. Zynq UltraScale+ MPSoC Device Boot Header
Address Offset Parameter Description
0x00-0x1F Arm® vector table XIP ELF vector table:
  • 0xEAFFFFFE: for Cortex®-R5F and Cortex A53 (32-bit)
  • 0x14000000: for Cortex A53 (64-bit)
0x20 Width Detection Word This field is used for QSPI width detection. 0xAA995566 in little endian format.
0x24 Header Signature Contains 4 bytes ‘X’, ’N’, ’L’, ’X’ in byte order, which is 0x584c4e58 in little endian format.
0x28 Key Source
  • 0x00000000 (Un-Encrypted)
  • 0xA5C3C5A5 (Black key stored in eFUSE)
  • 0xA5C3C5A7 (Obfuscated key stored in eFUSE)
  • 0x3A5C3C5A (Red key stored in BBRAM)
  • 0xA5C3C5A3 (eFUSE RED key stored in eFUSE)
  • 0xA35C7CA5 (Obfuscated key stored in Boot Header)
  • 0xA3A5C3C5 (USER key stored in Boot Header)
  • 0xA35C7C53 (Black key stored in Boot Header)
0x2C FSBL Execution address (RAM) FSBL execution address in OCM or XIP base address.
0x30 Source Offset If no PMUFW, then it is the start offset of FSBL. If PMUFW, then start of PMUFW.
0x34 PMU Image Length PMU firmware original image length in bytes. (0-128KB).
  • If size > 0, PMUFW is prefixed to FSBL.
  • If size = 0, no PMUFW image.
0x38 Total PMU FW Length Total PMUFW image length in bytes.(PMUFW length + encryption overhead)
0x3C FSBL Image Length Original FSBL image length in bytes. (0-250KB). If 0, XIP bootimage is assumed.
0x40 Total FSBL Length FSBL image length + Encryption overhead of FSBL image + Auth. Cert., + 64byte alignment + hash size (Integrity check).
0x44 FSBL Image Attributes See Bit Attributes.
0x48 Boot Header Checksum Sum of words from offset 0x20 to 0x44 inclusive. The words are assumed to be little endian.
0x4C-0x68 Obfuscated/Black Key Storage Stores the Obfuscated key or Black key.
0x6C Shutter Value 32-bit PUF_SHUT register value to configure PUF for shutter offset time and shutter open time.
0x70 -0x94 User-Defined Fields (UDF) 40 bytes.
0x98 Image Header Table Offset Pointer to Image Header Table.
0x9C Partition Header Table Offset Pointer to Partition Header.
0xA0-0xA8 Secure Header IV IV for secure header of bootloader partition.
0x0AC-0xB4 Obfuscated/Black Key IV IV for Obfuscated or Black key.

Zynq UltraScale+ MPSoC Boot Header Attribute Bits

Table 10. Zynq UltraScale+ MPSoC Boot Header Attribute Bits
Field Name Bit Offset Width Default Description
Reserved 31:16 16 0x0 Reserved. Must be 0.
BHDR RSA 15:14 2 0x0
  • 0x3: RSA Authentication of the boot image will be done, excluding verification of PPK hash and SPK ID.
  • All Others others : RSA Authentication will be decided based on eFuse RSA bits.
Reserved 13:12 2 0x0 NA
CPU Select 11:10 2 0x0
  • 0x0: R5 Single
  • 0x1: A53 Single 32-bit
  • 0x2: A53 Single 64-bit
  • 0x3: R5 Dual
Hashing Select 9:8 2 0x0
  • 0x0, 0x1 : No Integrity check
  • 0x3: SHA3 for BI integrity check
PUF-HD 7:6 2 0x0
  • 0x3: PUF HD is part of boot header.
  • All other: PUF HD is in eFuse
Reserved 5:0 6 0x0 Reserved for future use. Must be 0.

Zynq UltraScale+ MPSoC Register Initialization Table

The Register Initialization Table in Bootgen is a structure of 256 address-value pairs used to initialize PS registers for MIO multiplexer and flash clocks. For more information, see Initialization Pairs and INT File Attribute.

Table 11. Zynq UltraScale+ MPSoC Register Initialization Table
Address Offset Parameter Description
0xB8 to 0x8B4 Register Initialization Pairs: <address>:<value>:

(2048 bytes)

If the Address is set to 0xFFFFFFFF, that register is skipped and the value is ignored. All unused register fields must be set to Address=0xFFFFFFFF and value =0x0.

Zynq UltraScale+ MPSoC PUF Helper Data

The PUF uses helper data to re-create the original KEK value over the complete guaranteed operating temperature and voltage range over the life of the part. The helper data consists of a <syndrome_value>, an <aux_value>, and a <chash_value>. The helper data can either be stored in eFUSEs or in the boot image. See puf_file for more information. Also, see this link to the section on "PUF Helper Data" in Zynq UltraScale+ Device Technical Reference Manual (UG1085).
Table 12. Zynq UltraScale+ MPSoC PUF Helper Data
Address Offset Parameter Description
0x8B8 to 0xEC0 PUF Helper Data (1544 bytes) Valid only when Boot Header Offset 0x44 (bits 7:6) == 0x3. If the PUF HD is not inserted then Boot Header size = 2048 bytes. If the PUF Header Data is inserted, then the Boot Header size = 3584 bytes. PUF HD size = Total size = 1536 bytes of PUFHD + 4 bytes of CHASH + 2 bytes of AUX + 1 byte alignment = 1544 byte.

Zynq UltraScale+ MPSoC Image Header Table

Bootgen creates a boot image by extracting data from ELF files, bitstream, data files, and so forth. These files, from which the data is extracted, are referred to as images. Each image can have one or more partitions. The Image Header table is a structure, containing information which is common across all these images, and information like; the number of images, partitions present in the boot image, and the pointer to the other header tables.

Table 13. Zynq UltraScale+ MPSoC Device Image Header Table
Address Offset Parameter Description
0x00 Version
  • 0x01010000
  • 0x01020000 - 0x10 field is added
0x04 Count of Image Header Indicates the number of image headers.
0x08 1st Partition Header Offset Pointer to first partition header (word offset).
0x0C 1st Image Offset Header Pointer to first image header (word offset).
0x10 Header Authentication Certificate Pointer to header authentication certificate (word offset).
0x14 Secondary Boot Device Options are:
  • 0 - Same boot device
  • 1 - QSPI-32
  • 2 - QSPI-24
  • 3 - NAND
  • 4 - SD0
  • 5 - SD1
  • 6 - SDLS
  • 7 - MMC
  • 8 - USB
  • 9 - ETHERNET
  • 10 - PCIE
  • 11 - SATA
0x18- 0x38 Padding Reserved (0x0)
0x3C Checksum A sum of all the previous words in the image header.

Zynq UltraScale+ MPSoC Image Header

About Image Headers

The Image Header is an array of structures containing information related to each image, such as an ELF file, bitstream, data files, and so forth. Each image can have multiple partitions, for example an ELF can have multiple loadable sections, each of which form a partition in the boot image. The table will also contain the information of number of partitions related to an image. The following table provides the address offsets, parameters, and descriptions for the Zynq® UltraScale+™ MPSoC.

Table 14. Zynq UltraScale+ MPSoC Device Image Header
Address Offset Parameter Description
0x00 Next image header offset Link to next Image Header. 0 if last Image Header. (word offset)
0x04 Corresponding partition header Link to first associated Partition Header. (word offset)
0x08 Reserved Always 0.
0x0C Partition Count Value of the actual partition count.
0x10 - N Image Name Packed in big endian order. To reconstruct the string, unpack 4 bytes at a time, reverse the order, and concatenated. For example, the string “FSBL10.ELF” is packed as 0x10: ‘L’,’B’,’S’,’F’, 0x14: ’E’,’.’,’0’,’1’, 0x18: ’\0’,’\0’,’F’,’L’ The packed image name is a multiple of 4 bytes.
varies String Terminator 0x00000
varies Padding Defaults to 0xFFFFFFF to 64 bytes boundary.

Zynq UltraScale+ MPSoC Partition Header

About the Partition Header

The Partition Header is an array of structures containing information related to each partition. Each partition header table is parsed by the Boot Loader. The information such as the partition size, address in flash, load address in RAM, encrypted/signed, and so forth, are part of this table. There is one such structure for each partition including FSBL. The last structure in the table is marked by all NULL values (except the checksum.) The following table shows the offsets, names, and notes regarding the Zynq® UltraScale+™ MPSoC.

Table 15. Zynq UltraScale+ MPSoC Device Partition Header
Offset Name Notes
0x0 Encrypted Partition Data Word Length Encrypted partition data length.
0x04 Un-encrypted Data Word Length Unencrypted data length.
0x08 Total Partition Word Length (Includes Authentication Certificate. See Authentication Certificate. The total encrypted + padding + expansion +authentication length.
0x0C Next Partition Header Offset Location of next partition header (word offset).
0x10 Destination Execution AddressLO The lower 32-bits of executable address of this partition after loading.
0x14 Destination Execution Address HI The higher 32-bits of executable address of this partition after loading.
0x18 Destination Load Address LO The lower 32-bits of RAM address into which this partition is to be loaded.
0x1C Destination Load Address HI The higher 32-bits of RAM address into which this partition is to be loaded.
0x20 Actual Partition Word Offset The position of the partition data relative to the start of the boot image. (word offset)
0x24 Attributes See Zynq UltraScale+ MPSoC Partition Attribute Bits
0x28 Section Count The number of sections associated with this partition.
0x2C Checksum Word Offset The location of the checksum table in the boot image. (word offset)
0x30 Image Header Word Offset The location of the corresponding image header in the boot image. (word offset)
0x34 AC Offset The location of the corresponding Authentication Certificate in the boot image, if present (word offset)
0x38 Partition Number/ID Partition ID.
0x3C Header Checksum A sum of the previous words in the Partition Header.

Zynq UltraScale+ MPSoC Partition Attribute Bits

The following table describes the Partition Attribute bits on the partition header table for the Zynq® UltraScale+™ MPSoC.

Table 16. Zynq® UltraScale+™ MPSoC Device Partition Attribute Bits
Bit Offset Field Name Description
31:24 Reserved
23 Vector Location Location of exception vector.
  • 0: LOVEC (default)
  • 1: HIVEC
22:20 Reserved
19 Early Handoff
Handoff immediately after loading:
  • 0: No Early Handoff
  • 1: Early Handoff Enabled
18 Endianness
  • 0: Little Endian
  • 1: Big Endian
17:16 Partition Owner
  • 0: FSBL
  • 1: U-Boot
  • 2 and 3: Reserved
15 RSA Authentication Certificate present
  • 0: No RSA Authentication Certificate
  • 1: RSA Authentication Certificate
14:12 Checksum Type
  • 0: None
  • 1-2: Reserved
  • 3: SHA3
  • 4-7: Reserved
11:8 Destination CPU
  • 0: None
  • 1: A53-0
  • 2: A53-1
  • 3: A53-2
  • 4: A53-3
  • 5: R5-0
  • 6: R5 -1
  • 7 R5-lockstep
  • 8: PMU
  • 9-15: Reserved
7 Encryption Present
  • 0: Not Encrypted
  • 1: Encrypted
6:4 Destination Device
  • 0: None
  • 1: PS
  • 2: PL
  • 3-15: Reserved
3 A5X Exec State
  • 0: AARCH64 (default)
  • 1: AARCH32
2:1 Exception Level
  • 0: EL0
  • 1: EL1
  • 2: EL2
  • 3: EL3
0 Trustzone
  • 0: Non-secure
  • 1: Secure

Zynq UltraScale+ MPSoC Authentication Certificates

The Authentication Certificate is a structure that contains all the information related to the authentication of a partition. This structure has the public keys and the signatures that BootROM/FSBL needs to verify. There is an Authentication Header in each Authentication Certificate, which gives information like the key sizes, algorithm used for signing, and so forth. The Authentication Certificate is appended to the actual partition, for which authentication is enabled. If authentication is enabled for any of the partitions, the header tables also needs authentication. The Header Table Authentication Certificate is appended at end of the content to the header tables.

The Zynq® UltraScale+™ MPSoC uses RSA-4096 authentication, which means the primary and secondary key sizes are 4096-bit. The following table provides the format of the Authentication Certificate for the Zynq UltraScale+ MPSoC device.

Table 17. Zynq UltraScale+ MPSoC Device Authentication Certificates
Authentication Certificate
0x00 Authentication Header = 0x0101000. See Zynq UltraScale+ MPSoC Authentication Certification Header.
0x04 SPK ID
0x08 UDF (56 bytes)
0x40 PPK Mod (512)
0x240 Mod Ext (512)
0x440 Exponent (4 bytes)
0x444 Pad (60 bytes)
0x480 SPK Mod (512 bytes)
0x680 Mod Ext (512 bytes)
0x880 Exponent (4 bytes)
0x884 Pad (60 bytes)
0x8C0 SPK Signature = RSA-4096 ( PSK, Padding || SHA-384 (SPK + Authentication Header + SPK-ID))
0xAC0 Boot Header Signature = RSA-4096 ( SSK, Padding || SHA-384 (Boot Header))
0xCC0 Partition Signature = RSA-4096 ( SSK, Padding || SHA-384 (Partition || Padding || Authentication Header || UDF || PPK || SPK || SPK Signature))
Note: FSBL Signature is calculated as follows:
FSBL Signature = RSA-4096 ( SSK, Padding || SHA-384 (PMUFW || FSBL ||
Padding || Authentication Header || UDF || PPK || SPK || SPK Signature)

Zynq UltraScale+ MPSoC Authentication Certification Header

The following table describes the Authentication Header bit fields for the Zynq® UltraScale+™ MPSoC device.

Table 18. Authentication Header Bit Fields
Bit Field Description Notes
31:20 Reserved 0
19:18 SPK/User eFuse Select
  • 01: SPK eFuse
  • 10: User eFuse
17:16 PPK Key Select
  • 0: PPK0
  • 1: PPK1
15:14 Authentication Certificate Format 00: PKCS #1 v1.5
13:12 Authentication Certificate Version 00: Current AC
11 PPK Key Type 0: Hash Key
10:9 PPK Key Source 0: eFUSE
8 SPK Enable 1: SPK Enable
7:4 Public Strength
  • 0 : 2048b
  • 1 : 4096
  • 2:3 : Reserved
3:2 Hash Algorithm
  • 1: SHA3/384
  • 2:3 Reserved
1:0 Public Algorithm
  • 0: Reserved
  • 1: RSA
  • 2: Reserved
  • 3: Reserved

Zynq UltraScale+ MPSoC Secure Header

When you choose to encrypt a partition, Bootgen appends the secure header to that partition. The secure header, contains the key/iv used to encrypt the actual partition. This header in-turn is encrypted using the device key and iv. The Zynq UltraScale+ MPSoC secure header is shown in the following table.

Figure 4: Zynq UltraScale+ MPSoC Secure Header

Zynq UltraScale+ MPSoC Boot Image Block Diagram

The following is a diagram of the components that can be included in a Zynq® UltraScale+™ MPSoC boot image.
Figure 5: Zynq UltraScale+ MPSoC Device Boot Image Block Diagram

Versal ACAP Boot Image Format

The following is a diagram of the components that can be included in a Versal™ ACAP boot image called Programmable Device Image (PDI).

Platform Management Controller

The platform management controller (PMC) in Versal ACAP is responsible for platform management of the Versal ACAP, including boot and configuration. This chapter is focused on the boot image format processed by the two PMC MicroBlaze processors, the ROM code unit (RCU), and the platform processing unit (PPU):

RCU
The ROM code unit contains a triple-redundant MicroBlaze processor and read-only memory (ROM) which contains the executable BootROM. The BootROM executable is metal-masked and unchangeable. The MicroBlaze processor in the RCU is responsible for validating and running the BootROM executable. The RCU is also responsible for post-boot security monitoring and physical unclonable function (PUF) management.
PPU
The platform processing unit contains a triple-redundant MicroBlaze processor and 384 KB of dedicated PPU RAM. The MicroBlaze in the PPU is responsible for running the platform loader and manager (PLM).

In Versal ACAP, the adaptable engine (PL) consists of rCDO and rNPI files. The rCDO file mainly contains CFrame data along with PL and NoC power domain initialization commands. The rNPI file contains configuration data related to the NPI blocks. NPI blocks include NoC elements: NMU, NSU, NPS, NCRB; DDR, XPHY, XPIO, GTY, MMCMs, and so on.

Figure 6: Versal ACAP Boot Image Block Diagram

Versal ACAP Boot Header

Boot header is used by PMC BootROM. Based on the attributes set in the boot header, PMC BootROM validates the Platform Loader and Manager (PLM) and loads it to the PPU RAM. The first 16 bytes are intended for SelectMAP Bus detection. PMC BootROM and PLM ignore this data so Bootgen does not include this data in any of its operations like checksum/SHA/RSA/Encryption and so on. The following code snippet is an example of SelectMAP Bus width detection pattern bits. Bootgen places the following data in first 16-bytes as per the width selected.

The individual image header width and the corresponding bits are shown in the following list:
X8
[LSB] 00 00 00 DD 11 22 33 44 55 66 77 88 99 AA BB CC [MSB]
X16
[LSB] 00 00 DD 00 22 11 44 33 66 55 88 77 AA 99 CC BB [MSB]
X32
[LSB] DD 00 00 00 44 33 22 11 88 77 66 55 CC BB AA 99 [MSB]
Note: The default SelectMAP width is X32.

The following table shows the boot header format for a Versal™ ACAP.

Table 19. Versal ACAP Boot Header Format
Offset (Hex) Size (Bytes) Description Details
0x00 16 SelectMAP bus width Used to determine if the SelectMAP bus width is x8, x16, or x32
0x10 4 QSPI bus width QSPI bus width description. This is required to identify the QSPI flash in single/dual stacked or dual parallel mode. 0xAA995566 in the little endian format.
0x14 4 Image identification Boot image identification string. Contains 4 bytes X, N, L, X in byte order, which is 0x584c4e58 in the little endian format.
0x18 4 Encryption key source This field is used to identify the AES key source: 0x00000000

0x00000000 - Unencrypted

0xA5C3C5A3 - eFUSE red key

0xA5C3C5A5 - eFUSE black key

0x3A5C3C5A - BBRAM red key

0x3A5C3C59 - BBRAM black key

0xA35C7C53 - Boot Header black key
0x1C 4 PLM source offset PLM source start address in PDI
0x20 4 PMC data load address PMC CDO address to load
0x24 4 PMC data length PMC CDO length
0x28 4 Total PMC data length PMC CDO length including authentication and encryption overhead
0x2C 4 PLM length PLM original image size
0x30 4 Total PLM length PLM image size including the authentication and encryption overhead
0x34 4 Boot header attributes Boot Header Attributes
0x38 32 Black key 256-bit key, only valid when encryption status is set to black key in boot header
0x58 12 Black IV Initialization vector used when decrypting the black key
0x64 12 Secure header IV Secure header initialization vector
0x70 4 PUF shutter value Length of the time the PUF samples before it closes the shutter
Note: This shutter value must match the shutter value that was used during PUF registration.
0x74 12

Secure Header IV for PMC Data

 The IV used to decrypt secure header of PMC data.
0x80 68 Reserved Populate with zeroes.
0xC4 4 Meta Header Offset Offset to the start of meta header.
0xC8-0x124 96 Reserved
0x128 2048 Register init Stores register write pairs for system register initialization
0x928 1544 PUF helper data PUF helper data
0xF30 4 Checksum Header checksum
0xF34 76 SHA3 padding SHA3 standard padding

Boot Header Attributes

The image attributes are described in the following table.

Table 20. Versal ACAP Boot Header Attributes

Field Name

Bit Offset

Width

Default Value

Description
Reserved [31:18] 14 0x0 Reserved for future use, Must be 0
PUF Mode [17:16] 2 0x0

0x3 - PUF 4K mode.

0x0 - PUF 12K mode.

Boot Header Authentication

 [15:14] 2 0x0 0x3 - Authentication of the boot image is done, excluding verification of PPK hash and SPK ID.

All others - Authentication will be decided based on eFUSE RSA/ECDSA bits.
Reserved [13:12] 2 0x0 Reserved for future use, Must be 0
DPA counter measure [11:10] 2 0x0 0x3 - Enabled

All others disabled.(eFUSE over rides this)

Checksum selection

 [9:8] 2 0x0

0x0, 0x1, 0x2 - Reserved

0x3 - SHA3 is used as hash function to do Checksum.
PUF HD [7:6] 2 0x0

0x3 - PUF HD is part of boot header

All other - PUF HD is in eFUSE.
Reserved [5:0] 6 0x0 Reserved

Versal ACAP Image Header Table

The following table contains generic information related to the PDI image.

Table 21. Versal ACAP Image Header Table
Offset Name Description
0x0 Version

0x00030000(v3.0): updated secure chunk size to 32 KB from 64 KB

0x00020000(v2.00)
0x4 Total Number of Images Total number of images in the PDI
0x8 Image header offset Address to start of first image header
0xC Total Number of Partitions Total number of partitions in the PDI
0x10 Partition Header Offset Offset to the start of partitions headers
0x14 Secondary boot device address

Indicates the address where secondary image is present.

This is only valid if secondary boot device is present in attributes
0x1C Image Header Table Attributes Refer to Versal ACAP Image Header Table Attributes
0x20 PDI ID Used to identify a PDI
0x24 Parent ID ID of initial boot PDI. For boot PDI, it will be same as PDI ID
0x28 Identification string

Full PDI if present with boot header – “FPDI”

Partial/Sub-system PDI – “PPDI”
0x2C Headers size

0-7: Image header table size in words

8-15: Image header size in words

16-23: Partition header size in words

24-31: Reserved
0x30 Total meta header length Including authentication and encryption overhead (excluding IHT and including AC)
0x34 -0x3C IV for encryption of meta header IV for decrypting SH of header table
0x40 Encryption status Encryption key source, only key source used for PLM is valid for meta header.

0x00000000 - Unencrypted

0xA5C3C5A3 - eFuse red key

0xA5C3C5A5 - eFUSE black key

0x3A5C3C5A - BBRAM red key

0x3A5C3C59 - BBRAM black key

0xA35C7C53 - Boot Header black key
0x48 Meta Header AC Offset (Word) Word Offset to Meta Header Authentication Certificate
0x4c Meta Header Black/IV IV that is used to encrypt the Black key used to encrypt the Meta Header.
0x44 - 0x78 Reserved 0x0
0x7C Checksum A sum of all the previous words in the image header table

Image Header Table Attributes

The image header tables are described in the following table.

Table 22. Versal ACAP Image Header Table Attributes
Bit Field Name Description
31:14 Reserved 0
14 PUF Helper Data Location Location of the PUF Helper Data efuse/BH
12 dpacm enable DPA Counter Measure enable or not
11:6 Secondary boot device

Indicates the device on which rest of the data is present in.

0 - Same boot device (default)

1 - QSPI32

2 - QSPI24

3 - NAND

4 - SD0

5 - SD1

6 - SDLS

7 - MMC

8 - USB

9 - ETHERNET

10 - PCIe

11 - SATA

12 - OSPI

13 - SMAP

14 - SBI

15 - SD0RAW

16 - SD1RAW

17 - SDLSRAW

18 - MMCRAW

19 - MMC0

20 - MMC0RAW

All others are reserved

Note: These options are supported for various devices in Bootgen. For the exact list of secondary boot devices supported by any device, refer to its corresponding SSDG.
5:0 Reserved

Versal ACAP Image Header

The image header is an array of structures containing information related to each image, such as an ELF file, CFrame, NPI, CDOs, data files, and so forth. Each image can have multiple partitions, for example, an ELF can have multiple loadable sections, each of which form a partition in the boot image. An image header points to the partitions (partition headers) that are associated with this image. Multiple partition files can be grouped within an image using the BIF keyword "image"; this is useful for combining all the partitions related to a common subsystem or function in a group. Bootgen creates the required partitions for each file and creates a common image header for that image. The following table contains the information of number of partitions related to an image.

Table 23. Versal ACAP Image Header
Offset Name Description
0x0 First Partition Header Word offset to first partition header
0x4 Number of Partitions Number of partitions present for this image
0x8 Revoke ID Revoke ID for Meta Header
0xC Image Attributes See Image Attributes table
0x10-0x1C Image Name ASCII name of the image. Max of 16 characters. Fill with Zeros when padding is required.
0x20 Image/Node ID Defines the resource node the image is initializing
0x24 Unique ID Defines the affinity/compatibility identifier when required for a given device resource
0x28 Parent Unique ID Defines the required parent resource UID for the configuration content of the image, if required
0x2c Function ID Identifier used to capture the unique function of the image configuration data
0x30 DDR Low Address for Image Copy The DDR lower 32-bit address where the image should be copied when memcpy is enabled in BIF
0.34 DDR High Address for Image Copy The DDR higher 32-bit address where image should be copied when memcpy is enabled in BIF
0x38 Reserved
0x3C Checksum A sum of all the previous words.

The following table shows the Image Header Attributes.

Table 24. Versal ACAP Image Header Attributes
Bit Field Name Description
31:9 Reserved 0
8 Delay Hand off

0 – Handoff the image now (default)

1 – Handoff the image later
7 Delay load

0 – Load the image now (default)

1 – Load the image later
6 Copy to memory

0 – No copy to memory (Default)

1 – Image to be copied to memory
5:3 Image Owner

0 - PLM (default)

1 - Non-PLM

2-7 – Reserved
2:0 Reserved 0

Versal ACAP Partition Header

The partition header contains details of the partition and is described in the table below.

Table 25. Versal ACAP Partition Header Table
Offset Name Description
0x0 Partition Data Word Length Encrypted partition data length
0x4 Extracted Data Word Length Unencrypted data length
0x8 Total Partition Word Length (Includes Authentication Certificate) The total encrypted + padding + expansion + authentication length
0xC Next Partition header offset Offset of next partition header
0x10 Destination Execution Address (Lower Half) The lower 32 bits of the executable address of this partition after loading.
0x14 Destination Execution Address (Higher Half) The higher 32 bits of the executable address of this partition after loading.
0x18 Destination Load Address (Lower Half) The lower 32 bits of the RAM address into which this partition is to be loaded. For elf files Bootgen will automatically read from elf format. For RAW data users has to specify where to load it. For CFI and configuration data it should be 0xFFFF_FFFF
0x1C Destination Load Address (Higher Half) The higher 32 bits of the RAM address into which this partition is to be loaded. For elf files Bootgen will automatically read from elf format. For RAW data users has to specify where to load it. For CFI and configuration data it should be 0xFFFF_FFFF
0x20 Data Word Offset in Image The position of the partition data relative to the start of the boot image.
0x24 Attribute Bits See Partition Attributes Table
0x28 Section Count If image type is elf, it says how many more partitions are associated with this elf.
0x2C Checksum Word Offset The location of the checksum word in the boot image.
0x30 Partition ID Partition ID
0x34 Authentication Certification Word Offset The location of the Authentication Certification in the boot image.
0x38 – 0x40 IV IV for the secure header of the partition.
0x44 Encryption Key select

Encryption status:

  • 0x00000000 – Unencrypted
  • 0xA5C3C5A3 - eFuse Red Key
  • 0xA5C3C5A5 - eFuse Black Key
  • 0x3A5C3C5A - BBRAM Red Key
  • 0x3A5C3C59 - BBRAM Black Key
  • 0xA35C7C53 - Boot Header Black Key
  • 0xC5C3A5A3 - User Key 0
  • 0xC3A5C5B3 - User Key 1
  • 0xC5C3A5C3 - User Key 2
  • 0xC3A5C5D3 - User Key 3
  • 0xC5C3A5E3 - User Key 4
  • 0xC3A5C5F3 - User Key 5
  • 0xC5C3A563 - User Key 6
  • 0xC3A5C573 - User Key 7
  • 0x5C3CA5A3 - eFuse User Key 0
  • 0x5C3CA5A5 - eFuse User Black Key 0
  • 0xC3A5C5A3 - eFuse User Key 1
  • 0xC3A5C5A5 - eFuse User Black Key 1
0x48 Black IV IV used for encrypting the key source of that partition.
0x54 Revoke ID Partition revoke ID
0x58-0x78 Reserved 0
0x7C Header Checksum A sum of the previous words in the Partition Header

The following table lists the partition header table attributes.

Table 26. Versal ACAP Partition Header Table Attributes
Bit Field Name Description
31:29 Reserved 0x0
28:27 DPA CM Enable

0 – Disabled

1 – Enabled
26:24 Partition Type

0 – Reserved

1 - elf

2 - Configuration Data Object

3 - Cframe Data (PL data)

4 – Raw Data

5 – Raw elf

6 – CFI GSR CSC unmask frames

7 – CFI GSR CSC mask frames
23 HiVec

VInitHi setting for RPU/APU(32-bit) processor

0 – LoVec

1 – HiVec
22:19 Reserved 0
18 Endianness

0 – Little Endian (Default)

1 – Big Endian
17:16 Partition Owner

0 - PLM (Default)

1 - Non-PLM

2,3 – Reserved
15:14 PUF HD location

0 - eFuse

1 - Boot header
13:12 Checksum Type

000b - No Checksum(Default)

011b – SHA3
11:8 Destination CPU

0 – None (Default for non-elf files)

1 - A72-0

2 - A72-1

3 - Reserved

4 - Reserved

5 - R5-0

6 - R5-1

7- R5-L

8 – PSM

9 - AIE

10-15 – Reserved
3 A72 CPU execution state

0 - Aarch64 (default)

1 - Aarch32
2:1 Exception level (EL) the A72 core should be configured for

00b – EL0

01b – EL1

10b – EL2

11b – EL3 (Default)
0 TZ secure partition

0 – Non-Secure (Default)

1 – Secure

This bit indicates if the core that the PLM needs to configure (on which this partition needs to execute) should be configured as TrustZone secure or not. By default, this should be 0.

Versal ACAP Authentication Certificates

The Authentication Certificate is a structure that contains all the information related to the authentication of a partition. This structure has the public keys and the signatures that BootROM/PLM needs to verify. There is an Authentication Header in each Authentication Certificate, which gives information like the key sizes, algorithm used for signing, and so forth. Unlike the other devices, the Authentication Certificate is prepended or attached to the beginning of the actual partition, for which authentication is enabled. If you want Bootgen to perform authentication on the meta headers, specify it explicitly under the ‘metaheader’ bif attribute. See BIF Attribute Reference for information on usage.

Versal ACAP uses RSA-4096 authentication and ECDSA algorithms for authentication. The following table provides the format of the Authentication Certificate for the Versal ACAP.

Table 27. Versal ACAP Authentication Certificate – ECDSA p384
Authentication Certificate Bits Description
0x00 Authentication Header. See Versal ACAP Authentication Certification Header
0x04 Revoke ID
0x08 UDF (56 bytes)
0x40 PPK x (48 bytes)
y (48 bytes)
Pad 0x00 (932 bytes)
0x444 PPK SHA3 Pad (12 bytes)
0x450 SPK x (48 bytes)
y (48 bytes)
Pad 0x00 (932 bytes)
0x854 SPK SHA3 Pad (4 bytes)
0x858 Alignment (8 bytes)
0x860 SPK Signature(r+s+pad)(48+48+416)
0xA60 BH/IHT Signature(r+s+pad)(48+48+416)
0xC60 Partition Signature(r+s+pad)(48+48+416)
Table 28. Versal ACAP Authentication Certificate – ECDSA p521
Authentication Certificate Bits Description
0x00 Authentication Header. See Versal ACAP Authentication Certification Header
0x04 Revoke ID
0x08 UDF (56 bytes)
0x40 PPK PPK x (66 bytes)
y (66 bytes)
Pad 0x00 (896 bytes)
0x444 PPK SHA3 Pad (12 bytes)
0x450 SPK SPK x (66 bytes)
y (66 bytes)
Pad 0x00 (896 bytes)
0x854 SPK SHA3 Pad (4 bytes)
0x858 Alignment (8 bytes)
0x860 SPK Signature(r+s+pad)(66+66+380)
0xA60 BH/IHT Signature(r+s+pad)(66+66+380)
0xC60 Partition Signature(r+s+pad)(66+66+380)
Table 29. Versal ACAP Authentication Certificate – RSA
Authentication Certificate Bits Description
0x00 Authentication Header. See Versal ACAP Authentication Certification Header
0x04 Revoke ID
0x08 UDF (56 bytes)
0x40 PPK Mod (512 bytes)
Mod Ext (512 bytes)
Exponent (4 bytes)
0x444 PPK SHA3 Pad (12 bytes)
0x450 SPK Mod (512 bytes)
Mod Ext (512 bytes)
Exponent (4 bytes)
0x854 SPK SHA3 Pad (4 bytes)
0x858 Alignment (8 bytes)
0x860 SPK Signature
0xA60 BH/IHT Signature
0xC60 Partition Signature

Versal ACAP Authentication Certification Header

The following table describes the Authentication Header bit fields for the Versal ACAP.

Table 30. Authentication Header Bit Fields
Bit Fields Description Notes
31:16 Reserved 0
15-14 Authentication Certificate Format 00 -RSAPSS
13-12 Authentication Certificate Version 00: Current AC
11 PPK Key Type 0: Hash Key
10-9 PPK Key Source 0: eFUSE
8 SPK Enable 1: SPK Enable
7-4 Public Strength

0 - ECDSA p384

1 - RSA 4096

2 - ECDSA p521
3-2 Hash Algorithm 1-SHA3
1-0 Public Algorithm

1-RSA

2-ECDSA
Note:
  1. For the Bootloader partition:
    1. The offset 0xA60 of the AC holds the Boot Header Signature.
    2. The offset 0xC60 of the AC holds the signature of PLM and PMCDATA.
  2. For the Header tables:
    1. The offset 0xA60 of the AC holds the IHT Signature.
    2. The offset 0xC60 of the AC holds the signature of all the headers except IHT.
  3. For any other partition:
    1. The offset 0xA60 of the AC is zeroized.
    2. The offset 0xC60 of the AC holds the signature of that partition.