zynqmpbif - sample

Jorge Ramirez-Ortiz, Foundries jorge at foundries.io
Thu Jul 15 00:10:36 CEST 2021


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 at 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 at 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-bootgen-user-guide.pdf
> >>>
> >>> 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#uyu1526489661314
> > 
> > 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 at 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.



More information about the U-Boot mailing list