diff options
author | Stephen Warren <swarren@nvidia.com> | 2015-08-07 16:12:44 -0600 |
---|---|---|
committer | Tom Warren <twarren@nvidia.com> | 2015-08-13 13:06:04 -0700 |
commit | a5fc3d0b35a7e83a05dc41c1b966710d28118a29 (patch) | |
tree | a32271f2539cf32389a05f4a5f7e9fb63c66b09c /include/crc.h | |
parent | a89031671215e90f78194db31f68500ec1be3c8a (diff) |
ARM: tegra: query_sdram_size() cleanup
The return value of query_sdram_size() is assigned directly to
gd->ram_size in dram_init(). Adjust the return type to match the field
it's assigned to. This has the beneficial effect that on 64-bit systems,
the return value can correctly represent large RAM sizes over 4GB.
For similar reasons, change the type of variable size_bytes in the same
way.
query_sdram_size() would previously clip the detected RAM size to at most
just under 4GB in all cases, since on 32-bit systems, larger values could
not be represented. Disable this feature on 64-bit systems since the
representation restriction does not exist.
On 64-bit systems, never call get_ram_size() to validate the detected/
calculated RAM size. On any system with a secure OS/... carve-out, RAM
may not have a single contiguous usable area, and this can confuse
get_ram_size(). Ideally, we'd make this call conditional upon some other
flag that indicates specifically that a carve-out is actually in use. At
present, building for a 64-bit system is the best indication we have of
this fact. In fact, the call to get_ram_size() is not useful by the time
U-Boot runs on any system, since U-Boot (and potentially much other early
boot software) always runs from RAM on Tegra, so any mistakes in memory
controller register programming will already have manifested themselves
and prevented U-Boot from running to this point. In the future, we may
simply delete the call to get_ram_size() in all cases.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Diffstat (limited to 'include/crc.h')
0 files changed, 0 insertions, 0 deletions