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

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

Hello,

On 4/13/26 9:31 AM, Michał Kruszewski wrote:
>> It isn't if the FSBL isn't able to load position-independent executables.
> 
> I am pretty sure bootgen uses the PhysAddr (or VirtAddr) to determine where to load the partition.
> The address from at 0x0 is OCM, not DDR.
> I have never seen people loading the second or third stage bootloaders to OCM.
> 
> I tried barebox-myir-zturn.elf.exe, no change.
> 
> Partition Number: 12884901890
> Header Dump
> Image Word Len: 0x0000C06B
> Data Word Len: 0x0000C06B
> Partition Word Len:0x0000C06B
> Load Addr: 0x00000000
> Exec Addr: 0x04000000
> Partition Start: 0x000FDE20
> Partition Attr: 0x00000010
> Partition Checksum Offset: 0x00000000
> Section Count: 0x00000001
> Checksum: 0xFBEDDE2D
> Application
> Handoff Address: 0x00000000
> In FsblHookBeforeHandoff function
> No Execution Address JTAG handoff
> 
> I think we need position code with PhysAddr and VirtAddr other than 0x0.
> Or maybe position independent code, but with another address.

That it was saying 0 was not intended. I pushed my branch again, it
looks like this now:

Program Headers:
  Type        Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD        0x001000 0x04000000 0x04000000 0x2faf0 0x2faf0 RW  0x1000
  GNU_STACK   0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

Let me know how it goes.

Cheers,
Ahmad


> 
> Regards,
> Michał Kruszewski
> 
> 
> Sent with Proton Mail secure email.
> 
> On Sunday, April 12th, 2026 at 8:50 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> 
>> 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 |
>>
>>
> 

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