On 14.06.18 21:26, Heinrich Schuchardt wrote: > On 06/14/2018 09:13 PM, Alexander Graf wrote: >> >> >> On 14.06.18 21:01, Simon Glass wrote: >>> Hi Alex, >>> >>> On 14 June 2018 at 12:22, Alexander Graf <ag...@suse.de> wrote: >>>> We try hard to make sure that SMBIOS tables live in the lower 32bit. >>>> However, when we can not find any space at all there, we should not >>>> error out but instead just fall back to map them in the full address >>>> space instead. >>>> >>>> Signed-off-by: Alexander Graf <ag...@suse.de> >>>> --- >>>> lib/efi_loader/efi_smbios.c | 11 +++++++++-- >>>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> Does that actually work? I thought the addresses in the table were >>> always 32-bit? >> >> >> There is only a single table reference which indeed is 32bit: >> se->struct_table_address. >> >> That address however is unused in the EFI case usually, because the >> SMBIOS information is already encapsulated in a table, so there's no >> need to search through address space for a _DMI_ entry: >> >> https://github.com/mirror/dmidecode/blob/master/dmidecode.c#L5122 >> >> >> Alex >> > We still have an open issue with E820 memory reservations not observed > by Linux because they are not mirrored in the memory map. Could the same > happen with smbios?
The SMBIOS tables get allocated from the EFI pool in lib/efi_loader/efi_smbios.c. So the e820 patch fell through the cracks? Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
