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

[Alexander Graf]

On 08/02/2018 02:15 PM, Simon Glass wrote:
> Hi,
>
> On 1 August 2018 at 10:17, Stephen Warren <swarren at 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 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.
>>
>> 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