Vivado/Vitis 2024.1.
Bootgen 2024.1, but I have also tested 2025.1 and the behavior is the same.
I generate FSBL using Vitis, as recommended by AMD.
I compile bl31 from https://github.com/Xilinx/arm-trusted-firmware.git.
I want to boot Linux on ZynqMP (XCZU15EG).
I follow Bootgen User Guide [UG1283 (v2025.1) May 29, 2025], Appendix A: Use Cases and Examples, Zynq MPSoC Use Cases.
My boot.bif looks as follows:
the_ROM_image:
{
[bootloader] fsbl.elf
[pmufw_image] pmufw.elf
[destination_cpu = a53-0, exception_level= el-3, trustzone] bl31.bin
[destination_cpu = a53-0, exception_level= el-2, load = 0x10000000] images/u-boot.bin
}
Which is quite similar to the example from the Bootgen User Guide.
The main difference is that my Linux image is not part of the boot.bin, as I want to use U-Boot script to load Image from the SD partition.
I also had to provide the load attribute, because otherwise I got the following warning:
****** Bootgen v2023.2
**** Build date : Jul 7 2025-09:11:00
** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
** Copyright 2022-2023 Advanced Micro Devices, Inc. All Rights Reserved.
[WARNING]: Partition bl31.bin.0 range is overlapped with partition u-boot.bin.0 memory range
[INFO] : Bootimage generated successfully
With the warning, the U-Boot image is placed in the same partition as ATF (bl31), and ATF is never run.
Why do I need the load attribute, I don't understand.
The example from Bootgen User Guide does not specify load attribute for the U-Boot image.
However, the load attribute mystery is a minor issue.
The major issue is that the ATF handoff parameters for bl31 are never set by FSBL because the execution address of all partitions, except FSBL, is 0.
Take a look at the following snippet from the xfsbl_image_header.c file, function XFsbl_ReadImageHeader.
/**
* Assumption: Next partition corresponds to ATF
* 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
*/
CurrPartitionHdr = &ImageHeader->PartitionHeader[PartitionIndex];
GetDstnCpu = XFsbl_GetDestinationCpu(CurrPartitionHdr);
/* if destination cpu is not present, it means it is for same cpu */
if (GetDstnCpu == XIH_PH_ATTRB_DEST_CPU_NONE)
{
DestnCPU = RunningCpu;
}
else
{
DestnCPU = GetDstnCpu;
}
if ((PartitionIndex > 1U) && (EntryCount < XFSBL_MAX_ENTRIES_FOR_ATF) &&
(CurrPartitionHdr->DestinationExecutionAddress != 0U) &&
(((DestnCPU >= XIH_PH_ATTRB_DEST_CPU_A53_0) &&
(DestnCPU <= XIH_PH_ATTRB_DEST_CPU_A53_3))))
{
/**
* Populate handoff parameters to ATF
* These correspond to the partition of application
* which ATF will be loading
*/
XFsbl_SetATFHandoffParameters(CurrPartitionHdr, EntryCount);
EntryCount++;
}
/**
* Update the next partition present address
*/
PartitionHeaderAddress =
(ImageHeader->PartitionHeader[PartitionIndex].NextPartitionOffset)
* XIH_PARTITION_WORD_LENGTH;
}
/**
* After setting handoff parameters of all partitions to ATF,
* store address of the structure in PMU_GLOBAL.GLOBAL_GEN_STORAGE6.
*/
XFsbl_Out32(PMUy_GLOBAL_GLOB_GEN_STORAGE6, (u32)((PTRSIZE) &ATFHandoffParams));
END:
return Status;
}The comment claims that the first partiion of an application will have a non zero execution address.
The same condition is checked in the if statement.
However, bootgen doesn't set execution address for the U-Boot image specified in the boot.bif file.
Here is the output of the bootgen -read boot.bin command.
****** Bootgen v2025.1-Merged
**** Build date : Jul 8 2025-08:53:17
** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
** Copyright 2022-2025 Advanced Micro Devices, Inc. All Rights Reserved.
--------------------------------------------------------------------------------
BOOT HEADER
--------------------------------------------------------------------------------
boot_vectors (0x00) : 0x1400000014000000140000001400000014000000140000001400000014000000
width_detection (0x20) : 0xaa995566
image_id (0x24) : 0x584c4e58
encryption_keystore (0x28) : 0x00000000
header_version (0x2c) : 0xfffc0000
fsbl_sourceoffset (0x30) : 0x00002800
fsbl_length (0x34) : 0x0001fae0
fsbl_load_address (0x38) : 0x0001fae0
fsbl_exec_address (0x3C) : 0x00021030
fsbl_total_length (0x40) : 0x00021030
qspi_config-word (0x44) : 0x00000800
checksum (0x48) : 0xfd161621
iht_offset (0x98) : 0x000008c0
pht_offset (0x9c) : 0x00001100
--------------------------------------------------------------------------------
IMAGE HEADER TABLE
--------------------------------------------------------------------------------
version (0x00) : 0x01020000 total_images (0x04) : 0x00000003
pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900
hdr_ac_offset (0x10) : 0x00000000
--------------------------------------------------------------------------------
IMAGE HEADER (fsbl.elf)
--------------------------------------------------------------------------------
next_ih(W) (0x00) : 0x00000250
next_pht(W) (0x04) : 0x00000440
total_partitions (0x0c) : 0x00000001
name (0x10) : fsbl.elf
--------------------------------------------------------------------------------
IMAGE HEADER (bl31.bin)
--------------------------------------------------------------------------------
next_ih(W) (0x00) : 0x00000260
next_pht(W) (0x04) : 0x00000450
total_partitions (0x0c) : 0x00000001
name (0x10) : bl31.bin
--------------------------------------------------------------------------------
IMAGE HEADER (u-boot.bin)
--------------------------------------------------------------------------------
next_ih(W) (0x00) : 0x00000000
next_pht(W) (0x04) : 0x00000460
total_partitions (0x0c) : 0x00000001
name (0x10) : u-boot.bin
--------------------------------------------------------------------------------
PARTITION HEADER TABLE (fsbl.elf.0)
--------------------------------------------------------------------------------
encrypted_length (0x00) : 0x000102c4 unencrypted_length (0x04) : 0x000102c4
total_length (0x08) : 0x000102c4 load_addr (0x0c) : 0x00000450
exec_addr (0x10) : 0xfffc0000 partition_offset (0x14) : 0x00000000
attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000
checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000016
ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x0004e70c
attribute list -
trustzone [non-secure] el [el-0]
exec_state [aarch-64] dest_device [none]
encryption [no] core [none]
--------------------------------------------------------------------------------
PARTITION HEADER TABLE (bl31.bin.0)
--------------------------------------------------------------------------------
encrypted_length (0x00) : 0x00003c29 unencrypted_length (0x04) : 0x00003c29
total_length (0x08) : 0x00003c29 load_addr (0x0c) : 0x00000460
exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000
attributes (0x18) : 0x00000000 section_count (0x1C) : 0x00000000
checksum_offset (0x20) : 0x00010cd0 iht_offset (0x24) : 0x00000117
ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0xfffe36eb
attribute list -
trustzone [non-secure] el [el-0]
exec_state [aarch-64] dest_device [none]
encryption [no] core [none]
--------------------------------------------------------------------------------
PARTITION HEADER TABLE (u-boot.bin.0)
--------------------------------------------------------------------------------
encrypted_length (0x00) : 0x00056c64 unencrypted_length (0x04) : 0x00056c64
total_length (0x08) : 0x00056c64 load_addr (0x0c) : 0x00000000
exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000
attributes (0x18) : 0x10000000 section_count (0x1C) : 0x00000000
checksum_offset (0x20) : 0x00014900 iht_offset (0x24) : 0x00000114
ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0xefee6e5c
attribute list -
trustzone [non-secure] el [el-0]
exec_state [aarch-64] dest_device [none]
encryption [no] core [none]
--------------------------------------------------------------------------------
AUTHENTICATION CERTIFICATE (fsbl.elf.0)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
AUTHENTICATION CERTIFICATE (bl31.bin.0)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
AUTHENTICATION CERTIFICATE (u-boot.bin.0)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
As can be seen, both bl31.bin.0 and u-boot.bin.0 partitions have exec_addr set to 0.
I have added some custom log messages to both FSBL and bl31.
The FSBL indeed doesn't set any handoff parameters for ATF.
The EntryCount value before calling XFsbl_Out32(PMUy_GLOBAL_GLOB_GEN_STORAGE6, (u32)((PTRSIZE) &ATFHandoffParams)); equals 0.
The bl31 reports an error claiming the handoff structure is invalid.
BL31: invalid handoff structure at fffe9e00
BACKTRACE: START: bl31_early_platform_setup2
0: F_FUNCTION: 0x2880
1: F_FUNCTION: 0x34b4
2: F_FUNCTION: 0x108
3: F_FUNCTION: 0xfffcd8f8
BACKTRACE: END: bl31_early_platform_setup2
This is clearly a bug.
Either in the bootgen or in FSBL.
Vivado/Vitis 2024.1.
Bootgen 2024.1, but I have also tested 2025.1 and the behavior is the same.
I generate FSBL using Vitis, as recommended by AMD.
I compile bl31 from https://github.com/Xilinx/arm-trusted-firmware.git.
I want to boot Linux on ZynqMP (XCZU15EG).
I follow Bootgen User Guide [UG1283 (v2025.1) May 29, 2025], Appendix A: Use Cases and Examples, Zynq MPSoC Use Cases.
My
boot.biflooks as follows:Which is quite similar to the example from the Bootgen User Guide.
The main difference is that my Linux image is not part of the boot.bin, as I want to use U-Boot script to load Image from the SD partition.
I also had to provide the
loadattribute, because otherwise I got the following warning:With the warning, the U-Boot image is placed in the same partition as ATF (bl31), and ATF is never run.
Why do I need the
loadattribute, I don't understand.The example from Bootgen User Guide does not specify
loadattribute for the U-Boot image.However, the
loadattribute mystery is a minor issue.The major issue is that the ATF handoff parameters for bl31 are never set by FSBL because the execution address of all partitions, except FSBL, is 0.
Take a look at the following snippet from the
xfsbl_image_header.cfile, functionXFsbl_ReadImageHeader.The comment claims that the first partiion of an application will have a non zero execution address.
The same condition is checked in the if statement.
However,
bootgendoesn't set execution address for the U-Boot image specified in theboot.biffile.Here is the output of the
bootgen -read boot.bincommand.As can be seen, both
bl31.bin.0andu-boot.bin.0partitions haveexec_addrset to 0.I have added some custom log messages to both FSBL and bl31.
The FSBL indeed doesn't set any handoff parameters for ATF.
The
EntryCountvalue before callingXFsbl_Out32(PMUy_GLOBAL_GLOB_GEN_STORAGE6, (u32)((PTRSIZE) &ATFHandoffParams));equals 0.The bl31 reports an error claiming the handoff structure is invalid.
This is clearly a bug.
Either in the bootgen or in FSBL.