zynqmpbif - sample

hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
thanks Jorge

Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
Thanks, Michal

On 13/07/21, Michal Simek wrote:
Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
awesome, exactly what I needed to start with.
Thanks, Michal

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
thanks Jorge
Thanks, Michal

On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
Thanks, Michal

On 13/07/21, Michal Simek wrote:
On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
weird, I can not boot the bin when using bootgen 2019 nor 2021.
please can you send me the output of the following command so I can compare? vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin
also, are you booting from QSPI?
thanks a lot!
Thanks, Michal

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
hi Michal,
Would you have some sample/reference code to generate a SPL boot image using zynqmpbif instead of zynqmpimage? I cant find any documentation and I see no option to enable it (I was expecting to find some config in Makefile.spl but I see none).
What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
weird, I can not boot the bin when using bootgen 2019 nor 2021.
please can you send me the output of the following command so I can compare? vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin
also, are you booting from QSPI?
thanks a lot!
just for reference:
$ cat bif the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.elf [destination_cpu=a53-1, load=0xfffc0000, bootloader] u-boot-spl-align.bin }
BOOTGEN ========
$./bootgen -arch zynqmp -image ./bif -w -o bootbif.bin
will generate this image:
$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, 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) : 0x00000000 fsbl_sourceoffset (0x30) : 0x00002800 fsbl_length (0x34) : 0x00000000 fsbl_load_address (0x38) : 0x00000000 fsbl_exec_address (0x3C) : 0x00000000 fsbl_total_length (0x40) : 0x00000000 qspi_config-word (0x44) : 0x00000800 checksum (0x48) : 0xfd1a2c41 iht_offset (0x98) : 0x000008c0 pht_offset (0x9c) : 0x00001100 -------------------------------------------------------------------------------- IMAGE HEADER TABLE -------------------------------------------------------------------------------- version (0x00) : 0x01020000 total_images (0x04) : 0x00000001 pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900 hdr_ac_offset (0x10) : 0x00000000 -------------------------------------------------------------------------------- IMAGE HEADER (u-boot-spl-align.bin) -------------------------------------------------------------------------------- next_ih(W) (0x00) : 0x00000000 next_pht(W) (0x04) : 0x00000440 total_partitions (0x08) : 0x00000000 total_partitions (0x0c) : 0x00000001 name (0x10) : u-boot-spl-align.bin -------------------------------------------------------------------------------- PARTITION HEADER TABLE (u-boot-spl-align.bin.0) -------------------------------------------------------------------------------- encrypted_length (0x00) : 0x0000815d unencrypted_length (0x04) : 0x0000815d total_length (0x08) : 0x0000815d load_addr (0x0c) : 0x00000000 exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000 attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000 checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000216 ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x00026d91 attribute list - trustzone [non-secure] el [el-0] exec_state [aarch-64] dest_device [none] encryption [no] core [none] -------------------------------------------------------------------------------- AUTHENTICATION CERTIFICATE (u-boot-spl-align.bin.0) -------------------------------------------------------------------------------- --------------------------------------------------------------------------------
which will NOT boot (the fsbl information in the bootheader seems a source of concern but I dont know...hence why I was asking before about the one it worked for you)
MKIMAGE ========
Using mkimage - as you indicated- we can generate an image that will boot from QSPI
./mkimage -T zynqmpbif -d bif bootbif.bin
Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 132468 bytes (132468 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd164999
But the bin image is NOT readable by bootgen
jramirez@trex bootgen_bif (master *%)$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved.
[ERROR] : Error reading Image header
So both utilities do generate different bootheaders and layouts.
The layout that doesnt boot - the one generated with bootgen - is the one documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1283-...
And the one that does work - using a boot header not readable by bootgen!- is not documented anywhere AFAIK.
I am confused at this point.
Is there any public information about the bootrom? does the above information make sense to you?
Thanks, Michal

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
Hi,
On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote: > hi Michal, > > Would you have some sample/reference code to generate a SPL boot image > using zynqmpbif instead of zynqmpimage? I cant find any documentation > and I see no option to enable it (I was expecting to find some config > in Makefile.spl but I see none). > > What is the expected way of building these images?
Alex implemented it for Xilinx bif format after origin zynqmpimage format. But usage is just like this.
[u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif /tmp/boot.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 147216 bytes (147216 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd15d661 [u-boot](debian-sent)$ cat /tmp/bif image : { [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin }
awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
weird, I can not boot the bin when using bootgen 2019 nor 2021.
please can you send me the output of the following command so I can compare? vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin
also, are you booting from QSPI?
thanks a lot!
just for reference:
$ cat bif the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.elf [destination_cpu=a53-1, load=0xfffc0000, bootloader] u-boot-spl-align.bin }
BOOTGEN
$./bootgen -arch zynqmp -image ./bif -w -o bootbif.bin
will generate this image:
$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, 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) : 0x00000000 fsbl_sourceoffset (0x30) : 0x00002800 fsbl_length (0x34) : 0x00000000 fsbl_load_address (0x38) : 0x00000000 fsbl_exec_address (0x3C) : 0x00000000 fsbl_total_length (0x40) : 0x00000000 qspi_config-word (0x44) : 0x00000800 checksum (0x48) : 0xfd1a2c41 iht_offset (0x98) : 0x000008c0 pht_offset (0x9c) : 0x00001100
IMAGE HEADER TABLE
version (0x00) : 0x01020000 total_images (0x04) : 0x00000001 pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900 hdr_ac_offset (0x10) : 0x00000000
IMAGE HEADER (u-boot-spl-align.bin)
next_ih(W) (0x00) : 0x00000000 next_pht(W) (0x04) : 0x00000440 total_partitions (0x08) : 0x00000000 total_partitions (0x0c) : 0x00000001 name (0x10) : u-boot-spl-align.bin
PARTITION HEADER TABLE (u-boot-spl-align.bin.0)
encrypted_length (0x00) : 0x0000815d unencrypted_length (0x04) : 0x0000815d total_length (0x08) : 0x0000815d load_addr (0x0c) : 0x00000000 exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000 attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000 checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000216 ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x00026d91
attribute list - trustzone [non-secure] el [el-0] exec_state [aarch-64] dest_device [none] encryption [no] core [none]
AUTHENTICATION CERTIFICATE (u-boot-spl-align.bin.0)
which will NOT boot (the fsbl information in the bootheader seems a source of concern but I dont know...hence why I was asking before about the one it worked for you)
MKIMAGE
Using mkimage - as you indicated- we can generate an image that will boot from QSPI
./mkimage -T zynqmpbif -d bif bootbif.bin
Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 132468 bytes (132468 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd164999
But the bin image is NOT readable by bootgen
jramirez@trex bootgen_bif (master *%)$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved.
[ERROR] : Error reading Image header
So both utilities do generate different bootheaders and layouts.
The layout that doesnt boot - the one generated with bootgen - is the one documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1283-...
And the one that does work - using a boot header not readable by bootgen!- is not documented anywhere AFAIK.
I am confused at this point.
Is there any public information about the bootrom? does the above information make sense to you?
um, I dont think bootgen can boot spl.bin...seems we need an elf
Thanks, Michal

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote: > Hi, > > On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote: >> hi Michal, >> >> Would you have some sample/reference code to generate a SPL boot image >> using zynqmpbif instead of zynqmpimage? I cant find any documentation >> and I see no option to enable it (I was expecting to find some config >> in Makefile.spl but I see none). >> >> What is the expected way of building these images? > > Alex implemented it for Xilinx bif format after origin zynqmpimage > format. But usage is just like this. > > [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif > /tmp/boot.bin > Image Type : Xilinx ZynqMP Boot Image support > Image Offset : 0x000009c0 > Image Size : 147216 bytes (147216 bytes packed) > PMUFW Size : 129792 bytes (129792 bytes packed) > Image Load : 0xfffc0000 > Checksum : 0xfd15d661 > [u-boot](debian-sent)$ cat /tmp/bif > image : { > [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf > [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin > }
awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
weird, I can not boot the bin when using bootgen 2019 nor 2021.
please can you send me the output of the following command so I can compare? vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin
also, are you booting from QSPI?
thanks a lot!
just for reference:
$ cat bif the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.elf [destination_cpu=a53-1, load=0xfffc0000, bootloader] u-boot-spl-align.bin }
BOOTGEN
$./bootgen -arch zynqmp -image ./bif -w -o bootbif.bin
will generate this image:
$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, 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) : 0x00000000 fsbl_sourceoffset (0x30) : 0x00002800 fsbl_length (0x34) : 0x00000000 fsbl_load_address (0x38) : 0x00000000 fsbl_exec_address (0x3C) : 0x00000000 fsbl_total_length (0x40) : 0x00000000 qspi_config-word (0x44) : 0x00000800 checksum (0x48) : 0xfd1a2c41 iht_offset (0x98) : 0x000008c0 pht_offset (0x9c) : 0x00001100
IMAGE HEADER TABLE
version (0x00) : 0x01020000 total_images (0x04) : 0x00000001 pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900 hdr_ac_offset (0x10) : 0x00000000
IMAGE HEADER (u-boot-spl-align.bin)
next_ih(W) (0x00) : 0x00000000 next_pht(W) (0x04) : 0x00000440 total_partitions (0x08) : 0x00000000 total_partitions (0x0c) : 0x00000001 name (0x10) : u-boot-spl-align.bin
PARTITION HEADER TABLE (u-boot-spl-align.bin.0)
encrypted_length (0x00) : 0x0000815d unencrypted_length (0x04) : 0x0000815d total_length (0x08) : 0x0000815d load_addr (0x0c) : 0x00000000 exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000 attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000 checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000216 ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x00026d91
attribute list - trustzone [non-secure] el [el-0] exec_state [aarch-64] dest_device [none] encryption [no] core [none]
AUTHENTICATION CERTIFICATE (u-boot-spl-align.bin.0)
which will NOT boot (the fsbl information in the bootheader seems a source of concern but I dont know...hence why I was asking before about the one it worked for you)
MKIMAGE
Using mkimage - as you indicated- we can generate an image that will boot from QSPI
./mkimage -T zynqmpbif -d bif bootbif.bin
Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 132468 bytes (132468 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd164999
But the bin image is NOT readable by bootgen
jramirez@trex bootgen_bif (master *%)$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved.
[ERROR] : Error reading Image header
So both utilities do generate different bootheaders and layouts.
The layout that doesnt boot - the one generated with bootgen - is the one documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1283-...
And the one that does work - using a boot header not readable by bootgen!- is not documented anywhere AFAIK.
I am confused at this point.
Is there any public information about the bootrom? does the above information make sense to you?
um, I dont think bootgen can boot spl.bin...seems we need an elf
so yes, I doubt it can work for you either. I suppose you misread the question.
BTW where is the image layout zynqmpimage or zynqmpbif documented? I am not refereing to the boot header fields - those are clear - but mostly interested about the 0x9c0 address.
We are placing the pmufw at that location (0x9c0) and right after spl.bin...why does this boot? AFAICS it does not follow the documented layout so it shouldnt...
https://www.xilinx.com/html_docs/xilinx2020_2/vitis_doc/bootimagelayout.html...
I'd like to be able to extend zynqmpbif with support for authentication but ATM I am lacking some basic information.
Anything you can share that would be great.

Hi,
On 7/14/21 9:37 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote: > On 13/07/21, Michal Simek wrote: >> Hi, >> >> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote: >>> hi Michal, >>> >>> Would you have some sample/reference code to generate a SPL boot image >>> using zynqmpbif instead of zynqmpimage? I cant find any documentation >>> and I see no option to enable it (I was expecting to find some config >>> in Makefile.spl but I see none). >>> >>> What is the expected way of building these images? >> >> Alex implemented it for Xilinx bif format after origin zynqmpimage >> format. But usage is just like this. >> >> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif >> /tmp/boot.bin >> Image Type : Xilinx ZynqMP Boot Image support >> Image Offset : 0x000009c0 >> Image Size : 147216 bytes (147216 bytes packed) >> PMUFW Size : 129792 bytes (129792 bytes packed) >> Image Load : 0xfffc0000 >> Checksum : 0xfd15d661 >> [u-boot](debian-sent)$ cat /tmp/bif >> image : { >> [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf >> [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin >> } > > awesome, exactly what I needed to start with.
So I can boot using the steps you mentioned above.
But shouldnt the same bif work with bootgen?
****** Xilinx Bootgen v2019.2 **** Build date : Oct 23 2019-22:59:42 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
[TRACE] : Command Line parsing started [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace [INFO] : Command line parsing completed successfully [TRACE] : BIF File: ./bif [TRACE] : BIF file parsing started [TRACE] : Setting PMU FW Image file as pmu.elf [INFO] : BIF file parsing completed successfully [INFO] : Parsing Partition Data to Image [INFO] : Building image - image [INFO] : Building the Partition Header Table [INFO] : After build -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : After align -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump [INFO] : Partition Information: [INFO] : Image: u-boot-spl.bin [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 [INFO] : After Link -- Dump of Binary Image ---- 00000000 Len: 000008b8 Res: 00000000 "BootHeader" 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" -- End of Dump
however when I boot and inspect the processor state, xsdb returns "APU L2 cache is held in reset"
Since the functionality to support RSA authentication is missing from mkimage (I'll have to add that), I would first like to see it functional with SPL using bootgen.
However the same bif doesnt even boot - is this to be expected?
also the layouts generated from the bif using mkimage and bootgen are completely different (it seems that naively I expected them to be the same); is there any information on the different layouts used for the bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
weird, I can not boot the bin when using bootgen 2019 nor 2021.
please can you send me the output of the following command so I can compare? vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin
also, are you booting from QSPI?
thanks a lot!
just for reference:
$ cat bif the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.elf [destination_cpu=a53-1, load=0xfffc0000, bootloader] u-boot-spl-align.bin }
BOOTGEN
$./bootgen -arch zynqmp -image ./bif -w -o bootbif.bin
will generate this image:
$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, 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) : 0x00000000 fsbl_sourceoffset (0x30) : 0x00002800 fsbl_length (0x34) : 0x00000000 fsbl_load_address (0x38) : 0x00000000 fsbl_exec_address (0x3C) : 0x00000000 fsbl_total_length (0x40) : 0x00000000 qspi_config-word (0x44) : 0x00000800 checksum (0x48) : 0xfd1a2c41 iht_offset (0x98) : 0x000008c0 pht_offset (0x9c) : 0x00001100
IMAGE HEADER TABLE
version (0x00) : 0x01020000 total_images (0x04) : 0x00000001 pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900 hdr_ac_offset (0x10) : 0x00000000
IMAGE HEADER (u-boot-spl-align.bin)
next_ih(W) (0x00) : 0x00000000 next_pht(W) (0x04) : 0x00000440 total_partitions (0x08) : 0x00000000 total_partitions (0x0c) : 0x00000001 name (0x10) : u-boot-spl-align.bin
PARTITION HEADER TABLE (u-boot-spl-align.bin.0)
encrypted_length (0x00) : 0x0000815d unencrypted_length (0x04) : 0x0000815d total_length (0x08) : 0x0000815d load_addr (0x0c) : 0x00000000 exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000 attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000 checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000216 ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x00026d91
attribute list - trustzone [non-secure] el [el-0] exec_state [aarch-64] dest_device [none] encryption [no] core [none]
AUTHENTICATION CERTIFICATE (u-boot-spl-align.bin.0)
which will NOT boot (the fsbl information in the bootheader seems a source of concern but I dont know...hence why I was asking before about the one it worked for you)
MKIMAGE
Using mkimage - as you indicated- we can generate an image that will boot from QSPI
./mkimage -T zynqmpbif -d bif bootbif.bin
Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 132468 bytes (132468 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd164999
But the bin image is NOT readable by bootgen
jramirez@trex bootgen_bif (master *%)$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved.
[ERROR] : Error reading Image header
So both utilities do generate different bootheaders and layouts.
The layout that doesnt boot - the one generated with bootgen - is the one documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1283-...
And the one that does work - using a boot header not readable by bootgen!- is not documented anywhere AFAIK.
I am confused at this point.
Is there any public information about the bootrom? does the above information make sense to you?
um, I dont think bootgen can boot spl.bin...seems we need an elf
so yes, I doubt it can work for you either. I suppose you misread the question.
BTW where is the image layout zynqmpimage or zynqmpbif documented? I am not refereing to the boot header fields - those are clear - but mostly interested about the 0x9c0 address.
We are placing the pmufw at that location (0x9c0) and right after spl.bin...why does this boot? AFAICS it does not follow the documented layout so it shouldnt...
https://www.xilinx.com/html_docs/xilinx2020_2/vitis_doc/bootimagelayout.html...
I'd like to be able to extend zynqmpbif with support for authentication but ATM I am lacking some basic information.
Anything you can share that would be great.
I have never tried to boot bootimage generaged from that bif with bootgen. Only boot.bin generated by mkimage with zynqmpbif based on provided bif file.
This code was developed long time ago and I have never used zynqmpbif but I use zynqmpimage all the time because it is wired with make for spl/boot.bin generation.
In past also the code was developed by reverse engineering of images to find out the bare minimum required for boot. And TBH this is the first time I see detailed description of boot headers. It wasn't public information in past. It would be interesting to use secondary boot device from Image Header table which we are doing differently now in SPL.
Definitely feel free to extend it. I am happy to test it and review.
Thanks, Michal

On 14/07/21, Michal Simek wrote:
Hi,
On 7/14/21 9:37 AM, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
On 13/07/21, Michal Simek wrote:
On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote: > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote: >> On 13/07/21, Michal Simek wrote: >>> Hi, >>> >>> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote: >>>> hi Michal, >>>> >>>> Would you have some sample/reference code to generate a SPL boot image >>>> using zynqmpbif instead of zynqmpimage? I cant find any documentation >>>> and I see no option to enable it (I was expecting to find some config >>>> in Makefile.spl but I see none). >>>> >>>> What is the expected way of building these images? >>> >>> Alex implemented it for Xilinx bif format after origin zynqmpimage >>> format. But usage is just like this. >>> >>> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif >>> /tmp/boot.bin >>> Image Type : Xilinx ZynqMP Boot Image support >>> Image Offset : 0x000009c0 >>> Image Size : 147216 bytes (147216 bytes packed) >>> PMUFW Size : 129792 bytes (129792 bytes packed) >>> Image Load : 0xfffc0000 >>> Checksum : 0xfd15d661 >>> [u-boot](debian-sent)$ cat /tmp/bif >>> image : { >>> [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf >>> [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin >>> } >> >> awesome, exactly what I needed to start with. > > So I can boot using the steps you mentioned above. > > But shouldnt the same bif work with bootgen? > > ****** Xilinx Bootgen v2019.2 > **** Build date : Oct 23 2019-22:59:42 > ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved. > > [TRACE] : Command Line parsing started > [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace > [INFO] : Command line parsing completed successfully > [TRACE] : BIF File: ./bif > [TRACE] : BIF file parsing started > [TRACE] : Setting PMU FW Image file as pmu.elf > [INFO] : BIF file parsing completed successfully > [INFO] : Parsing Partition Data to Image > [INFO] : Building image - image > [INFO] : Building the Partition Header Table > [INFO] : After build > -- Dump of Binary Image ---- > 00000000 Len: 000008b8 Res: 00000000 "BootHeader" > 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" > 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" > 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" > 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" > 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" > -- End of Dump > [INFO] : After align > -- Dump of Binary Image ---- > 00000000 Len: 000008b8 Res: 00000000 "BootHeader" > 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" > 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" > 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" > 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" > 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" > -- End of Dump > [INFO] : Partition Information: > [INFO] : Image: u-boot-spl.bin > [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 > [INFO] : After Link > -- Dump of Binary Image ---- > 00000000 Len: 000008b8 Res: 00000000 "BootHeader" > 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" > 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" > 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" > 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" > 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" > -- End of Dump > > > however when I boot and inspect the processor state, xsdb returns "APU > L2 cache is held in reset" > > Since the functionality to support RSA authentication is missing from > mkimage (I'll have to add that), I would first like to see it > functional with SPL using bootgen. > > However the same bif doesnt even boot - is this to be expected? > > also the layouts generated from the bif using mkimage and bootgen are > completely different (it seems that naively I expected them to be the > same); is there any information on the different layouts used for the > bootrom?
I tested it and it works fine for me. Take a look at the code what exactly is
[u-boot]$ cat /tmp/bif image : { [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl-align.bin }
Didn't try the latest bootgen but format is changing over years but none is updating this tool. Feel free to take a look at it.
weird, I can not boot the bin when using bootgen 2019 nor 2021.
please can you send me the output of the following command so I can compare? vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin
also, are you booting from QSPI?
thanks a lot!
just for reference:
$ cat bif the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.elf [destination_cpu=a53-1, load=0xfffc0000, bootloader] u-boot-spl-align.bin }
BOOTGEN
$./bootgen -arch zynqmp -image ./bif -w -o bootbif.bin
will generate this image:
$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, 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) : 0x00000000 fsbl_sourceoffset (0x30) : 0x00002800 fsbl_length (0x34) : 0x00000000 fsbl_load_address (0x38) : 0x00000000 fsbl_exec_address (0x3C) : 0x00000000 fsbl_total_length (0x40) : 0x00000000 qspi_config-word (0x44) : 0x00000800 checksum (0x48) : 0xfd1a2c41 iht_offset (0x98) : 0x000008c0 pht_offset (0x9c) : 0x00001100
IMAGE HEADER TABLE
version (0x00) : 0x01020000 total_images (0x04) : 0x00000001 pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900 hdr_ac_offset (0x10) : 0x00000000
IMAGE HEADER (u-boot-spl-align.bin)
next_ih(W) (0x00) : 0x00000000 next_pht(W) (0x04) : 0x00000440 total_partitions (0x08) : 0x00000000 total_partitions (0x0c) : 0x00000001 name (0x10) : u-boot-spl-align.bin
PARTITION HEADER TABLE (u-boot-spl-align.bin.0)
encrypted_length (0x00) : 0x0000815d unencrypted_length (0x04) : 0x0000815d total_length (0x08) : 0x0000815d load_addr (0x0c) : 0x00000000 exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000 attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000 checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000216 ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x00026d91
attribute list - trustzone [non-secure] el [el-0] exec_state [aarch-64] dest_device [none] encryption [no] core [none]
AUTHENTICATION CERTIFICATE (u-boot-spl-align.bin.0)
which will NOT boot (the fsbl information in the bootheader seems a source of concern but I dont know...hence why I was asking before about the one it worked for you)
MKIMAGE
Using mkimage - as you indicated- we can generate an image that will boot from QSPI
./mkimage -T zynqmpbif -d bif bootbif.bin
Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 132468 bytes (132468 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd164999
But the bin image is NOT readable by bootgen
jramirez@trex bootgen_bif (master *%)$ ./bootgen -read bootbif.bin
****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved.
[ERROR] : Error reading Image header
So both utilities do generate different bootheaders and layouts.
The layout that doesnt boot - the one generated with bootgen - is the one documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1283-...
And the one that does work - using a boot header not readable by bootgen!- is not documented anywhere AFAIK.
I am confused at this point.
Is there any public information about the bootrom? does the above information make sense to you?
um, I dont think bootgen can boot spl.bin...seems we need an elf
so yes, I doubt it can work for you either. I suppose you misread the question.
BTW where is the image layout zynqmpimage or zynqmpbif documented? I am not refereing to the boot header fields - those are clear - but mostly interested about the 0x9c0 address.
We are placing the pmufw at that location (0x9c0) and right after spl.bin...why does this boot? AFAICS it does not follow the documented layout so it shouldnt...
https://www.xilinx.com/html_docs/xilinx2020_2/vitis_doc/bootimagelayout.html...
I'd like to be able to extend zynqmpbif with support for authentication but ATM I am lacking some basic information.
Anything you can share that would be great.
I have never tried to boot bootimage generaged from that bif with bootgen. Only boot.bin generated by mkimage with zynqmpbif based on provided bif file.
This code was developed long time ago and I have never used zynqmpbif but I use zynqmpimage all the time because it is wired with make for spl/boot.bin generation.
In past also the code was developed by reverse engineering of images to find out the bare minimum required for boot. And TBH this is the first time I see detailed description of boot headers. It wasn't public information in past. It would be interesting to use secondary boot device from Image Header table which we are doing differently now in SPL.
Definitely feel free to extend it. I am happy to test it and review.
I added bin support to bootgen ; now we can use the same bif on mkimage and bootgen. so using
the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.bin [bootloader, destination_cpu=a53-0, load=0xfffc0000] u-boot-spl.bin }
And https://github.com/Xilinx/bootgen.git
(HEAD -> master, tag: xilinx_v2021.1, origin/xlnx-rel-v2021.1, origin/master, origin/HEAD) commit 34c4313a09dd75cf6ff5b188136e1a077c5b0aa2 Author: RamyaSree rdarapun@xilinx.com Date: 7 weeks ago
2021.1 Updates
with these changes:
diff --git a/imageheadertable-zynqmp.cpp b/imageheadertable-zynqmp.cpp index f06ca71..6832fc9 100755 --- a/imageheadertable-zynqmp.cpp +++ b/imageheadertable-zynqmp.cpp @@ -384,6 +384,32 @@ void ZynqMpImageHeader::ImportBin(BootImage& bi) hdr->execState = A53ExecState::AARCH32; }
+ if (Bootloader) { + /* hacking: add PMU FW before SPL */ + + std::string pmu_fw = bi.bifOptions->GetPmuFwImageFile(); + ByteFile pmu_fw_data(pmu_fw); + Binary::Length_t pmu_size = pmu_fw_data.len; + + uint8_t *partition_data = (uint8_t *)malloc(pmu_size); + memcpy(partition_data, pmu_fw_data.bytes, pmu_size); + + uint8_t pmu_padding = (4 - (pmu_size & 3)) & 3; + pmuFwSize = totalPmuFwSize = pmu_size + pmu_padding; + + partition_data = (uint8_t *)realloc(partition_data, pmuFwSize + data.len); + + memset(partition_data + pmu_size, 0, pmu_padding); + memcpy(partition_data + pmuFwSize, data.bytes, data.len); + + data.bytes = partition_data; + fsblFwSize = totalFsblFwSize = data.len + ((4 - (data.len & 3)) & 3); + data.len += pmuFwSize; + + if (Load.IsSet()) + hdr->execAddress = Load.Value(); + } + hdr->partition = new Partition(hdr, data.bytes, data.len); hdr->partitionSize = data.len; partitionHeaderList.push_back(hdr);
allows SPL to boot on ZynqMP:
./bootgen -arch zynqmp -image ./bif -w on -o boot.bin
I'll try to get authentication with SPL going first on bootgen; then should be simple to port back to mkimage.
participants (2)
-
Jorge Ramirez-Ortiz, Foundries
-
Michal Simek