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
