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. > 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.
