> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, February 14, 2020 8:07 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 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. Ok, this is not my familiar area. You guys are better than me.
> > > > > > > > > > > > > > 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? Hah this is my question for you. Can someone under Pre-OS environment and steal boot hard ID and do something bad? Or change it to run malicious code from another HART?