[U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim

[Heinrich Schuchardt]

On 4/12/19 7:36 PM, Ilias Apalodimas wrote:
> Hi Heinrich,
>
>>
>> Hello Ilias, hello Ard,
>>
>> please, have a look at this patch:
>>
>> efi_loader: update virtual address in efi_mem_carve_out
>> https://lists.denx.de/pipermail/u-boot/2019-April/364937.html
>>
>> Possibly the bug reported here could have contributed the Linux crash
>> you experienced.
>>
> Thanks for the heads up.
> Unfortunately i've already tried that. I was talking to Patrick before he posted
> the patch upstream. This seems unrelated anyway (all my tests were with the
> patch applied regardless)
> https://lore.kernel.org/linux-arm-kernel/20190411151320.GA23031@apalos/
> This has an explanation on the problem.
>
> The tl;dr version (quoting Russell)
>
> "It is also designed to allow hardware-section sized mappings (making
> it possible to map sections on 1MB granularity) but as a single Linux
> page table always occupies 2MB, it is not permitted for the unused
> half of an aligned 2MB slot to be used for a page table mapping -
> hence this BUG_ON().
> The ARM early mapping routines are intentionally designed such that
> areas of memory that they are asked to map are non-overlapping - it
> is the caller's responsibility to ensure this."
>
> In order to make sure this won't trigger we got to make sure that the fdt is
> placed on the first 1mb boundary of the memory (of any 2mb aligned area)
> thus forcing the kernel to init the pte's correctly,
> instead of trying to do section mappings for the memory in that area.
>
> The problem happens when you have a small no-map section within a 2MB
> region, and it does cross the even-odd 1MB boundary.
> So fdt at 0x7f00000 (or any other are after that like 0xc7f01000) will crash
> the kernel with a BUG_ON().
> Placing it in 0x7e01000-7eFF000 would be fine (on armv7's with LPAE off in the
> kernel)
>

I think Linux cannot make any assumptions about UEFI memory layout if it
is not explicitly specified in the UEFI spec. Everything is simply a
Linux bug.

Concerning FDT I suggest to stick to what EDK II does: use
EfiBootServicesData.

Best regards

Heinrich

> Thanks
> /Ilias
>