diff options
author | Stephen Warren <swarren@nvidia.com> | 2018-08-31 00:43:44 +0300 |
---|---|---|
committer | Alexander Graf <agraf@suse.de> | 2018-09-23 22:55:29 +0300 |
commit | 0797f7f0b7e1d7853e2842ddc235ffef139fa792 (patch) | |
tree | 88c5bd96b35f8801385dedadc50848754daa4c83 /lib | |
parent | 9b5e6396bff5ede22f880c38915da5538e8bd117 (diff) | |
download | u-boot-0797f7f0b7e1d7853e2842ddc235ffef139fa792.tar.xz |
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>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions