How to boot u-boot from embedded ELF file in Microblaze core

[Michal Simek]

Hi,

On 11/28/25 07:42, Álvaro G. M. wrote:
> Hi all,
> 
> I've been working a bit on this and now I have more doubts than before...
> 
> On Fri, 2025-11-14 at 11:30 +0100, Álvaro G. M. wrote:
>>
>> [...]
>> I can load this via xsdb and u-boot works and is capable of booting Linux
>> kernel. However, there are a couple of things I don't understand.
>>
>> First off, if I set CONFIG_TEXT_BASE=0x80000000 (the exact beginning of RAM), it
>> won't boot, not even early debug message will appear. Why is that?
>>
> 
> I still haven't been able to solve this. Why is this value invalid? And which
> value should I put there to embed u-boot.elf into the microblaze boot memory?

Because you need early stack pointer which is allocated in front of u-boot 
itself at start. It means you need at least small space there.
U-Boot is going to be relocated to the end of memory anyway that's why it 
shouldn't really matter that TEXT base is not aligned with DDR start.


> 
>> And the second thing, my endgame is to embed u-boot.elf into Microblaze itself,
>> so it acts as FSBL. I reduced the size to the maximum and I got a quite small
>> binary, even smaller than my current bootloader (the one from Xilinx that loads
>> an SREC image from flash), so there shouldn't be any issue from that part. To do
>> this, I set CONFIG_TEXT_BASE=0x0, but again, no early boot debug message
>> appears.
>>
>> I've tried different values for CONFIG_TEXT_BASE in this case, but none of them
>> will work. Also, in either case, I'm not sure why, but I can't debug step by
>> step via xsdb, I won't see what ASM or C code matches with current PC address.
>> However, SPL will let me run it step by step via xsdb.
>>
> 
> I've discovered that I can launch u-boot file with xsdb and debug step by step
> via xsdb. But this file won't boot up properly, because somehow it seems to be
> missing the DT? But the file is bigger than u-boot.elf. If I load u-boot.elf, I
> get uboot console and am able to use sf probe and sf read to launch the kernel.
> But this file is smaller and I can't debug it step by step. So I don't really
> understand anything.
> 
> $ ls -al u-boot{,.elf}
> -rwxr-xr-x 1 sslayer sslayer 1882032 Nov 27 10:06 u-boot

this is file with all symbols

> -rwxr-xr-x 1 sslayer sslayer  215224 Nov 27 10:06 u-boot.elf

This is recreated file from binary. The best is to run make V=1 u-boot.elf

Then you will see
   microblazeel-xilinx-linux-gnu-objcopy --gap-fill=0xff  -O binary   u-boot 
u-boot-nodtb.bin && {  echo '  tools/relocate-rela  '; tools/relocate-rela 
u-boot-nodtb.bin u-boot; } || { rm -f u-boot-nodtb.bin; false; }
   tools/relocate-rela
   cp u-boot-nodtb.bin u-boot.bin
microblazeel-xilinx-linux-gnu-objcopy -I binary -B microblaze  -O 
elf32-microblaze u-boot.bin u-boot-elf.o
   microblazeel-xilinx-linux-gnu-ld u-boot-elf.o -o u-boot.elf -EB -T 
u-boot-elf.lds --defsym="_start"=0x29000000 -Ttext=0x29000000

Which is showing you what files are used.

For you the best option is to use CONFIG_OF_EMBED=y which includes DTB directly 
in binary that you don't need to deal with it.

Regarding sizes and location. I didn't try to put u-boot to BRAM but I can't see 
any reason why you can't do it.
Overall binary size is all the time question what exactly you want to do with it.
SPL is another option but I didn't try it for a while but should be enabled.

Keep in your mind that full relocation is enabled that's why you u-boot itself 
is finding out where it runs and then update sections. Based on your loading 
address you can in xsdb remap symbols to see them by:

memmap -file u-boot -reloc $reloc_addr

Keep in mind that Microblaze is pretty much EOL and for new designs you should 
focus on Microblaze V(risc-v compatible version).

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs