On 10/25/23 04:49, Simon Glass wrote:
Hi Heinrich,
On Tue, 24 Oct 2023 at 18:22, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 25. Oktober 2023 01:31:19 MESZ schrieb Simon Glass sjg@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