On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> wrote: > > > > > -----Original Message----- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: Friday, February 14, 2020 7:33 PM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> > > Cc: Alexander Graf <ag...@csgraf.de>; Atish Patra <ati...@atishpatra.org>; > > Heinrich Schuchardt <xypron.g...@gmx.de>; U-Boot Mailing List <u- > > b...@lists.denx.de>; Atish Patra <atish.pa...@wdc.com>; > > l...@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.ch...@hpe.com> wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Alexander Graf [mailto:ag...@csgraf.de] > > > > Sent: Friday, February 14, 2020 4:07 PM > > > > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> > > > > Cc: Atish Patra <ati...@atishpatra.org>; Ard Biesheuvel > > > > <ard.biesheu...@linaro.org>; Heinrich Schuchardt > > > > <xypron.g...@gmx.de>; U-Boot Mailing List <u-boot@lists.denx.de>; > > > > Atish Patra <atish.pa...@wdc.com>; l...@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.ch...@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. >
Fine. But that doesn't mean we should be parsing SMBIOS tables in the Linux startup code. > > > > > > > > > > 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? What security considerations did you have in mind?
