Re: [PATCHv6 1/3] sandbox: add board_get_usable_ram_top

[Randolph Sapp <rs@ti.com>]

On Mon May 11, 2026 at 1:26 PM CDT, Simon Glass wrote:
> Hi Randolph,
>
> On 2026-05-08T22:29:09, Randolph Sapp <rs@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@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.

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