[U-Boot] [PATCH] arm64: mvebu: fix crash in EFI memory allocation

[Alexander Graf]

On 29.11.18 19:54, Baruch Siach wrote:
> Hi Stephen,
> 
> Adding Heinrich Schuchardt.
> 
> Stephen Warren writes:
>> On 11/22/18 8:19 AM, Baruch Siach wrote:
>>> Adding Stephen Warren to Cc.
>>>
>>> On Thu, Nov 22, 2018 at 02:30:34PM +0000, Alexander Graf wrote:
>>>>> Am 22.11.2018 um 11:42 schrieb Baruch Siach <baruch at tkos.co.il>:
>>>>>
>>>>> EFI memory allocation code return values that are not mapped by U-Boot
>>>>> MMU. This causes a crash when tftp calls efi_set_bootdev(). Fix this
>>>>> similarly to commit 0797f7f0b7e1 ("ARM: tegra: reserve unmapped RAM so
>>>>> EFI doesn't use it").
>>>>>
>>>>> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
>>>>
>>>> Hm, how about we fox this up in the common memory registration function and
>>>> add addresses > board_get_usable_ram_top() as boot time data?
>>>
>>> That would be much nicer indeed. Where should I look in lib/efi_loader/ to
>>> implement that?
>>>
>>> With that in place we can revert commit 0797f7f0b7e1, right? Stephen, do you
>>> concur?
>>
>> I believe so, yes. I'm not sure why it's acceptable to fix the EFI allocator
>> to solve this now, when it wasn't acceptable before though.
> 
> I read the previous discussion[1] from July/August. If I understand the
> conclusion correctly, efi_add_memory_map() provides information that is
> vital to the correctness of the EFI memory map, and is platform
> specific. Is that correct?
> 
> If so, then this patch (actually, its v2) is the correct solution for
> Armada 8K. A possible improvement to the EFI memory allocation code
> would be a warning instead of crash. Would that be acceptable?

So the problem is that the EFI memory map needs to describe all memory.
We can't just leave out chunks because U-Boot doesn't map them, as then
Linux wouldn't get to see them either.

What we can do however, is mark regions that should not be used during
boot time as "allocated by firmware". That way the memory map still
exposes the full map, but we make sure no payload makes use of high
addresses when they're not mapped.

I honestly don't remember why exactly I didn't want to put in support
for board_get_usable_ram_top() in the generic code. It's a reasonable
interface to influence the allocation code. I must've thought it's
nvidia specific, so a one-off and thus made more sense in their board file.

Let me quickly write up a patch of what I have in mind.


Alex