Hi Stephen,
On 23 December 2014 at 13:22, Stephen Warren <swar...@wwwdotorg.org> wrote:
> On 12/23/2014 01:01 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 23 December 2014 at 10:34, Stephen Warren <swar...@wwwdotorg.org>
>> wrote:
>>>
>>> From: Stephen Warren <swar...@nvidia.com>
>>>
>>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>>> example would be a Tegra124 system (where RAM starts at 2GB physical)
>>> that has more than 2GB of RAM.
>>>
>>> In this case, we can gd->ram_size to represent the actual RAM size, so
>>> that the actual RAM size is passed to the OS. This is useful if the OS
>>> implements LPAE, and can actually use the "extra" RAM.
>>>
>>> However, U-Boot does not implement LPAE and so must deal with 32-bit
>>> physical addresses. To this end, we enhance board_get_usable_ram_top() to
>>> detect the "over-sized" case, and limit the relocation addres so that it
>>> fits into 32-bits of physical address space.
>>>
>>> Signed-off-by: Stephen Warren <swar...@nvidia.com>
>>
>>
>> Reviewed-by: Simon Glass <s...@chromium.org>
>
>
>>> diff --git a/common/board_f.c b/common/board_f.c
>
>
>>> /* Get the top of usable RAM */
>>> __weak ulong board_get_usable_ram_top(ulong total_size)
>>> {
>>> +#ifdef CONFIG_SYS_SDRAM_BASE
>>> + /*
>>> + * Detect whether we have so much RAM it goes past the end of our
>>> + * 32-bit address space. If so, clip the usable RAM so it
>>> doesn't.
>>> + */
>>> + if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
>>> + /*
>>> + * Will wrap back to top of 32-bit space when
>>> reservations
>>> + * are made.
>>> + */
>>> + return 0;
>>
>>
>> I wonder whether (ulong)(1ULL << 32) would be more portable, but
>> perhaps it would just be confusing. We can worry about this when we do
>> more 64-bit things.
>
>
> I don't think it makes any difference while board_get_usable_ram_top()
> returns a 32-bit value.
>
> If board_get_usable_ram_top() was modified to return a 32-bit value on
> 32-bit systems and a 64-bit value on 64-bit systems then:
>
> The value "0" means "top of addressable address space" (once wrapped from 0
> backwards when allocations are made later).
>
> The value 1ULL<<32 means 4GB, no matter what the address space size is.
> That's quite a different thing on 64-bit.
>
> We really do want 0 here, not a masked/clipped/overflowed 4GB value, since
> on 64-bit, if gd->ram_top ended up less than CONFIG_SYS_SDRAM_BASE, we'd
> have the exact same situation as I'm fixing here on 32-bit, just with much
> larger numbers; consider a system where RAM starts at (U64_MAX + 1 - 2GB)
> and RAM is 4GB in size; we get the same wrapping effect. (Admittedly that
> physical layout would be quite unlikely to happen on 64-bit since presumably
> no SoC designer would ever set CONFIG_SYS_SDRAM_BASE that high if that much
> RAM were supported, since that'd require a 64-bit system with >64-bit LPAE,
> which hopefully is many many years in the future).
Yes it's best to avoid predicting the future, and what you have looks
right for 32-bit.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
