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

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

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 |