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

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

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.

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:

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