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

[Álvaro G. M.]

On Tue, 2025-12-02 at 14:35 +0100, Michal Simek wrote:
> 
> 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.

Yeah, I see. My current BRAM is 65536 and I wouldn't want to increase it. In
fact, once I leave the embedded bootloader and run u-boot or linux, does this
bram even get used? Because I was thinking of making it even smaller.

So I should try to use SPL and have this load full u-boot, or maybe go the
falcon mode, right?



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

I don't know exactly what's going on, and due to timing constraints (of mine,
not of the FPGA), we've decided to go back to the old 128Mbit flash, so even
though I'm gonna try to have the SPL working, we won't be using the new bigger
flash, so I won't be spending any more time on diagnosing this. I'm a bit
frustrated because I had it working once, but I haven't been able to replicate
the conditions under which it worked, it was just one of a dozen of tests and I
wasn't disciplined enough to document and save each test separately, so, that's
my penance.

Thanks!