On 20.09.18 21:11, Stephen Warren wrote:
On 09/01/2018 03:58 AM, Alexander Graf wrote:
From: Stephen Warren swarren@nvidia.com
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
Thanks, applied to efi-next
They don't seem to have shown up in u-boot/master though...
Yes, thanks to the new sandbox support we were able to run more tests than before and suddenly caught one that only got fixed very recently. Because of that we didn't pass travis and I didn't want to send a pull request that would break our automated testing :)
Should be on its way soon (today if things work out as planned).
Alex