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

Simon Glass sjg at chromium.org
Thu Aug 2 12:15:08 UTC 2018


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...?

Regards,
Simon


More information about the U-Boot mailing list