[PATCH] xilinx: mbv: Update stack, heap, and OpenSBI memory

[Tom Rini]

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 <padmarao.begari at amd.com>
> > > > > ---
> > > > >    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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260218/0fffe24d/attachment.sig>