[PATCH] smbios: arm64: Allow table to be written at a fixed addr

[Heinrich Schuchardt]

On 10/25/23 23:09, Tom Rini wrote:
> On Wed, Oct 25, 2023 at 10:52:48PM +0200, Heinrich Schuchardt wrote:
>> On 10/25/23 19:09, Tom Rini wrote:
>>> On Wed, Oct 25, 2023 at 05:28:10PM +0200, Heinrich Schuchardt wrote:
>>>> On 25.10.23 16:28, Tom Rini wrote:
>>>>> On Wed, Oct 25, 2023 at 04:18:20PM +0200, Mark Kettenis wrote:
>>>>>>> Date: Tue, 24 Oct 2023 18:34:05 -0400
>>>>>>> From: Tom Rini <trini at konsulko.com>
>>>>>>>
>>>>>>> On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote:
>>>>>>>>> From: Simon Glass <sjg at chromium.org>
>>>>>>>>> Date: Mon, 23 Oct 2023 00:04:14 -0700
>>>>>>>>>
>>>>>>>>> Hi Caleb,
>>>>>>>>>
>>>>>>>>> On Sat, 21 Oct 2023 at 01:43, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On 21/10/2023 01:45, Simon Glass wrote:
>>>>>>>>>>> U-Boot typically sets up its malloc() pool near the top of memory. On
>>>>>>>>>>> ARM64 systems this can result in an SMBIOS table above 4GB which is
>>>>>>>>>>> not supported by SMBIOSv2.
>>>>>>> [snip]
>>>>>>>> There is absolutely no guarantee that arm64 machines have memory below
>>>>>>>> 4GB.  Examples of SoCs that have no memory below 4GB are AMD's Opteron
>>>>>>>> A1100 SoC and all the recent Apple SoCs.
>>>>>>>
>>>>>>> So one thing to resolve here is where does that requirement about the
>>>>>>> SMBIOS table needing to be below 4GB come from (standards wise), and in
>>>>>>> turn is that obeyed by consumers like say Linux or OpenBSD? Answering my
>>>>>>> own question, maybe in part, https://www.dmtf.org/standards/smbios reads
>>>>>>> to me like there's a v3 and maybe we should be doing what we need to
>>>>>>> support / identify as that, if it doesn't have that restriction?
>>>>>>
>>>>>> Right.  U-Boot implements SMBIOS 2.x which is pretty much obsolete and
>>>>>> uses 32-bit addresses.  SMBIOS 3.x allows for 64-bit addresses.  So to
>>>>>> fix this U-Boot needs support for SMBIOS 3.x.
>>>>>
>>>>> OK, thanks.  And for clarity / repeating my confusion, at least right
>>>>> now we also set the major/minor in the struct to 3.0.
>>>>>
>>>>>> Personally I don't see why we'd need SMBIOS support on non-x86
>>>>>> platforms, which is why implementing this isn't a high priority for
>>>>>> me.  I simply disabled SMBIOS support for M1 for now.
>>>>>
>>>>> This I think in turn (based on Heinrich's emails in v2 of this patch)
>>>>> EFI_LOADER wants to pass SMBIOS (probably 3) information along so that
>>>>> human user facing tools can see the kind of info that table provides.
>>>>>
>>>>
>>>> If you have to manage a fleet of devices, be it Apple laptops, small
>>>> servers or IoT devices, you want to be able to retrieve information
>>>> about these devices like installed firmware, serial numbers, etc. This
>>>> information should be presented by our SMBIOS implementation.
>>>>
>>>> Other EFI architectures (ARM and RISC-V) target the same markets as x86.
>>>> The customers expect that they can use the same tools irrespective of
>>>> architecture.
>>>
>>> Ah, we do have serial# being passed along that way (as well as other
>>> methods which is why I didn't think about them for SMBIOS). But this
>>> also doesn't answer my bigger concern which is that we're setting our
>>> version major to 3, our minor to 0 and then filling in a struct that's
>>> not the "smbios3" one that Simon's patch from another thread added. Is
>>> what we're filling out today semantically valid? I'm hoping someone who
>>> has already read over the spec / is familiar and I don't need to go do
>>> that right now.
>>>
>>
>> First of all there is a field "Anchor String". For a 32bit structure it
>> contains the value '_SM_', for a 64bit structure it contains the value
>> '_SM3_'. The different EFI GUIDs relate to these two different
>> structures. In our mails we simply referred to them as SMBIOS2 and
>> SMBIOS3 structures.
>>
>> Next there are the fields 'SMBIOS Major Version' and 'SMBIOS Minor
>> Version'. These should refer to the standard version 3.7 if U-Boot
>> adheres to the current version.
>>
>> As RISC-V was only fully added in SMBIOS version 3.4 we should not use
>> any older version of the specification.
>>
>> See
>> https://www.dmtf.org/content/dmtf-releases-smbios-37
>
> That's helpful.  Can we use an SMBIOS2 structure with 'SMBIOS Major
> Version' = 3 and be valid?
>

The SMBIOS specification 3.7 says:

"If an implementation provides both a 32-bit and a 64-bit entry point,
they must both report the same SMBIOS major.minor specification version"

This implies that SMBIOS Major Version = 3 is valid both in the 32- and
in the 64-bit structure.

Best regards

Heinrich