Sorry, you need to enable JavaScript to visit this website.

Bootgen vs mkimage with U-Boot SPL

3 posts / 0 new
gnemas's picture
Bootgen vs mkimage with U-Boot SPL

I have created a U-Boot bootloader and Linux operating system using Buildroot


git clone git://
cd buildroot
make zynq_zed_defconfig


This was successful, and I am able to boot Linux on my ZedBoard using a microSD as the boot device and using the BOOT.BIN that buildroot/U-Boot created from the U-Boot SPL binary.


The latest buildroot version uses U-Boot's mkimage to create a Zynq-compatible first stage bootloader from the U-Boot SPL binary (u-boot-spl.bin). I think this used to require a special python tool, but now mkimage has been given the ability to generate this binary itself.


However, I would like to experiment with the Xilinx bootgen tool instead of mkimage. Unfortunately, when I use bootgen, the resulting BOOT.BIN does not work.


I am using a BIF file (boot.bif) as follows:


[bootloader] u-boot-spl.bin


I am invoking bootgen like this:


bootgen -arch zynq -image boot.bif -o BOOT.BIN


The resulting BOOT.BIN file is 90600 bytes, which is larger than what I create using mkimage (86952 bytes):


$ mkimage -A arm -T zynqimage -d u-boot-spl.bin BOOT.BIN
Image Type : Xilinx Zynq Boot Image support
Image Offset : 0x000008c0
Image Size : 86952 bytes (86952 bytes packed)
Image Load : 0x00000000
User Field : 0x00000000
Checksum : 0xfd17ac31


Can anyone tell me how to get bootgen to generate a bootable binary from my u-boot-spl.bin? I noticed that if I specify zynqmp instead of zynq for -arch, the file size is exactly 256 bytes larger, but it still does not work.






hockeyman1972's picture
bootgen process

Hi Gregg,

  I'm not a user of buildroot, but it seems to follow a slightly different procedure to generate a boot.bin file for Zynq than bootgen does.  The normal procedure for using bootgen is to supply (in the .bif) a first-stage bootloader program (zynq-fsbl.elf), and optional bitstream (if you are loading the PL) and an executable (in this case, u-boot.elf).   The FSBL can be generated automatically from the application template in the Xilinx SDK.  It looks like buildroot takes some of the PS7 initialization files and puts them directly into the u-boot image it creates, which is perfectly fine as it doesn't matter where the initialization is done, it just has to be done.  

I suspect the problem you are having is trying to take components from two similar but different processes for accomplishing the same task, and there are some differences in the way the components are generated.  Bootgen expects the FSBL to be an ELF file.  If you can convert the output of the self-contained u-boot image generated by buildroot to an ELF, then it should be possible to simply generate a boot.bin that contains only that file, as it contains the initialization required for the PS.  


gnemas's picture
It seems that bootgen leaves

It seems that bootgen leaves the length fields in the boot header set to zero when the input file is a raw binary. It must rely on the elf headers for length information. I was able to make this work by converting the bin file to an elf using objcopy (search for bin2elf), which it turns out is exactly what you suggested above. Thanks.