Love the functionality, but don't like using the 'hint' namespace for
this. Can we change it now before too many things depend on it? We had
similar issues in ACPI and moved it to the 'acpi' space. Can we move
this to the 'smbios' space please?

The reason is that 'hint' is special and sometimes filtered out, so it
is a poor choice to export data from the boot loader to the kernel.

Warner

On Fri, Oct 14, 2016 at 11:10 AM, Doug Ambrisko <ambri...@freebsd.org> wrote:
> Author: ambrisko
> Date: Fri Oct 14 17:10:53 2016
> New Revision: 307326
> URL: https://svnweb.freebsd.org/changeset/base/307326
>
> Log:
>   In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
>   etc. can find out where the SMBIOS entry point is located.  In pure
>   UEFI mode the BIOS is not mapped into the standard address space so the
>   SMBIOS table might not appear between 0xf0000 and 0xfffff.  The
>   UEFI environment can report this the location of the anchor.  If it is
>   reported then expose it as hint.smbios.0.mem.  This can then be used
>   by other tools.  However, we should make smbios(4) useful and have it
>   take this value and provide accesor function so ipmi(4) etc. don't
>   have to parse and figure things about the SMBIOS table.  I have some
>   simple patches to smbios(4) to expose this address as sysctl and
>   for ipmi(4) to get the base address.  However, the real fix is to
>   have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
>   parse it out and return it.  This would make smbios(4) useful and reduce
>   duplicated code.  If this address doesn't point to the anchor then
>   finding SMBIOS info. will fail as if this didn't exist.  So there should
>   be no harm.
>
>   With this change and the following hack, dmidecode works on a bunch of
>   UEFI machines that I tested:
>
>     if kenv hint.smbios.0.mem > /dev/null
>     then
>           mkdir -p /sys/firmware/efi
>           mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
>           echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
>     fi
>
>   Linux exposes this information via the /sys/firmware/efi/systab file which
>   dmidecode looks at.  We should update dmidecode to do this the FreeBSD
>   way when we determine what that is!
>
>   Reviewed by:  jhb
>
> Modified:
>   head/sys/boot/efi/loader/main.c
>
> Modified: head/sys/boot/efi/loader/main.c
> ==============================================================================
> --- head/sys/boot/efi/loader/main.c     Fri Oct 14 17:04:07 2016        
> (r307325)
> +++ head/sys/boot/efi/loader/main.c     Fri Oct 14 17:10:53 2016        
> (r307326)
> @@ -235,6 +235,7 @@ main(int argc, CHAR16 *argv[])
>         uint64_t pool_guid;
>         UINTN k;
>         int has_kbd;
> +       char buf[40];
>
>         archsw.arch_autoload = efi_autoload;
>         archsw.arch_getdev = efi_getdev;
> @@ -447,6 +448,9 @@ main(int argc, CHAR16 *argv[])
>         for (k = 0; k < ST->NumberOfTableEntries; k++) {
>                 guid = &ST->ConfigurationTable[k].VendorGuid;
>                 if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) {
> +                       snprintf(buf, sizeof(buf), "%p",
> +                           ST->ConfigurationTable[k].VendorTable);
> +                       setenv("hint.smbios.0.mem", buf, 1);
>                         smbios_detect(ST->ConfigurationTable[k].VendorTable);
>                         break;
>                 }
> @@ -603,7 +607,8 @@ command_configuration(int argc, char *ar
>                 else if (!memcmp(guid, &acpi20, sizeof(EFI_GUID)))
>                         printf("ACPI 2.0 Table");
>                 else if (!memcmp(guid, &smbios, sizeof(EFI_GUID)))
> -                       printf("SMBIOS Table");
> +                       printf("SMBIOS Table %p",
> +                           ST->ConfigurationTable[i].VendorTable);
>                 else if (!memcmp(guid, &dxe, sizeof(EFI_GUID)))
>                         printf("DXE Table");
>                 else if (!memcmp(guid, &hoblist, sizeof(EFI_GUID)))
>
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to