On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com wrote:
-----Original Message----- From: Alexander Graf [mailto:agraf@csgraf.de] Sent: Friday, February 14, 2020 4:07 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com Cc: Atish Patra atishp@atishpatra.org; Ard Biesheuvel ard.biesheuvel@linaro.org; Heinrich Schuchardt xypron.glpk@gmx.de; U-Boot Mailing List u-boot@lists.denx.de; Atish Patra Atish.Patra@wdc.com; leif@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)
...
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.