RE: [RFC PATCH 0/1] Add boot hartid to a Device tree
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, February 25, 2020 4:48 PM > To: Chang, Abner (HPS SW/FW Technologist) > Cc: Atish Patra ; Heinrich Schuchardt > ; Atish Patra ; U-Boot Mailing > List ; Alexander Graf ; Anup Patel > ; Bin Meng ; Joe > Hershberger ; Loic Pallardy > ; Lukas Auer ; > Marek Behún ; Marek Vasut > ; Patrick Delaunay ; > Peng Fan ; Philippe Reynes > ; Simon Glass ; > Simon Goldschmidt ; Stefano Babic > ; Thierry Reding ; Tom Rini > ; l...@nuviainc.com; Schaefer, Daniel (DualStudy) > > Subject: Re: [RFC PATCH 0/1] Add boot hartid to a Device tree > > On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist) > wrote: > > > > > > > > > -Original Message- > > > From: Atish Patra [mailto:ati...@atishpatra.org] > > > > > > > > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel > > > wrote: > > > > > > > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt > > > > > > > wrote: > > > > > > > > > > On 2/24/20 11:19 PM, Atish Patra wrote: > > > > > > The RISC-V booting protocol requires the hart id to be present in > "a0" > > > > > > register. This is not a problem for bootm/booti commands as > > > > > > they directly jump to Linux kernel. However, bootefi jumps to > > > > > > a EFI boot stub code in Linux kernel which acts a loader and > > > > > > jumps to real Linux after terminating the boot services. This > > > > > > boot stub code has to be aware of the boot hart id so that it > > > > > > can set it in "a0" before jumping to Linux kernel. Currently, > > > > > > UEFI protocol doesn't have any mechanism to pass the boot hart > > > > > > id to an EFI executable. We should keep it this way as this is > > > > > > a RISC-V specific requirement rather than a UEFI requirement. > > > > > > Out of the all > > > possible options, device tree seemed to be the best choice to do this job. > > > > > > The detailed discussion can be found in the following thread. > > > > > > > > > > > > INVALID URI REMOVED > > > > > > > > > > abs.org_patch_1233664_=DwIBaQ=C5b8zRQO1miGmBeVZ2LFWg=_S > > > N6FZB > > > > > > > > > > N4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=J8GY_HS3fV_cJH9duXP739y > > > 0hDK > > > > > > 3qfHGNx2Dpcf-UBY=iVpRlpTOME_A- > > > O5STNbXXawkW24gxy2yi56Q8AtZ2bI= > > > > > > > > > > The above mentioned patch is obsoleted by the new suggestion. > > > > > > > > > > > Thanks for pointing that out to avoid confusion. > > > > > > > > > > > > > > > This patch updates the device tree in arch_fixup_fdt() which > > > > > > is common for all booting commands. As a result, the DT > > > > > > modification doesn't require any efi related arch specific > > > > > > functions and all DT related modifications are contained at > > > > > > one place. However, the hart id node will be available for > > > > > > Linux even if the kernel is booted using > > > bootm command. > > > > > > > > > > > > If that is not acceptable, we can always move the code to an > > > > > > efi specific function. > > > > > > > > > > Does a related Linux patch already exist? > > > > > > Yes. But in my local tree ;). It will be included in RISC-V EFI stub > > > support series which I am planning to post in a couple of days. > > > > > > > > How about EDK2? > > > > > > > > > > > > > RISC-V is not supported at all yet in EDK2. > > > > > > > > > > The EDK2 patches are out there and reviewed. I guess it will be > > > available in mainline EDK2 pretty soon. > > Yes, currently we are working on edk2 CI testing for RISCV64 arch. We > hope edk2 RISC-V port could be in mainstream in Mar. > > > > Excellent! Is this core support? Or do you have a platform implemented as > well that can be upstreamed? Yes we do have platform implementations to be upstreamed, below is the latest status of RISC-V edk2 port. We will have to update status later because we just merged OpenSBI tag 0.6 to edk2 RISC-V. https://github.com/riscv/riscv-uefi-edk2-docs > > > > Abner agreed that similar patch can be added to EDK2 as well in the > > > previous thread. > > Yes, this will be another TODO for edk2 to add similar DT changes if we > want to boot system from edk2 firmware to EFI Stub and Linux kernel. We do > not have that so far. > > > > > > > > > > I guess boot loaders like GRUB would not have to care about the > > > > > extra property? > > > > > > > > > > > > > Yes, that is basically the point. > > > > > > > > > > > > -- > > > Regards, > > > Atish
RE: [RFC PATCH 0/1] Add boot hartid to a Device tree
> -Original Message- > From: Atish Patra [mailto:ati...@atishpatra.org] > Sent: Tuesday, February 25, 2020 7:52 AM > To: Ard Biesheuvel > Cc: Heinrich Schuchardt ; Atish Patra > ; U-Boot Mailing List ; > Alexander Graf ; Anup Patel ; Bin > Meng ; Joe Hershberger > ; Loic Pallardy ; Lukas Auer > ; Marek Behún ; > Marek Vasut ; Patrick Delaunay > ; Peng Fan ; Philippe > Reynes ; Simon Glass > ; Simon Goldschmidt > ; Stefano Babic ; > Thierry Reding ; Tom Rini ; > l...@nuviainc.com; Chang, Abner (HPS SW/FW Technologist) > ; Schaefer, Daniel (DualStudy) > > Subject: Re: [RFC PATCH 0/1] Add boot hartid to a Device tree > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel > wrote: > > > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt > wrote: > > > > > > On 2/24/20 11:19 PM, Atish Patra wrote: > > > > The RISC-V booting protocol requires the hart id to be present in "a0" > > > > register. This is not a problem for bootm/booti commands as they > > > > directly jump to Linux kernel. However, bootefi jumps to a EFI > > > > boot stub code in Linux kernel which acts a loader and jumps to > > > > real Linux after terminating the boot services. This boot stub > > > > code has to be aware of the boot hart id so that it can set it in > > > > "a0" before jumping to Linux kernel. Currently, UEFI protocol > > > > doesn't have any mechanism to pass the boot hart id to an EFI > > > > executable. We should keep it this way as this is a RISC-V > > > > specific requirement rather than a UEFI requirement. Out of the all > possible options, device tree seemed to be the best choice to do this job. > > > > The detailed discussion can be found in the following thread. > > > > > > > > INVALID URI REMOVED > > > > > abs.org_patch_1233664_=DwIBaQ=C5b8zRQO1miGmBeVZ2LFWg=_S > N6FZB > > > > > N4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=J8GY_HS3fV_cJH9duXP739y > 0hDK > > > > 3qfHGNx2Dpcf-UBY=iVpRlpTOME_A- > O5STNbXXawkW24gxy2yi56Q8AtZ2bI= > > > > > > The above mentioned patch is obsoleted by the new suggestion. > > > > > Thanks for pointing that out to avoid confusion. > > > > > > > > > This patch updates the device tree in arch_fixup_fdt() which is > > > > common for all booting commands. As a result, the DT modification > > > > doesn't require any efi related arch specific functions and all DT > > > > related modifications are contained at one place. However, the > > > > hart id node will be available for Linux even if the kernel is booted > > > > using > bootm command. > > > > > > > > If that is not acceptable, we can always move the code to an efi > > > > specific function. > > > > > > Does a related Linux patch already exist? > > Yes. But in my local tree ;). It will be included in RISC-V EFI stub support > series > which I am planning to post in a couple of days. > > > > How about EDK2? > > > > > > > RISC-V is not supported at all yet in EDK2. > > > > The EDK2 patches are out there and reviewed. I guess it will be available in > mainline EDK2 pretty soon. Yes, currently we are working on edk2 CI testing for RISCV64 arch. We hope edk2 RISC-V port could be in mainstream in Mar. > Abner agreed that similar patch can be added to EDK2 as well in the previous > thread. Yes, this will be another TODO for edk2 to add similar DT changes if we want to boot system from edk2 firmware to EFI Stub and Linux kernel. We do not have that so far. > > > > I guess boot loaders like GRUB would not have to care about the > > > extra property? > > > > > > > Yes, that is basically the point. > > > > -- > Regards, > Atish
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Atish Patra [mailto:ati...@atishpatra.org] > Sent: Friday, February 14, 2020 7:57 AM > To: Ard Biesheuvel > Cc: Chang, Abner (HPS SW/FW Technologist) ; > Heinrich Schuchardt ; Alexander Graf > ; U-Boot Mailing List ; Atish Patra > ; l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > On Thu, Feb 13, 2020 at 2:11 PM Ard Biesheuvel > wrote: > > > > On Thu, 13 Feb 2020 at 19:59, Atish Patra wrote: > > > > > > On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel > > > wrote: > > > > > > > > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW > > > > Technologist) wrote: > > > > > > > > > > > > > > > > > > > > > -----Original Message- > > > > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > > > > > > Sent: Wednesday, February 12, 2020 2:26 AM > > > > > > To: Chang, Abner (HPS SW/FW Technologist) > > > > > > ; Atish Patra ; > > > > > > Ard Biesheuvel > > > > > > Cc: Alexander Graf ; U-Boot Mailing List > > > > > b...@lists.denx.de>; Atish Patra ; > > > > > > l...@nuviainc.com > > > > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific > > > > > > UEFI setup > > > > > > > > > > > > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > > > > > > > > > > > > > > > > >> -Original Message- > > > > > > >> From: Atish Patra [mailto:ati...@atishpatra.org] > > > > > > >> Sent: Friday, February 7, 2020 6:56 AM > > > > > > >> To: Ard Biesheuvel ; Chang, > > > > > > >> Abner (HPS SW/FW > > > > > > >> Technologist) > > > > > > >> Cc: Alexander Graf ; Heinrich Schuchardt > > > > > > >> ; U-Boot Mailing List > > > > > > >> ; Atish Patra ; > > > > > > >> l...@nuviainc.com > > > > > > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture > > > > > > >> specific UEFI setup > > > > > > >> > > > > > > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > > > > > > >> > > > > > > >> wrote: > > > > > > >>> > > > > > > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra > wrote: > > > > > > >>>> > > > > > > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > > > > > > >>>> > > > > > > wrote: > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> On 06.02.20 19:28, Atish Patra wrote: > > > > > > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > > > > > > >>>>>> wrote: > > > > > > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > > > > > > >> wrote: > > > > > > >>>>>>>> RISC-V booting currently is based on a per boot stage > > > > > > >>>>>>>> lottery to determine the active CPU. The Hart State > > > > > > >>>>>>>> Management (HSM) SBI extension replaces this lottery > > > > > > >>>>>>>> by using a dedicated primary > > > > > > >> CPU. > > > > > > >>>>>>>> > > > > > > >>>>>>>> Cf. Hart State Management Extension, Extension ID: > > > > > > >>>>>>>> 0x48534D > > > > > > >>>>>>>> (HSM) > > > > > > >>>>>>>> https://github.com/riscv/riscv-sbi-doc/blob/master/ri > > > > > > >>>>>>>> scv-sbi.a > > > > > > >>>>>>>> doc > > > > > > >>>>>>>> > > > > > > >>>>>>>> In this scenario the id of the active hart has to be > > > > > > >>>>>>>> passed from boot stage to boot stage. Using a UEF
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -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) > Cc: Alexander Graf ; Atish Patra ; > Heinrich Schuchardt ; U-Boot Mailing List b...@lists.denx.de>; Atish Patra ; > 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) > 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) > > > Cc: Alexander Graf ; Atish Patra > > > ; Heinrich Schuchardt ; > > > U-Boot Mailing List ; Atish Patra > > > ; 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) > > > 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) > > > > > > Cc: Atish Patra ; Ard Biesheuvel > > > > > ; Heinrich Schuchardt > > > > > ; U-Boot Mailing List > > > > > ; Atish Patra ; > > > > > 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) > > > > > : > > > > > > > > > > > > ... > > > > > 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 reall
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Alexander Graf [mailto:ag...@csgraf.de] > Sent: Friday, February 14, 2020 4:07 PM > To: Chang, Abner (HPS SW/FW Technologist) > Cc: Atish Patra ; Ard Biesheuvel > ; Heinrich Schuchardt ; > U-Boot Mailing List ; Atish Patra > ; 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) > : > > > > > > > >> -Original Message- > >> From: Atish Patra [mailto:ati...@atishpatra.org] > >> Sent: Friday, February 14, 2020 7:57 AM > >> To: Ard Biesheuvel > >> Cc: Chang, Abner (HPS SW/FW Technologist) ; > >> Heinrich Schuchardt ; Alexander Graf > >> ; U-Boot Mailing List ; Atish > Patra > >> ; l...@nuviainc.com > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > >> > >>> On Thu, Feb 13, 2020 at 2:11 PM Ard Biesheuvel > > >>> wrote: > >>> > >>> On Thu, 13 Feb 2020 at 19:59, Atish Patra wrote: > >>>> > >>>> On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel > >>>> wrote: > >>>>> > >>>>> On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW > >>>>> Technologist) wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -Original Message- > >>>>>>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > >>>>>>> Sent: Wednesday, February 12, 2020 2:26 AM > >>>>>>> To: Chang, Abner (HPS SW/FW Technologist) > >>>>>>> ; Atish Patra ; > >>>>>>> Ard Biesheuvel > >>>>>>> Cc: Alexander Graf ; U-Boot Mailing List >>>>>>> b...@lists.denx.de>; Atish Patra ; > >>>>>>> l...@nuviainc.com > >>>>>>> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific > >>>>>>> UEFI setup > >>>>>>> > >>>>>>> On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> -Original Message- > >>>>>>>>> From: Atish Patra [mailto:ati...@atishpatra.org] > >>>>>>>>> Sent: Friday, February 7, 2020 6:56 AM > >>>>>>>>> To: Ard Biesheuvel ; Chang, > >>>>>>>>> Abner (HPS SW/FW > >>>>>>>>> Technologist) > >>>>>>>>> Cc: Alexander Graf ; Heinrich Schuchardt > >>>>>>>>> ; U-Boot Mailing List > >>>>>>>>> ; Atish Patra ; > >>>>>>>>> l...@nuviainc.com > >>>>>>>>> Subject: Re: [PATCH v2 1/1] efi_loader: architecture > >>>>>>>>> specific UEFI setup > >>>>>>>>> > >>>>>>>>> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > >>>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> On Thu, 6 Feb 2020 at 21:06, Atish Patra > >> wrote: > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > >>>>>>>>>>> > >>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 06.02.20 19:28, Atish Patra wrote: > >>>>>>>>>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > >>>>>>>>> wrote: > >>>>>>>>>>>>>>> RISC-V booting currently is based on a per boot stage > >>>>>>>>>>>>>>> lottery to determine the active CPU. The Hart State > >>>>>>>>>>>>>>> Management (HSM) SBI extension replaces this lottery > >>>>>>>>>>>>>>> by using a dedicated primary > >>>>>>>>
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -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) > Cc: Alexander Graf ; Atish Patra ; > Heinrich Schuchardt ; U-Boot Mailing List b...@lists.denx.de>; Atish Patra ; > 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) > 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) > > > Cc: Atish Patra ; Ard Biesheuvel > > > ; Heinrich Schuchardt > > > ; U-Boot Mailing List ; > > > Atish Patra ; 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) > > > : > > > > > > ... > > > 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?
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > Sent: Wednesday, February 12, 2020 2:26 AM > To: Chang, Abner (HPS SW/FW Technologist) ; > Atish Patra ; Ard Biesheuvel > > Cc: Alexander Graf ; U-Boot Mailing List b...@lists.denx.de>; Atish Patra ; > l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > >> -Original Message- > >> From: Atish Patra [mailto:ati...@atishpatra.org] > >> Sent: Friday, February 7, 2020 6:56 AM > >> To: Ard Biesheuvel ; Chang, Abner (HPS > >> SW/FW > >> Technologist) > >> Cc: Alexander Graf ; Heinrich Schuchardt > >> ; U-Boot Mailing List ; > >> Atish Patra ; l...@nuviainc.com > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > >> setup > >> > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > >> > >> wrote: > >>> > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra wrote: > >>>> > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > wrote: > >>>>> > >>>>> > >>>>> On 06.02.20 19:28, Atish Patra wrote: > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > >>>>>> wrote: > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > >> wrote: > >>>>>>>> RISC-V booting currently is based on a per boot stage lottery > >>>>>>>> to determine the active CPU. The Hart State Management (HSM) > >>>>>>>> SBI extension replaces this lottery by using a dedicated > >>>>>>>> primary > >> CPU. > >>>>>>>> > >>>>>>>> Cf. Hart State Management Extension, Extension ID: 0x48534D > >>>>>>>> (HSM) > >>>>>>>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a > >>>>>>>> doc > >>>>>>>> > >>>>>>>> In this scenario the id of the active hart has to be passed > >>>>>>>> from boot stage to boot stage. Using a UEFI variable would > >>>>>>>> provide > >> an easy implementation. > >>>>>>>> > >>>>>>>> This patch provides a weak function that is called at the end > >>>>>>>> of the setup of U-Boot's UEFI sub-system. By overriding this > >>>>>>>> function architecture specific UEFI variables or configuration > >>>>>>>> tables > >> can be created. > >>>>>>>> > >>>>>>>> Signed-off-by: Heinrich Schuchardt > >>>>>>>> Reviewed-by: Atish Patra > >>>>>>> OK, so I have a couple of questions: > >>>>>>> > >>>>>>> - does RISC-V use device tree? if so, why are you not passing > >>>>>>> the active hart via a property in the /chosen node? > >>>>>> Yes. RISC-V uses device tree. Technically, we can pass the active > >>>>>> hart by a DT property but that means we have to modify the DT in > >>>>>> OpenSBI (RISC-V specific run time service provider). > >>>>>> We have been trying to avoid that if possible so that DT is not > >>>>>> bounced around. This also limits U-Boot to have its own device > >>>>>> tree. > >>>>> > >>>>> > >>>>> I don't understand how this is different from the UEFI variable > >>>>> scheme proposed here? If you want to create an SBI interface to > >>>>> propagate the active HART that U-Boot then uses to populate the > >>>>> /chosen property, that's probably fine as well. > >>>>> > >>>> > >>>> We don't want to create SBI interface to pass this information. > >>>> > >>>>> We already have hooks that allow you to modify the DT right before > >>>>> it gets delivered to the payload. Just add it there? > >>>>> > >>>> > >>>> Hmm. I guess it is true if the DT is loaded from MMC or network as well. > >>>> How about EDK2 ? If we go DT route, it also has to modify the DT to > >>>>
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> -Original Message- > From: Atish Patra [mailto:ati...@atishpatra.org] > Sent: Friday, February 7, 2020 6:56 AM > To: Ard Biesheuvel ; Chang, Abner (HPS SW/FW > Technologist) > Cc: Alexander Graf ; Heinrich Schuchardt > ; U-Boot Mailing List ; Atish > Patra ; l...@nuviainc.com > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > wrote: > > > > On Thu, 6 Feb 2020 at 21:06, Atish Patra wrote: > > > > > > On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf wrote: > > > > > > > > > > > > On 06.02.20 19:28, Atish Patra wrote: > > > > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > > > > > wrote: > > > > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > wrote: > > > > >>> RISC-V booting currently is based on a per boot stage lottery > > > > >>> to determine the active CPU. The Hart State Management (HSM) > > > > >>> SBI extension replaces this lottery by using a dedicated primary > CPU. > > > > >>> > > > > >>> Cf. Hart State Management Extension, Extension ID: 0x48534D > > > > >>> (HSM) > > > > >>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a > > > > >>> doc > > > > >>> > > > > >>> In this scenario the id of the active hart has to be passed > > > > >>> from boot stage to boot stage. Using a UEFI variable would provide > an easy implementation. > > > > >>> > > > > >>> This patch provides a weak function that is called at the end > > > > >>> of the setup of U-Boot's UEFI sub-system. By overriding this > > > > >>> function architecture specific UEFI variables or configuration > > > > >>> tables > can be created. > > > > >>> > > > > >>> Signed-off-by: Heinrich Schuchardt > > > > >>> Reviewed-by: Atish Patra > > > > >> OK, so I have a couple of questions: > > > > >> > > > > >> - does RISC-V use device tree? if so, why are you not passing > > > > >> the active hart via a property in the /chosen node? > > > > > Yes. RISC-V uses device tree. Technically, we can pass the > > > > > active hart by a DT property but that means we have to modify > > > > > the DT in OpenSBI (RISC-V specific run time service provider). > > > > > We have been trying to avoid that if possible so that DT is not > > > > > bounced around. This also limits U-Boot to have its own device > > > > > tree. > > > > > > > > > > > > I don't understand how this is different from the UEFI variable > > > > scheme proposed here? If you want to create an SBI interface to > > > > propagate the active HART that U-Boot then uses to populate the > > > > /chosen property, that's probably fine as well. > > > > > > > > > > We don't want to create SBI interface to pass this information. > > > > > > > We already have hooks that allow you to modify the DT right before > > > > it gets delivered to the payload. Just add it there? > > > > > > > > > > Hmm. I guess it is true if the DT is loaded from MMC or network as well. > > > How about EDK2 ? If we go DT route, it also has to modify the DT to > > > pass the boot hart. > > > > > > As it requires DT modification in multiple projects, why not use efi > > > configuration tables as suggested by Ard ? > > > > > > > Configuration tables are preferred over variables, but putting it in > > the DT makes even more sense, since in that case, nothing that runs in > > the UEFI context has to care about any of this. > > > > > > > > > > > > > > > > >> I'd assume the EFI stub would not care at all about this > > > > >> information, and it would give you a Linux/RISC-V specific way > > > > >> to convey this information that is independent of EFI. > > > > > Yes. EFI stub doesn't care about this information. However, it > > > > > needs to save the information somewhere so that it can pass to > > > > > the real kernel after exiting boot time services. > > > > > > > > > > > > DT sounds like a pretty natural choice for that to me :). > > > > > > > > Indeed. DT has a /chosen node that is set aside for this purpose. It > > does depend on how early you need the value (i.e., before or after you > > can run C code), but since you are passing the DT address to the core > > kernel, it makes way more sense to drop any additional information > > that you need to pass in there. > > We don't need boot hart id until real kernel boots and parse DT. So that > should be okay. > I just looked at the efi stub code once more and realized that it is already > parsing the DT to setup uefi memory maps from /chosen node. Adding boot > hart id to the chosen node does seem much cleaner to me :). Thanks for all > the explanations. > > I have not looked at EDK2 code. But I am assuming modifying the DT just > before jumping to the payload won't be too hard for EDK2 as well. We don’t use DT in edk2 RISC-V port and we pass boot HART ID in SMBIOS type 44h as it is spec out in below link, https://github.com/riscv/riscv-smbios/blob/master/RISCV-SMBIOS.md Abner > > Added Leif and Abner for the opinion. > > > > -- > Regards, > Atish
