Am 30.03.23 um 10:53 schrieb Gerd Hoffmann:
> On Thu, Mar 30, 2023 at 10:04:02AM +0200, Fiona Ebner wrote:
>> Am 28.11.22 um 06:40 schrieb Gerd Hoffmann:
>>> Instead of using hard-coded strings ("0.0.0" for BiosVersion etc)
>>> which is mostly useless read the PCDs (PcdFirmwareVendor,
>>> PcdFirmwareVersionString and PcdFirmwareReleaseDateString) and
>>> build the string table dynamuically at runtime.
>>>
>>> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
>>> ---
>>> .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 6 +
>>> .../XenSmbiosPlatformDxe.inf | 9 +-
>>> OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 115 +++++++++++-------
>>> 3 files changed, 85 insertions(+), 45 deletions(-)
>>>
>>
>> Hi,
>> after this patch, certain SMBIOS values are different[2]. We got a
>> report that the different vendor causes issues with hardware keys[0].
>> And, as I learned from the patch fixing it, the missing date can cause
>> issues with Windows[1].
>
> See a0f9628705e3 ("OvmfPkg/SmbiosPlatformDxe: tweak fallback release
> date") for the windows issue.
>
Should the date string be "02/02/2022" rather than "2/2/2022" in that
commit?
I was wondering whether month or date comes first and found the
following in ([0], section 7.1):
> String number of the BIOS release date.
> The date string, if supplied, is in either
> mm/dd/yy or mm/dd/yyyy format. If the year
> portion of the string is two digits, the year is
> assumed to be 19yy.
> NOTE: The mm/dd/yyyy format is required for
> SMBIOS version 2.3 and later.
> You can set those using
> 'build --pcd PcdFirmwareVersionString="L${string}\\0" ...'
> (same for the other pcds).
I had already found the build option in the discussion of v1 of this
patch, but now I'm wondering: is the "\\0" explicitly required? My build
yesterday seemed to work without it, but I guess, I'll just add it to
make sure.
>>> It'd be
>>> good to understand what upstream's intention was there - are they
>>> expecting each distributor to set our own values, and if so, is there
>>> a scheme we should follow?
>
> The intention is to allow setting version information to whatever makes
> sense for you. A hardcoded "0.0.0" version certainly isn't very useful
> when it comes to bug reporting etc.
>
> Fedora leaves vendor unchanged, sets release date to the commit date of
> the edk2-stableyyyymm stable tag the build is based on and version to
> the rpm package version, i.e. like this ...
>
> Handle 0x0000, DMI type 0, 26 bytes
> BIOS Information
> Vendor: EDK II
> Version: edk2-20230301gitf80f052277c8-1.test6.fc37
> Release Date: 03/01/2023
> [ ... ]
>
> ... which allows to easily identify the exact firmware build running.
> The one listed above happens to be this one:
>
> https://download.copr.fedorainfracloud.org/results/kraxel/edk2.testbuilds/fedora-37-x86_64/05727085-edk2/
>
Thank you for the explanation!
Best regards,
Fiona
[0]:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102172): https://edk2.groups.io/g/devel/message/102172
Mute This Topic: https://groups.io/mt/95304965/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
