[PATCH 1/1] efi_loader: create memory reservations in ACPI case

[Heinrich Schuchardt]

On 11/18/23 18:58, Simon Glass wrote:
> Hi Heinrich,
> 
> On Sat, 18 Nov 2023 at 10:34, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
>>
>> On 11/18/23 18:10, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Thu, 16 Nov 2023 at 02:29, Heinrich Schuchardt
>>> <heinrich.schuchardt at canonical.com> wrote:
>>>>
>>>> ACPI tables cannot convey memory reservations for least ARM and RISC-V.
>>>> x86 uses the BIOS E820 table for this purpose. We cannot simply ignore the
>>>> device-tree when booting via ACPI.
>>>
>>> Why is that? I had thought that we had to use one or the other. Isn't
>>> the devicetree irrelevant when booting with ACPI, so we can just drop
>>> it?
>>
>> Linux Documentation/arch/arm64/acpi_object_usage.rst, line 718f
>> describes the mechanism to convey memory information as follows:
>>
>> "For arm64, we will only support UEFI for booting with ACPI, hence the
>> UEFI GetMemoryMap() boot service is the only mechanism that will be used."
>>
>> With the patch we tell the UEFI sub-system which memory areas are
>> reserved (e.g. for TF-A on ARM or for OpenSBI on RISC-V). This
>> information is inferred from the device-tree. The operating system will
>> collect this information by calling GetMemoryMap() immediately before
>> ExitBootServices().
>>
>> Without the patch Linux on RISC-V using ACPI crashed when illegally
>> accessing the memory reserved for OpenSBI.
> 
> OK thank you, I misunderstood it.
> 
> Reviewed-by: Simon Glass <sjg at chromium.org>
> 
> Perhaps someone could convert efi_carve_out_dt_rsv() to use the ofnode API?

Is there any ofnode API to retrieve reservations as easily as with 
fdt_get_mem_rsv(), fdt_num_mem_rsv()?

boot/image-fdt.c, boot/fdt_region.c, boot/fdt_support.c, cmd/fdt.c all 
use the libfdt API directly.

Best regards

Heinrich