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

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

Good news.
I am able to boot barebox and Linux now.
Just one minor issue.
barebox prints some garbage before it starts:

FSBL Status = 0xE0001000

�=�H�
         !1k̨�!H�sH�o�9�<9ϭsMJ!�H�N�o�MJ�H�N�o�MJ!�H�N�o�9
                                                                �kMJKJH�N�o�JH�N�o�Switch to console [cs1]


barebox 2026.03.0-02720-g57db6e3f7c05 #8 Mon Apr 13 16:53:33 CEST 2026


Board: Zynq Z-Turn MYIR Board V5
deep-probe: disabled in device tree
ERROR: could not get clock /axi/dma-controller@f8003000:apb_pclk(0)
ERROR: could not get clock /axi/etb@f8801000:apb_pclk(0)
ERROR: could not get clock /axi/tpiu@f8803000:apb_pclk(0)
ERROR: could not get clock /axi/funnel@f8804000:apb_pclk(0)
ERROR: could not get clock /axi/ptm@f889c000:apb_pclk(0)
ERROR: could not get clock /axi/ptm@f889d000:apb_pclk(0)
mdio_bus: miibus0: probed
macb e000b000.ethernet@e000b000.of: Cadence GEM at 0xe000b000
arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0
malloc space: 0x17e00000 -> 0x1fdfffff (size 128 MiB)
arasan-sdhci e0100000.mmc@e0100000.of: error while transferring data for command 6
arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0202 , interrupt = 0x00208000
mmc0: Card's startup fails with -74
barebox-environment chosen:environment-sd.of: probe failed: No such file or directory
environment load /dev/env0: No such file or directory
Maybe you have to create the partition.

Hit any to stop autoboot:    1
barebox@Zynq Z-Turn MYIR Board V5:/



Regards,
Michał Kruszewski


Sent with Proton Mail secure email.

On Monday, April 13th, 2026 at 3:58 PM, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

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