On 08/01/2018 06:17 PM, Stephen Warren 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.
Memory banks and gd->top together cannot reflect unusable memory regions in the middle of the RAM area.
To be consistent reflect all information in the device tree and calculate gd->ram_top from the device tree information.
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.
The situation before the patch was really buggy. It is sufficient if you get the Jetson device tree right.
Best regards
Heinrcih