[PATCHv6 1/3] sandbox: add board_get_usable_ram_top

[Simon Glass]

Hi Randolph,

On Mon, 11 May 2026 at 12:44, Randolph Sapp <rs at ti.com> wrote:
>
> On Mon May 11, 2026 at 1:26 PM CDT, Simon Glass wrote:
> > Hi Randolph,
> >
> > On 2026-05-08T22:29:09, Randolph Sapp <rs at ti.com> wrote:
> >> sandbox: add board_get_usable_ram_top
> >>
> >> Add a board_get_usable_ram_top definition, since currently ram_top is
> >> equal to ram_size. Attempting to actually map ram_size with map_sysmem
> >> results in a fault.
> >>
> >> Signed-off-by: Randolph Sapp <rs at ti.com>
> >>
> >> board/sandbox/sandbox.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >
> >> diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
> >> @@ -105,6 +105,11 @@ int dram_init(void)
> >> +phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
> >> +{
> >> +     return gd->ram_size - 1;
> >> +}
> >> +
> >
> > Please describe which caller actually faults on map_sysmem(), since
> > that is the real motivation.
> >
> > But this contradicts the documented API. From include/init.h:
> >
> >    The returned address is exclusive (i.e. 1 byte above the
> >    last usable address).
> >
> > See the weak function in common/board_f.c
>
> Ugh. Why is *usable* ram top exclusive? That's returning an explicitly
> *unusable* address. Fun. Suppose it's my fault for not reading that first.

It's just the way it is defined. It avoids lots of ffff's in
addresses. I know that ACPI tends to use the last valid address, but
that's not typically how U-Boot works.

>
> > If the real problem is callers doing map_sysmem(ram_top, ...) and
> > faulting, you could fix it in those callers (use ram_top - 1 when you
> > need the last valid byte). But I could take a look if you point to the
> > code.
> >
> > Also, this uses gd->ram_size as if it were an address; it should
> > really be gd->ram_base + gd->ram_size. It happens to work because
> > sandbox's ram_base is 0, but it reads as a type confusion.
> >
> > Regards,
> > Simon
>
> Fair enough, but it seems that this board definition will not be required given
> the above feedback.

Ah OK...but I'm still interested in knowing which caller caused this problem.

Regards,
Simon