Hi Randolph, On Mon, 11 May 2026 at 12:44, Randolph Sapp <[email protected]> wrote: > > On Mon May 11, 2026 at 1:26 PM CDT, Simon Glass wrote: > > Hi Randolph, > > > > On 2026-05-08T22:29:09, Randolph Sapp <[email protected]> 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 <[email protected]> > >> > >> 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
