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!
