[U-Boot] [PATCH] efi_loader: don't allocate unusable RAM

[Heinrich Schuchardt]

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 at 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