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

Stephen Warren swarren at wwwdotorg.org
Sat Aug 4 17:39:34 UTC 2018


On 08/04/2018 10:56 AM, Heinrich Schuchardt wrote:
> On 08/02/2018 07:00 PM, Stephen Warren wrote:
>> On 08/01/2018 11:57 PM, Heinrich Schuchardt wrote:
>>> 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.
>>
>> Sure this is possible. For example, a common set of memory banks for
>> Tegra is:
>>
>> bank 0:
>> start:  0x080000000
>> length: 0x070000000
>> limit:  0x0f0000000
>> bank 1:
>> start:  0x100000000
>> length: 0x080000000
>> limit:  0x180000000
>>
>> gd->ram_top = 0x0f0000000
>> That is set so that U-Boot itself (not just the UEFI code) doesn't use
>> RAM above 4GB due to HW peripherals that can't access such RAM. The RAM
>> above 4GB is left in the DRAM banks so that the kernel can use it for
>> non-DMA purposes
> 
> Hello Stephen,
> 
> this explanation makes the problem much clearer. Memory usable by the
> operating system but not by the firmware cannot be expressed in the
> device tree.
> 
> If bank 1 cannot be used by U-Boot but can be used by the operating
> system we should mark it as EFI_BOOT_SERVICES_DATA by calling
> efi_add_memory_map() in arch/arm/mach-tegra/board2.c. This will indicate
> to the operating system that it may use this memory after exiting boot
> services and the U-Boot EFI subsystem will not use this region. This
> call could be done in dram_init_banksize().
> 
> Could you give this a try, please.

Please revert the patch first, then we can fix this later (I sent the
revert as a patch already). I'm leaving on vacation right now, so won't
be able to look at this for at least 2 weeks. We need to fix the
regression immediately. Equally, EFI shouldn't require boards to provide
memory information to U-Boot in a different way than the rest of U-Boot
as I mentioned, so even if this WAR works, it doesn't sound scalable
across all boards.


More information about the U-Boot mailing list