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