Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

[Adriana Nicolae <adriana@arista.com>]

On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Oct 22, 2025 at 04:45:25AM -0700, adriana wrote:
> > Some bootloaders like U-boot, particularly for the ARM architecture,
> > provide SMBIOS/DMI tables at a specific memory address. However, these
> > systems often do not boot using a full UEFI environment, which means the
> > kernel's standard EFI DMI scanner cannot find these tables.
>
> I thought u-boot is a pretty complete UEFI implementation now. If
> there's standard way for UEFI to provide this, then that's what we
> should be using. I know supporting this has been discussed in context of
> EBBR spec, but no one involved in that has been CC'ed here.

Regarding the use of UEFI, the non UEFI boot is used on Broadcom iProc which
boots initially into a Hardware Security Module which validates U-boot and then
loads it. This specific path does not utilize U-Boot's UEFI
implementation or the
standard UEFI boot services to pass tables like SMBIOS.

Because there's no UEFI configuration table available in this boot mode, we need
an alternative mechanism to pass the SMBIOS table address to the kernel. The
/chosen node seemed like the most straightforward way for the bootloader to
communicate this non-discoverable information.

I wasn't aware of the EBBR discussions covering this. I've added the
boot-architecture and arm.ebbr-discuss lists to the Cc. If there's a preferred
EBBR-compliant way to handle this for non-UEFI boots, I'm happy to adapt
the approach.

>
> > This series adds support for the kernel to find these tables by
> > reading properties from the Device Tree /chosen node. The bootloader
> > can specify the physical addresses using "linux,smbios-table" and
> > "linux,smbios3-table".
>
> /chosen node entries go in chosen.yaml schema in dtschema repository.
> But first, I need to see some agreement this is how we want to support
> this.
>
> Rob

Adriana