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

[Peter Robinson]

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

For reference on the TX1 this patch doesn't fix the problem I've seen
on TX series that I previously sent the patch enabling the bounce
buffer option on the TX2, if I enable bounce buffers it works as I
need with or without this patch. I didn't test TX2 but can if it's
useful (I had to power up the TX1 for other reasons this morning).

Peter