From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CF08C21A0912C for ; Thu, 18 May 2017 08:28:53 -0700 (PDT) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 330A7800BA; Thu, 18 May 2017 15:28:53 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx3-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A201460061; Thu, 18 May 2017 15:28:50 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx3-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 8F42760070; Thu, 18 May 2017 15:28:49 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 18 May 2017 16:28:45 +0100 To: CC: References: <1548dc48-890d-29e0-0bdc-5df3ce545e5b@solarflare.com> <83202bed-050e-cf5d-a3f3-13b8a83ad739@solarflare.com> <800d8d0d8b4841eaa43d75d0939b6521@ausx13mps335.AMER.DELL.COM> From: "Tomas Pilar (tpilar)" Message-ID: <8aa8fe53-b9f5-64c7-66ba-b18555087a99@solarflare.com> Date: Thu, 18 May 2017 16:28:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <800d8d0d8b4841eaa43d75d0939b6521@ausx13mps335.AMER.DELL.COM> X-Originating-IP: [10.17.20.51] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23076.003 X-TM-AS-Result: No--16.883500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1495121331-DpkW5NN7oZmW Subject: Re: SMBios configuration table not present until late stage of boot X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:28:54 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US This is what I was afraid of. I am writing an IHV network driver that lives in optionROM. Cheers, Tom On 18/05/17 16:25, Jim.Dailey@dell.com wrote: > It is a tricky problem. > > What I would like is for a new protocol to be defined, which should > not rely on devices, to contain certain identifying information > like this that would be useful to device drivers. It could be > created early in DXE. > > What I fear is some future requirement that SMBIOS be made available > at some definitive time pre-OS boot. > > You may have to get support from the BIOS vendor. If you are doing a > driver for a particular system, that might not be too bad of a > solution; but if you're trying to develop some generic driver, I > don't have a good suggestion. > > Regards, > Jim > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tomas Pilar (tpilar) > Sent: Thursday, May 18, 2017 10:14 AM > To: Dailey, Jim > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] SMBios configuration table not present until late stage of boot > > This does make sense. Do you have a suggestion how I would go about > finding/creating a unique identifier for the system during preboot? > > Cheers, > Tom > > On 18/05/17 16:11, Jim.Dailey@dell.com wrote: >> Not a helpful comment, but I wanted to air my feelings on the topic: >> >> I view SMBIOS as data strictly for OS-level consumption and not for >> any pre-boot code. I'm sure I'm in the minority, however. >> >> One of the problems is that the BIOS needs to have scanned all >> devices/resources and perhaps executed a connect all before the >> tables can be generated (or at least completed). >> >> Regards, >> Jim >> >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tomas Pilar (tpilar) >> Sent: Thursday, May 18, 2017 10:01 AM >> To: edk2-devel@lists.01.org >> Subject: [edk2] SMBios configuration table not present until late stage of boot >> >> Hi, >> >> I am trying to read the system UUID from the System Table (Type 1) in >> the SMBios set of tables. I am doing this during DriverBinding.Start() >> part of the UEFI_DRIVER initialisation. Unfortunately the >> gST->ConfigurationTable only contains 6 tables and SMBios is not one of >> them. >> >> Once I boot into UEFI shell or start a PXE booting process, the >> gST->ConfigurationTable now contains 8 tables and SMBios is one of the >> two new tables. If I however only boot to a HDD, this never seems to >> happen. >> >> Can someone offer some insight why this might be so and how would I go >> about forcing the platform to provide the SMBios in >> gST->ConfigurationTable at a sensible point? >> >> Incidentally it seems ExitBootServices is not signaled on this platform >> if the boot goes through to HDD either, which is another strange thing ... >> >> Cheers, >> Tom >> >> >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel