]> git.sur5r.net Git - u-boot/commit
ARM: tegra: query_sdram_size() cleanup
authorStephen Warren <swarren@nvidia.com>
Fri, 7 Aug 2015 22:12:44 +0000 (16:12 -0600)
committerTom Warren <twarren@nvidia.com>
Thu, 13 Aug 2015 20:06:04 +0000 (13:06 -0700)
commita5fc3d0b35a7e83a05dc41c1b966710d28118a29
treea32271f2539cf32389a05f4a5f7e9fb63c66b09c
parenta89031671215e90f78194db31f68500ec1be3c8a
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>
arch/arm/mach-tegra/board.c