summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-tegra
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2015-07-29 13:47:58 -0600
committerTom Warren <twarren@nvidia.com>2015-08-06 10:50:02 -0700
commit424afc0a9591796106b2c6f3f812ceaa553bcb32 (patch)
tree328577406de3b4124f8d5eb1c508dd405f99d617 /arch/arm/mach-tegra
parent1264f0f6c6e42c076c8e5767757880140b967f71 (diff)
downloadtalos-obmc-uboot-424afc0a9591796106b2c6f3f812ceaa553bcb32.tar.gz
talos-obmc-uboot-424afc0a9591796106b2c6f3f812ceaa553bcb32.zip
ARM: tegra: restrict usable RAM size further
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> Signed-off-by: Tom Warren <twarren@nvidia.com>
Diffstat (limited to 'arch/arm/mach-tegra')
-rw-r--r--arch/arm/mach-tegra/board2.c13
1 files changed, 11 insertions, 2 deletions
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
index 2927b4ed12..41e9341874 100644
--- a/arch/arm/mach-tegra/board2.c
+++ b/arch/arm/mach-tegra/board2.c
@@ -290,11 +290,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;
}
OpenPOWER on IntegriCloud