[PATCH 3/5] smbios: Use SMBIOS 3.0 to support an address above 4GB
Caleb Connolly
caleb.connolly at linaro.org
Tue Oct 17 19:59:37 CEST 2023
Hi Both,
[...]
>>>
>>> @@ -513,13 +517,23 @@ ulong write_smbios_table(ulong addr)
>>> */
>>> table_addr = (ulong)map_sysmem(tables, 0);
>>> if (sizeof(table_addr) > sizeof(u32) && table_addr > (ulong)UINT_MAX) {
>>
>> You have to check the end address of the table not the start address here.
>>
>> The SMBIOS specification says that you should always supply a 32bit
>> SMBIOS entry point. Of course this is not possible on boards that don't
>> have low memory.
>>
>> In install_smbios_table() this can be achieved by calling
>> efi_allocate_pages() with EFI_MAX_ALLOCATE_TYPE and a maximum address of
>> 4 GiB - 1. Only if this fails use high memory.
>
> Hmm perhaps we need a way to allocate memory below 4GB in U-Boot? How
> does this EFI function work?
Yes, prior to 53fab13a7b11 ("efi: Use the installed SMBIOS tables")
efi_allocate_pages() was called directly from efi_smbios_register(). My
boards all malloc() memory above the 4GB boundary and I just recently
rebased and hit a regression caused by this.
In my testing, calling efi_allocate_pages() from install_smbios_table()
did work, but I figure that's probably not intended behaviour...
I can confirm that this series does allow my boards to boot again, but
dmidecode is unable to decode the SMBIOS 3.0 table (even with
STRICT_DEVMEM disabled fwiw).
Below is EFI and board memory map info after applying this patch series.
=> efidebug tables
Cannot read EFI system partition
Cannot read EFI system partition
Failed to persist EFI variables
000000017ea22040 32313633-3532-3634-2d66-3765662d3463 EFI Conformance
Profiles Table
000000017ea21040 36366265-3139-6138-2d37-6565662d3430 Runtime properties
000000017fb13000 64663266-3531-3434-2d39-3739342d3461 (unknown)
=> efidebug memmap
Type Start End Attributes
================ ================ ================ ==========
CONVENTIONAL 0000000080000000-000000017ea1f000 WB
BOOT DATA 000000017ea1f000-000000017ea21000 WB
RUNTIME DATA 000000017ea21000-000000017ea22000 WB|RT
BOOT DATA 000000017ea22000-000000017ea23000 WB
RUNTIME DATA 000000017ea23000-000000017ea25000 WB|RT
BOOT DATA 000000017ea25000-000000017ea26000 WB
RUNTIME DATA 000000017ea26000-000000017ea36000 WB|RT
BOOT DATA 000000017ea36000-000000017eaef000 WB
BOOT CODE 000000017eaef000-000000017fb13000 WB
RUNTIME DATA 000000017fb13000-000000017fb14000 WB|RT
BOOT CODE 000000017fb14000-000000017ff20000 WB
RUNTIME CODE 000000017ff20000-000000017ff30000 WB|RT
BOOT CODE 000000017ff30000-0000000180000000 WB
BOOT DATA 0000000180000000-000000027c7a0000 WB
=> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000080000000
-> size = 0x0000000100000000
DRAM bank = 0x0000000000000001
-> start = 0x0000000180000000
-> size = 0x00000000fc7a0000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x000000017ff26000
reloc off = 0x000000017ff26000
Build = 64-bit
fdt_blob = 0x000000017faef6c0
new_fdt = 0x000000017faef6c0
fdt_size = 0x0000000000017680
Video = framebuffer at 9D400000 active
FB base = 0x000000009d400000
FB size = 1080x2160x32
lmb_dump_all:
memory.cnt = 0x1 / max = 0x40
memory[0] [0x80000000-0x27c79ffff], 0x1fc7a0000 bytes flags: 0
reserved.cnt = 0x7 / max = 0x40
reserved[0] [0x85700000-0x85cfffff], 0x00600000 bytes flags: 4
reserved[1] [0x85e00000-0x85efffff], 0x00100000 bytes flags: 4
reserved[2] [0x85fc0000-0x890fffff], 0x03140000 bytes flags: 4
reserved[3] [0x8ab00000-0x8c416fff], 0x01917000 bytes flags: 4
reserved[4] [0x8c500000-0x97bfffff], 0x0b700000 bytes flags: 4
reserved[5] [0x9d400000-0x9f7fffff], 0x02400000 bytes flags: 4
reserved[6] [0x17ea1f000-0x27c79ffff], 0xfdd81000 bytes flags: 0
devicetree = board
arch_number = 0x0000000000000000
TLB addr = 0x000000017fff0000
irq_sp = 0x000000017faef6b0
sp start = 0x000000017faef6b0
Early malloc usage: a78 / 2000
>
> I don't think EFI has been set up by the time this function is called.
>
> Regards,
> Simon
--
// Caleb (they/them)
More information about the U-Boot
mailing list