[PATCH v2] smbios: arm64: Allow table to be written at a fixed addr

[Heinrich Schuchardt]

On 10/25/23 04:49, Simon Glass wrote:
> Hi Heinrich,
>
> On Tue, 24 Oct 2023 at 18:22, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>>
>>
>> Am 25. Oktober 2023 01:31:19 MESZ schrieb Simon Glass <sjg at chromium.org>:
>>> U-Boot typically sets up its malloc() pool near the top of memory. On
>>> ARM64 systems this can result in an SMBIOS table above 4GB which is
>>> not supported by SMBIOSv2.
>>>
>>> Work around this problem by providing a new option to choose an address
>>> below 4GB (but as high as possible), if needed.
>>
>> You must not overwrite memory controlled by the EFI subsystem without calling its allocator.  We should provide SMBIOS 3. SMBIOS 2 is only a fallback for outdated tools.
>
> That is not my intention and I don't believe this code does that. EFI
> is not running at this point, is it?

The function install_smbios_table() only exists if CONFIG_EFI_LOADER=y.

We have:
EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, install_smbios_table);
This is invoked after efi_memory_init().

The EFI specification requires that the memory area occupied by the
SMBIOS table uses one of a specific set of memory types where
EfiRuntimeServicesData is recommended. So you must call

u64 addr = UINT_MAX;
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
EFI_RUNTIME_SERVICES_DATA, efi_size_in_pages(size), *addr);

to allocate the memory. If the return code is not EFI_SUCCESS, no memory
below 4 GiB is available.

>
> The bit I am confused about is that we don't support SMBIOS3 in
> U-Boot. I am trying to fix an introduced bug...

I would not know why we should not use SMBIOS 3.

Best regards

Heinrich