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

[Chang, Abner (HPS SW/FW Technologist)]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: Friday, February 14, 2020 7:33 PM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com>
> Cc: Alexander Graf <agraf at csgraf.de>; Atish Patra <atishp at atishpatra.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
> 
> 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.
Hart ID is just one of the information in type 44 which is the same as the processor information provided in type 4.

> 
> > >
> > > 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.
As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good example, the Host interface used to talk to BMC and Redfish service in pre-OS environment (also runtime OS).
For OS boot, maybe OS (like Windows) still retrieves information from it before ACPI enable.

I have no preference of using which way to get boot hard ID for the boot process, either to get it from DT, SMBIOS or  ACPI seems to me the same... just the information is provided over there

> 
> 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.
Security consideration?