On 08/02/2018 02:15 PM, Simon Glass wrote:
Hi,
On 1 August 2018 at 10:17, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/01/2018 12:07 AM, Heinrich Schuchardt wrote:
On 07/31/2018 09:44 PM, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
Some boards define a maximum usable RAM top that's more restrictive than the ranges defined by U-Boot's memory bank definitions[1]. In this case, the unusable RAM isn't mapped in the page tables, and so the EFI code must not attempt to allocate RAM from outside the usable regions. Fix efi_find_free_memory() to detect when max_addr is unconstrained or out of range, and substitue a valid value.
In this case the board has to call efi_add_memory_map() to mark the reserved region (cf. board/raspberrypi/rpi/rpi.c) or have to mark the memory region as reserved in the device tree (see efi_carve_out_dt_rsv()).
Please, check if the tegra boards with which you had problems do so.
I don't think this makes sense; memory should be managed the same way within U-Boot no matter which part of U-Boot is consuming that memory. Memory regions are currently represented by the content of the memory bank definitions and gd->ram_top. Having different parts of the code define legal RAM usage in different ways is horribly inconsistent.
At this point, I think the best thing is to revert aa909462d018 "efi_loader: efi_allocate_pages is too restrictive" since it causes a regression on Jetson TX1, and we can work out the correct way to fix all this once the system is working again.
That seems OK to me, since I don't think that patch actually fixed anything...?
I think I ran into a problem with the limitation to start_addr_sp in some other case as well, but I can't remember where. So yes, reverting it works for me for now if that gets us forward on the path to make efi_loader work for real on TX1 ;)
Alex