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

[Álvaro G. M.]

Hi

On Fri, 2025-11-28 at 08:23 +0100, Michal Simek wrote:
> > 
> > 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.

Right, so if I were to run this from embedded BRAM, should I set
CONFIG_TEXT_BASE to something slightly above 0 as well?


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

That's what I did, but as I understand from those lines above, original binary
does not include the DTS, right? That's why I get the fdtdec_setup() failed
message.


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

Yeah, it looks like the u-boot.elf code region is bigger than my current
bootloader (one based on the s-rec example), so it seems like it won't fit on my
design. I will try SPL, which I'm sure will open a different can of worms  :)

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

Yes, thank you. I'm trying to upgrade an old design from 2016 because we've just
built a new version of the board with a new mtd (mt25ql02g replacing mt25ql128),
but it seems like Linux leaves the MTD configured in a mode our current
bootloader (the s-record based one) isn't able to work with, so resetting the
board leaves it unable to reload Linux kernel from flash. u-boot however is able
to sf read data from the flash regardless of the status Linux left it with, so
that's why I wanted to port u-boot to this semi-old design.

I'm facing however other problems related with this flash, as it seems that
Linux is unable to write to it. But also, Vivado 2025.1 isn't quite capable of
writing to my old mt25ql128, which I was able to do so with Vivado versions 2016
through 2018 (I just posted about this on AMD/Vivado forums), so we are
considering undoing this MTD change because it was intended as future-proofing
for bigger software designs, but it seem like it isn't worth the effort for us
right now.

Sorry about the non u-boot rambling!

Thanks!