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

[Stephen Warren]

On 07/31/2018 02:15 PM, Alexander Graf wrote:
> 
> 
>> Am 31.07.2018 um 22:04 schrieb Stephen Warren <swarren at wwwdotorg.org>:
>>
>> On 07/31/2018 02:03 PM, Alexander Graf wrote:
>>>> Am 31.07.2018 um 21:44 schrieb Stephen Warren <swarren at wwwdotorg.org>:
>>>>
>>>> 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.
>>>>
>>>> [1] For example, when some peripherals can't access RAM above 4GiB, it's
>>>> simplest to force U-Boot's ram_top to a smaller value to avoid dealing
>>>> with this issue more explicitly. However, the RAM bank definitions still
>>>> describe the unusable RAM so that the booted OS has access to it, since
>>>> the OS can typically deal with such restrictions in a more complex
>>>> manner.
>>> That's what we have the efi bounce buffers for. Can't we just enable those for tegra?
>>
>> No, because that wouldn't help all the non-EFI code, or cause the RAM to be mapped in the page tables due to the non-EFI code not needing it.
> 
> The non-efi code can still rely on ram_top just fine, no? I was more thinking of enabling the bounce buffer config option as alternative to your patch.

A lot more besides enabling that option would have to be done. The issue 
here is that EFI is attempting to use RAM that's not in the page tables 
and hence crashes. Enabling bounce buffers alone isn't going to help 
that; we'd also have to rejig the U-Boot MMU code to set up page table 
entries for the entire of the RAM banks rather than just the usable RAM, 
and then we've have to develop some new way of preventing U-Boot from 
mapping RAM that's part of the RAM banks but shouldn't be mapped because 
e.g. it's part of the secure carveout that can't be mapped in the MMU in 
order to ensure that the CPU never pre-fetches that RAM to avoid taking 
security faults on the fetch. The fact that ram_top is lower than the 
HW-defined RAM limit exists for reasons other than just preventing use 
of RAM that some peripheral HW can't access, so bounce buffers will only 
solve one of the causes, not everything.