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

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

Hello Michał,

On 4/12/26 16:42, Michał Kruszewski wrote:
> 
> It does not work.
> No matter whether I change ENTRY_FUNCTION_WITHSTACK() to 0x200000.
> 
> I see that both VirtAddr and PhysAddr of the executable section in your case are set to 0.
> I am not sure this is safe.
> u-boot uses 0x04000000.

It isn't if the FSBL isn't able to load position-independent executables.

> I enabled Zynq FSBL logging.
> In the case of barebox, the FSBL for some reason thinks there is no section to hand off to.
> 
> This is the log for u-boot:

Thanks, this is useful. Could you pull my rft-myir-zturn branch again,
build it and test barebox-myir-zturn.elf.exe?

Same procedure as before with each of the two stack addresses.

If it doesn't work, I am interested to see the FSBL log output.

Thanks,
Ahmad

> 
> FPGA Done !
> In FsblHookAfterBitstreamDload function
> Partition Number: 12884901890
> Header Dump
> Image Word Len: 0x000423FC
> Data Word Len: 0x000423FC
> Partition Word Len:0x000423FC
> Load Addr: 0x04000000
> Exec Addr: 0x04000000
> Partition Start: 0x000FDE20
> Partition Attr: 0x00000010
> Partition Checksum Offset: 0x00000000
> Section Count: 0x00000001
> Checksum: 0xF7E3B37A
> Application
> Handoff Address: 0x04000000
> In FsblHookBeforeHandoff function
> SUCCESSFUL_HANDOFF
> FSBL Status = 0xE0001000
> U-Boot 2026.01-00518-gc05dba22f1f2-dirty (Feb 06 2026 - 13:18:15 +0100)
> 
> and this is the log for barebox:
> 
> FPGA Done !
> In FsblHookAfterBitstreamDload function
> Partition Number: 17179869186
> Header Dump
> Image Word Len: 0x000017EA
> Data Word Len: 0x000017EA
> Partition Word Len:0x000017EA
> Load Addr: 0x00000000
> Exec Addr: 0x00000000
> Partition Start: 0x000FDE20
> Partition Attr: 0x00000010
> Partition Checksum Offset: 0x00000000
> Section Count: 0x00000002
> Checksum: 0xFFEFD7AF
> Application
> Handoff Address: 0x00000000
> In FsblHookBeforeHandoff function
> No Execution Address JTAG handoff
> 
> 
> Best regards,
> Michał Kruszewski
> 
> 
> Sent with Proton Mail secure email.
> 
> On Friday, April 10th, 2026 at 1:11 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> 
>> 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 |
>>
>>
>>
> 


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