On Wed, Feb 18, 2026 at 04:17:38PM +0100, Michal Simek wrote: > > > On 2/18/26 15:32, Tom Rini wrote: > > On Wed, Feb 18, 2026 at 03:18:37PM +0100, Michal Simek wrote: > > > > > > > > > On 2/18/26 15:12, Tom Rini wrote: > > > > On Wed, Feb 18, 2026 at 12:03:15PM +0530, Padmarao Begari wrote: > > > > > > > > > A 2 MB region of DDR memory is allocated for U‑Boot SPL, with the > > > > > heap starting at address 0x80000000 and the stack at 0x80200000. > > > > > However, U‑Boot fails when using OpenSBI v1.8 because OpenSBI begins > > > > > execution at 0x80100000, causing an overlap between the SPL stack > > > > > and the malloc region. > > > > > To resolve this conflict, the SPL heap and stack are moved to > > > > > higher memory addresses, and OpenSBI is relocated to 0x80000000. > > > > > The SPL heap now starts at 0x8C000000, and the stack is placed > > > > > at 0x8F000000. The MB-V requires at least 256MB of DDR to run U-Boot. > > > > > > > > > > _________________ > > > > > | |0x8FFFFFFF > > > > > |_______________| > > > > > | SPL- Stack |0x8F000000 > > > > > | | > > > > > | | > > > > > | SPL - Heap | > > > > > |_______________|0x8C000000 > > > > > | | > > > > > | | > > > > > | Full U-Boot | > > > > > |_______________|0x81200000 > > > > > |Load FIT Image | > > > > > |_______________|0x80200000 > > > > > | OpenSBI | > > > > > |_______________|0x80000000 > > > > > > > > > > Signed-off-by: Padmarao Begari <[email protected]> > > > > > --- > > > > > configs/xilinx_mbv32_defconfig | 4 ++-- > > > > > configs/xilinx_mbv32_smode_defconfig | 2 +- > > > > > configs/xilinx_mbv64_smode_defconfig | 2 +- > > > > > 3 files changed, 4 insertions(+), 4 deletions(-) > > > > > > > > As general feedback, this is something that ought to be in doc/board/ > > > > somewhere too. One such existing example is doc/board/ti/am62x_sk.rst > > > > and follow-up patches are fine. > > > > > > Just curious. Memory layout is something what every platform has to deal > > > with. > > > Don't we have any script for it? > > > > My still current preference is putting reasonable default values in > > Kconfig, so that it's not something that has to be managed in defconfigs > > as it's not typically on the developer to modify per board, but rather > > on whomever is doing the upstream SoC/etc support to say what it is. But > > that's also a little less true for FPGA platforms? > > This platform is soft core as classic Microblaze is. Difference is pretty > much that this is risc-v based ISA. It means memory location is not fixed, > memory size is not fixed (because there will be users of openamp where small > amount of memory can be also used). > And IPs base is also moving from one design to another on the same board. > > Anyway setup is that SPL is running from small memory - we can call it as > OCM which by default starts at 0 (but can be changed). And we got only 64kB > of memory that's why spl stack and heap need to be placed in DDR (which is > already configured). We had it at DDR start but it is not practical because > after handoff to opensbi that memory is unused. > That's why make sense to have opensbi at ddr start to use it fully. > > Currently BSS is the part of OCM but I can imagine that we will move it to > DDR too to have more space for text/data/rodata. But the problem is the same > how to define BSS location. > I don't think this is going to be a problem to get it via tool machinery.
Thanks for the explanation. Yes, some tooling could indeed spit out a config fragment that's correct for the configuration you have. And I think it would be good to capture some of the above in documentation in U-Boot as well. -- Tom
signature.asc
Description: PGP signature
