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@konsulko.com > > On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote: >>> From: Simon Glass sjg@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@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.
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