From: Andrew Fish <afish@apple.com>
To: "Tomas Pilar (tpilar)" <tpilar@solarflare.com>
Cc: Jim.Dailey@dell.com, edk2-devel@lists.01.org
Subject: Re: SMBios configuration table not present until late stage of boot
Date: Thu, 18 May 2017 10:22:48 -0700 [thread overview]
Message-ID: <C1890D41-6B41-491A-B271-119D0986DD44@apple.com> (raw)
In-Reply-To: <8aa8fe53-b9f5-64c7-66ba-b18555087a99@solarflare.com>
> On May 18, 2017, at 8:28 AM, Tomas Pilar (tpilar) <tpilar@solarflare.com> wrote:
>
> This is what I was afraid of. I am writing an IHV network driver that lives in optionROM.
>
Tomas,
I think this issue is fixed in the current Specs and edk2 code. The PI Spec defines an Protocol, gEfiSmbiosProtocolGuid, for SMBIOS and the current edk2 implementation publishes the tables as data comes in.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.c#L516
//
// Some UEFI drivers (such as network) need some information in SMBIOS table.
// Here we create SMBIOS table and publish it in
// configuration table, so other UEFI drivers can get SMBIOS table from
// configuration table without depending on PI SMBIOS protocol.
//
SmbiosTableConstruction (Smbios32BitTable, Smbios64BitTable);
Looks like your issue is working on older systems?
Thanks,
Andrew Fish
> 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 <Jim_Dailey@Dell.com>
>> 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
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2017-05-18 17:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 15:00 SMBios configuration table not present until late stage of boot Tomas Pilar (tpilar)
2017-05-18 15:11 ` Jim.Dailey
2017-05-18 15:13 ` Tomas Pilar (tpilar)
2017-05-18 15:25 ` Jim.Dailey
2017-05-18 15:28 ` Tomas Pilar (tpilar)
2017-05-18 17:22 ` Andrew Fish [this message]
2017-05-18 18:26 ` Laszlo Ersek
2017-05-19 10:32 ` Tomas Pilar (tpilar)
2017-05-19 17:36 ` Andrew Fish
2017-05-19 20:48 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C1890D41-6B41-491A-B271-119D0986DD44@apple.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox