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 <tr...@konsulko.com>
On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote:
From: Simon Glass <s...@chromium.org>
Date: Mon, 23 Oct 2023 00:04:14 -0700
Hi Caleb,
On Sat, 21 Oct 2023 at 01:43, Caleb Connolly <caleb.conno...@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.
Best regards
Heinrich
