On 31.07.18 22:20, Stephen Warren wrote:
On 07/31/2018 02:15 PM, Alexander Graf wrote:
Am 31.07.2018 um 22:04 schrieb Stephen Warren swarren@wwwdotorg.org:
On 07/31/2018 02:03 PM, Alexander Graf wrote:
Am 31.07.2018 um 21:44 schrieb Stephen Warren swarren@wwwdotorg.org:
From: Stephen Warren swarren@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.
I see. The main problem I just see is exactly the rationale you described above: The EFI memory map will be used by the booted OS to indicate which regions are usable. If they really aren't, then we need to properly annotate that in the EFI memory map as well, because otherwise Linux may end up writing to carved out secure regions of RAM.
Alex