[PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist)
<abner.chang at hpe.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Alexander Graf [mailto:agraf at csgraf.de]
> > Sent: Friday, February 14, 2020 4:07 PM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com>
> > Cc: Atish Patra <atishp at atishpatra.org>; Ard Biesheuvel
> > <ard.biesheuvel at linaro.org>; Heinrich Schuchardt <xypron.glpk at gmx.de>;
> > U-Boot Mailing List <u-boot at lists.denx.de>; Atish Patra
> > <Atish.Patra at wdc.com>; leif at nuviainc.com
> > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> >
> >
> >
> > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW Technologist)
> > <abner.chang at hpe.com>:
> > >

...
> > The table  from this link https://github.com/riscv/riscv-
> > smbios/blob/master/RISCV-SMBIOS.md
> > > Offset 3 is HART ID, and offset 13h is the boolean indicates this hart is the
> > boot hart.
> > >
> > >> kernel. How difficult is to modify the DT in EDK2 ?
> > >>
> > > I never used DT before on PC/Server project. However, the DT code is over
> > there in edk2 repo which mostly used by ARM platforms. I don’t think it is
> > difficult to adopt it though.
> >
> > Yes, some arm platforms already transform the DT just fine. Let's really
> > please not use SMBIOS for anything boot or system configuration related: its
> > purpose is in general purely informational.
> As DT to embedded system, SMBIOS provides system information/configuration on most PC/Server platforms. Especially to pre-OS applications such as EFI diagnostic tool, factory/customer deployment tools, pre-OS system configuration, network boot image and EFI OS  boot loader as well. The intention of RISC-V SMBIOS is support above applications using single image for the RISC-V core variants, Non ACPI-aware OS is also part of this scope, but it is rare though.
> If you are booting to OS which is actually well understand DT then just use DT, but for PC/Server industry, SMBIOS would be still our choice before OS.
> We may have to define the corresponding syntax If DT doesn't have it for boot HART information. RISC-V System Description Task Group (f it formed) would be a good place to bring this topic.
> Maybe you can support both DT or SMBIOS to retrieve the information you need on demand...
>

SMBIOS is an informational protocol. Firmware or OS loaders should not
rely on it for low-level things like the hart id.

> >
> > So yes, unless I hear really good arguments against passing it via /chosen in
> > DT, I'd strongly prefer that mechanism. For ACPI (if it ever happens), there
> > would be a special ACPI table for it anyway.
> Yes, we do have an ECR for ACPI spec to report the RISC-V core characteristic which is similar to what we done for SMBIOS.
>

So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and
we'll always have to parse two sets of tables, just to discover the
hart id. I don't think that makes sense at all, to be honest.

SMBIOS is wonderful for the sysadmin to look at the model numbers of
the installed DIMMs etc. But for core boot stuff, we really should
avoid it.