From owner-svn-src-all@freebsd.org Fri Oct 14 17:27:11 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBB4EC12430; Fri, 14 Oct 2016 17:27:11 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id AA6EBAC7; Fri, 14 Oct 2016 17:27:11 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 14 Oct 2016 10:40:04 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.14.4) with ESMTP id u9EHR5eT066494; Fri, 14 Oct 2016 10:27:05 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.14.4/Submit) id u9EHR5sL066493; Fri, 14 Oct 2016 10:27:05 -0700 (PDT) (envelope-from ambrisko) Date: Fri, 14 Oct 2016 10:27:05 -0700 From: Doug Ambrisko To: Warner Losh Cc: Doug Ambrisko , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r307326 - head/sys/boot/efi/loader Message-ID: <20161014172705.GA65545@ambrisko.com> References: <201610141710.u9EHArlL089412@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:27:11 -0000 On Fri, Oct 14, 2016 at 11:16:02AM -0600, Warner Losh wrote: | 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. The reason I picked hint was it could be put /boot/device.hints to make it work as well and that it was a hint. Other standards in the future might use other methods. Looking back over the email I had with John he had suggested hint.smbios.0.anchor to make this look different. This code had been hanging around for so long I forgot about that and we were using hint.smbios.0.mem in our shipping code base. However, I hope that nothing would use this except for smbios(4) and for people to make smbios(4) useful for this info. Thanks, Doug A. | On Fri, Oct 14, 2016 at 11:10 AM, Doug Ambrisko 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))) | >