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

[Michal Simek]

On 12/2/25 12:07, Álvaro G. M. wrote:
> 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?
> 

How big is your bram?

Obviously never thought to have full u-boot in bram because bram sizes were 
small that's why never really wanted to allocated bram just for bootloader itself.
Another thing is that normally MB has reset address at 0 where reset vectors are.
And full u-boot is also setting up these vectors that's why you even don't want 
to have full u-boot to start from 0 but from any offset to have location for 
reset vectors.


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

with OF_EMBED dt is present in both files but relocation section is not filled 
by proper data.

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

SPL on microblaze is around but not really used (maybe never used in any 
product) because Xilinx was using fsboot instead. I think this could be solution 
for you too.


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

I haven't really spent my time on SPI to help you on this. But you are using axi 
spi/qspi which shouldn't be that problematic. Lowering frequency or mode 
limitation can solve the problem.

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