Page MenuHomeFreeBSD

stand: Support (and prefer) the SMBIOS 64-bit Entry Point Structure
AcceptedPublic

Authored by allanjude on Feb 17 2021, 9:34 PM.

Details

Summary

Continue to set the old hint to avoid breaking older kernels

Sponsored by: Ampere Computing LLC
Submitted by: Klara Inc.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 37335
Build 34224: arc lint + arc unit

Event Timeline

allanjude added inline comments.
stand/libsa/smbios.c
108

In the original review, @andrew indicated we would want to keep doing both loops here: https://reviews.freebsd.org/D28707#inline-178708

This revision is now accepted and ready to land.Feb 17 2021, 9:44 PM
stand/efi/loader/main.c
1163–1164

because smbios_detect() "locks in" on the first smbios entry point it's given, doing smbios_detect as either table type is found prefers the earlier table, and not smbios3 over smbios. Maybe this whole loop could be dropped for:

void *smbios_ep, *smbios3_ep;
bool smbios_found;
 
smbios_found = false;
smbios_ep = efi_get_table(&smbios);
smbios3_ep = efi_get_table(&smbios3);
if (smbios3_ep != NULL) {
  setenv("hint.smbios3.0.mem", ...);
  smbios_detect(smbios3_ep);
}
if (smbios_ep != NULL) {
  setenv("hint.smbios.0.mem", ...);
  smbios_detect(smbios_ep);
}
1163–1164

we wouldn't want to set hint.smbios.0.mem to the address of the smbios3 entry point, as it's a different format.

manu requested changes to this revision.Feb 17 2021, 10:06 PM
manu added inline comments.
stand/efi/loader/main.c
1163

Doing both memcmp here and do another one after doesn't seems the best things to do.

This revision now requires changes to proceed.Feb 17 2021, 10:06 PM

Switch to Scott's newer suggested code that is much cleaner

This revision is now accepted and ready to land.Jul 15 2021, 9:20 AM

Ping - is there any work left to do here or can this be merged and closed?

Ping - is there any work left to do here or can this be merged and closed?

This specific piece is ready to land, but many others in the stack are not accepted yet.
I need to rebase them all and re-test it on the target hardware.

If this specific bit is somehow meaningful for you, I can land it by itself if that makes sense.

@allanjude not necessary, but "nice to have" as it resolves an outstanding bug in sysutils/hw-probe on ACPI-based arm64 systems