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).
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
