From: Stephen Warren swarren@nvidia.com
Additionally, ARM64 devices typically run a secure monitor in EL3 and U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3 code and data. These carve-outs are located at the top of 32-bit address space. Restrict U-Boot's RAM usage to well below the location of those carve-outs. Ideally, we would the secure monitor would inform U-Boot of exactly which RAM it could use at run-time. However, I'm not sure how to do that at present (and even if such a mechanism does exist, it would likely not be generic across all forms of secure monitor).
Signed-off-by: Stephen Warren swarren@nvidia.com --- arch/arm/mach-tegra/board2.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c index 36bcfb04c021..7842caaa5afb 100644 --- a/arch/arm/mach-tegra/board2.c +++ b/arch/arm/mach-tegra/board2.c @@ -287,11 +287,20 @@ void pad_init_mmc(struct mmc_host *host) * 32-bits of the physical address space. Cap the maximum usable RAM area * at 4 GiB to avoid DMA buffers from being allocated beyond the 32-bit * boundary that most devices can address. + * + * Additionally, ARM64 devices typically run a secure monitor in EL3 and + * U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3 + * code and data. These carve-outs are located at the top of 32-bit address + * space. Restrict U-Boot's RAM usage to well below the location of those + * carve-outs. Ideally, we would the secure monitor would inform U-Boot of + * exactly which RAM it could use at run-time. However, I'm not sure how to + * do that at present (and even if such a mechanism does exist, it would + * likely not be generic across all forms of secure monitor). */ ulong board_get_usable_ram_top(ulong total_size) { - if (gd->ram_top > 0x100000000) - return 0x100000000; + if (gd->ram_top > 0xe0000000) + return 0xe0000000;
return gd->ram_top; }