Re: Compiling barebox without PBL and using dts from Linux dts upstream for Zynq SoC

["Michał Kruszewski" <mkru@protonmail.com>]

> But first can you verify that using images/start_avnet_zedboard.pbl with
> DT replaced as described in a previous message of mine successfully
> boots to shell?

No, it does not boot to shell.
I have replaced:

-#include <arm/xilinx/zynq-zed.dts>
+/include/ "../../../dts/src/arm/xilinx/zynq-zturn-v5.dts"

in arch/arm/dts/zynq-zed.dts file.

Then I used images/start_avnet_zedboard.pbl for boot.bin generation.
I see no barebox output in terminal.

Regards,
Michał Kruszewski


Sent with Proton Mail secure email.

On Tuesday, April 7th, 2026 at 3:22 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

> Hello Michał,
> 
> I hope you had a please Easter.
> 
> On 3/27/26 11:37 AM, Michał Kruszewski wrote:
> > Of course, due to the hurry, I made a mistake in my previous message.
> > The program for the boot.bin generation is called bootgen not bootbin.
> >
> > You can find AMD bootgen user guide here:
> >   https://docs.amd.com/r/en-US/ug1283-bootgen-user-guide/Introduction.
> >
> > The ELF file provided to the bootgen can have multiple loadable sections, each of which forms a partition in the boot image.
> > The AMD/Xilinx FSBL will load and hand-off execution to the next executable partition found in the boot.bin file.
> > The u-boot.elf file has one LOAD section:
> >   [user@host] readelf -l u-boot.elf
> >   Elf file type is EXEC (Executable file)
> >   Entry point 0x4000000
> >   There is 1 program header, starting at offset 52
> >   Program Headers:
> >     Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> >     LOAD           0x010000 0x04000000 0x04000000 0x108ff0 0x108ff0 RW  0x10000
> >    Section to Segment mapping:
> >     Segment Sections...
> >      00     .data
> > The readelf for barebox shows 3 LOAD sections and 1 DYNAMIC section.
> 
> This is true for the "barebox" binary, but if you check the
> images/start_avnet_zedboard.pbl, the situation is different. It does
> have multiple sections too, but the initial LOAD section contains
> everything placed linearly.
> 
> > The second difference is that Elf file type for u-boot is EXEC (Executable file), for barebox DYN (Position-Independent Executable file).
> 
> I suspect that the ELF type doesn't actually matter, but we can
> easily change it should it really be needed.
> 
> > The bootgen user guide has the table 49 with the following note for the ELF file format:
> > "Symbols and headers removed."
> > However, it is not clear whether bootgen automatically removes symbosls and headers, or whether it expects the elf file without symbols and headers.
> 
> This is easily done with the strip command.
> 
> > Now, I would like to describe a few ideas and potential problems.
> > I am by far not bootloaders expert.
> > However, I had to boot and debug booting on a few custom and off-the-shelf boards with AMD/Xilinx SoCs and MPSoCs.
> > All the things I write below are related to booting ADM/Xilinx chips only.
> >
> >
> > There are 2 alternative paths you may chose when trying to boot AMD/Xilinx SoCs.
> >
> > Path 1: The no-FSBL path
> > This is the path currently supported by barebox.
> > You do not want to utilize the AMD/Xilinx automatically generated FSBL.
> > In such a case, you have to define a board, and provide C code for the low-level board initialization.
> > The barebox PBL does the FSBL job in this case.
> > I think this path is fine for hobby projects and off-the-shelf boards when you want to quickly get things running.
> > However, I am not a fan of this path in professional projects because of the following reasons:
> >   a) The FSBL code is automatically generated, it may include some workarounds or fixes for hardware bugs.
> >      The copied low-level initialization C code may potentially miss them.
> 
> If you don't update your FPGA toolchain, you may miss these issues also
> and we have been burnt a lot in the past with FPGA toolchains adding
> subtle breakage all around.
> 
> >   b) Forget about getting official support from AMD/Xilinx if you mention you don't use the official FSBL for boot.
> 
> Yes, if you need FAE support, they may require you to reproduce using
> their bootloader.
> 
> >
> > Path 2: The FSBL path
> > For me, this is the way to go in professional projects.
> > Barebox currently does not support this path.
> > In this case, you do not want to be forced to define a board.
> > This is simply pointless, the FSBL is responsible for initializing the low-level stuff.
> > All you need to boot Linux when FSBL stops execution is some SSBL and device tree.
> 
> I see your point.
> 
> > Now, what a support for path 2 in the barebox could look like.
> > We could use the concept of the virtual board.
> > The virtual board is a board that:
> >   - is assumed to already be low-level initialized when barebox starts running,
> >   - can accept arbitrary device tree,
> >   - should not be bound to any specific device tree by default.
> > The boilerplate related to the board definition should not exist for the virtual board.
> 
> Well, the boilerplate will exist, but you wouldn't need to modify it.
> The generic board would be just an extra image produced in the barebox
> build.
> 
> > What the user experience would look like:
> >   1. make zynq_virt_defconfig,
> >   2. open menuconfig,
> >   3. find and set config containing path for the device tree file (can be out of tree),
> 
> Linux regularly breaks forward and to a lesser degree backwards
> compatibility for device tree. We can make it possible to reference a
> device tree in dts/, but I don't want to make it possible to point an
> arbitrary device tree where it's unclear if the binding are compatible
> with barebox.
> 
> If someone wants to inject a device tree, they should copy its source
> into barebox.
> 
> >   4. make,
> >   5. copy the required elf and/or bin files to your project.
> 
> This is doable, but I'd prefer a new images/barebox-zynq-ssbl.img that's
> just an extra image generated from the normal zynq_virt_defconfig.
> 
> 
> >
> > The u-boot has a similar concept of virt defconfigs, for example:
> > xilinx_versal_virt_defconfig
> > xilinx_zynqmp_virt_defconfig
> > xilinx_zynq_virt_defconfig
> 
> I see. I haven't worked myself with the Zynq, so I was not aware of how
> it's handled in U-Boot.
> 
> > What potential problems do I see?
> > The bootgen handles elf files with multiple loadable sections by putting each section into a separate partition.
> > The FSBL simply loads and hands-off to the next executable partition from the boot.bin.
> > I do not know how barebox works and prepares images.
> 
> That's not a problem. As mentioned in previous mails, barebox/vmbarebox
> is the wrong image to use however you look at it. You always need an
> image with PBL, even if the PBL only does decompression and passing
> along the DT without any lowlevel HW initialization at all.
> 
> > However I can see 3 potential scenarios.
> 
> [snip]
> 
> > Unfortunately, I do not have enough skills to apply required changes to barebox to test these ideas on my own.
> > However, I would be more than happy to test your changes.
> 
> Thanks and I would like to take you up on the offer.
> 
> But first can you verify that using images/start_avnet_zedboard.pbl with
> DT replaced as described in a previous message of mine successfully
> boots to shell?
> 
> Once we know that the ELF generated is ok in principle I can look into
> implementing a virt/ssbl image
> 
> > Let me know what you think.
> 
> Cheers,
> Ahmad
> 
> >
> > Regards,
> > Michał Kruszewski
> >
> 
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> 
> 
>