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

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

Hi,

On 4/8/26 7:43 AM, Michał Kruszewski wrote:
>> 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.

Please give this patch a try:

https://github.com/a3f/barebox/commit/1dc352b5de6e03429010a23ce6804a3e4c7109e1

The image will be called start_myir_zturn.elf.

If this is also completely silent, try changing the zero in
ENTRY_FUNCTION_WITHSTACK() to 0x200000.

Cheers,
Ahmad

> 
> 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 |
>>
>>
>>
> 

-- 
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 |