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/13/26 5:08 PM, Michał Kruszewski wrote:
> Good news.
> I am able to boot barebox and Linux now.
> Just one minor issue.
> barebox prints some garbage before it starts:

Nice! The early PBL console output is before parsing the DT and it seems
the baudrate was calculated incorrectly.

Is CONFIG_BAUDRATE of the correct value?

Next step would be to allow replacing the DT easily. I will let you know
when there's something to test.

> Board: Zynq Z-Turn MYIR Board V5
> deep-probe: disabled in device tree

I expect that wit barebox,disable-deep-probe removed in the DT, below
errors should dsappear.

> 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

That's MMC_CMD_SWITCH that's failing.

Just a guess, try swapping the order of

  mci_of_parse(&arasan_sdhci->mci);
  sdhci_setup_host(&arasan_sdhci->sdhci);

in drivers/mci/arasan-sdhci.c and see if it makes a difference.

> barebox-environment chosen:environment-sd.of: probe failed: No such file or directory
> environment load /dev/env0: No such file or directory

This is expected when the MMC probe had failed.

Cheers,
Ahmad

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

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