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
