forked from pool/u-boot
- Update to v2018.09 - Update to v2018.09-rc3 - Patch queue updated from git://github.com/openSUSE/u-boot.git tumbleweed-2018.09 * Patches added: 0010-ARM-tegra-reserve-unmapped-RAM-so-E.patch - Update to v2018.09-rc2 - Patch queue updated from git://github.com/openSUSE/u-boot.git tumbleweed-2018.09 * Patches dropped: 0010-snow-set-fdtfile.patch - Update to v2018.09-rc1 - Patch queue updated from git://github.com/openSUSE/u-boot.git tumbleweed-2018.09 * Patches dropped: 0011-omap3-beagle-re-enable-EFI-support-.patch OBS-URL: https://build.opensuse.org/request/show/634923 OBS-URL: https://build.opensuse.org/package/show/hardware:boot/u-boot?expand=0&rev=26
67 lines
2.5 KiB
Diff
67 lines
2.5 KiB
Diff
From 18c6f6d2ce73a0e019606981c5878a3b8bfc13ee Mon Sep 17 00:00:00 2001
|
|
From: Stephen Warren <swarren@nvidia.com>
|
|
Date: Thu, 30 Aug 2018 15:43:44 -0600
|
|
Subject: [PATCH] ARM: tegra: reserve unmapped RAM so EFI doesn't use it
|
|
|
|
Tegra U-Boot ensures that board_get_usable_ram_top() never returns a value
|
|
over 4GB, since some peripherals can't access such addresses. However, on
|
|
systems with more than 2GB of RAM, RAM bank 1 does describe this extra
|
|
RAM, so that Linux (or whatever OS) can use it, subject to DMA
|
|
limitations. Since board_get_usable_ram_top() points at the top of RAM
|
|
bank 0, the memory locations describes by RAM bank 1 are not mapped by
|
|
U-Boot's MMU configuration, and so cannot be used for anything.
|
|
|
|
For some completely inexplicable reason, U-Boot's EFI support ignores the
|
|
value returned by board_get_usable_ram_top(), and EFI memory allocation
|
|
routines will return values above U-Boot's RAM top. This causes U-Boot to
|
|
crash when it accesses that RAM, since it isn't mapped by the MMU. One
|
|
use-case where this happens is TFTP download of a file on Jetson TX1
|
|
(p2371-2180).
|
|
|
|
This change explicitly tells the EFI code that this extra RAM should not
|
|
be used, thus avoiding the crash.
|
|
|
|
A previous attempt to make EFI honor board_get_usable_ram_top() was
|
|
rejected. So, this patch will need to be replicated for any board that
|
|
implements board_get_usable_ram_top().
|
|
|
|
Fixes: aa909462d018 ("efi_loader: efi_allocate_pages is too restrictive")
|
|
Signed-off-by: Stephen Warren <swarren@nvidia.com>
|
|
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
---
|
|
arch/arm/mach-tegra/board2.c | 14 ++++++++++++++
|
|
1 file changed, 14 insertions(+)
|
|
|
|
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c
|
|
index 421a71b301..12257a42b5 100644
|
|
--- a/arch/arm/mach-tegra/board2.c
|
|
+++ b/arch/arm/mach-tegra/board2.c
|
|
@@ -6,6 +6,7 @@
|
|
|
|
#include <common.h>
|
|
#include <dm.h>
|
|
+#include <efi_loader.h>
|
|
#include <errno.h>
|
|
#include <ns16550.h>
|
|
#include <usb.h>
|
|
@@ -210,6 +211,19 @@ int board_early_init_f(void)
|
|
|
|
int board_late_init(void)
|
|
{
|
|
+#if CONFIG_IS_ENABLED(EFI_LOADER)
|
|
+ if (gd->bd->bi_dram[1].start) {
|
|
+ /*
|
|
+ * Only bank 0 is below board_get_usable_ram_top(), so all of
|
|
+ * bank 1 is not mapped by the U-Boot MMU configuration, and so
|
|
+ * we must prevent EFI from using it.
|
|
+ */
|
|
+ efi_add_memory_map(gd->bd->bi_dram[1].start,
|
|
+ gd->bd->bi_dram[1].size >> EFI_PAGE_SHIFT,
|
|
+ EFI_BOOT_SERVICES_DATA, false);
|
|
+ }
|
|
+#endif
|
|
+
|
|
#if defined(CONFIG_TEGRA_SUPPORT_NON_SECURE)
|
|
if (tegra_cpu_is_non_secure()) {
|
|
printf("CPU is in NS mode\n");
|