> -----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) <abner.ch...@hpe.com>; > Atish Patra <ati...@atishpatra.org>; Ard Biesheuvel > <ard.biesheu...@linaro.org> > Cc: Alexander Graf <ag...@csgraf.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 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 <ard.biesheu...@linaro.org>; Chang, Abner (HPS > >> SW/FW > >> Technologist) <abner.ch...@hpe.com> > >> Cc: Alexander Graf <ag...@csgraf.de>; 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 > >> > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > >> <ard.biesheu...@linaro.org> > >> wrote: > >>> > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra <ati...@atishpatra.org> wrote: > >>>> > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf <ag...@csgraf.de> > wrote: > >>>>> > >>>>> > >>>>> On 06.02.20 19:28, Atish Patra wrote: > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > >>>>>> <ard.biesheu...@linaro.org> wrote: > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > >> <xypron.g...@gmx.de> 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 <xypron.g...@gmx.de> > >>>>>>>> Reviewed-by: Atish Patra <atish.pa...@wdc.com> > >>>>>>> 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 > > Thanks for the link. > > For 'RISC-V SMBIOS Type 44 Processor Additional Information' I find entry > 0x13h 1: This is boot hart to boot system . > > But is '44' a hexadecimal number? The document does not indicate this. Type '44' is decimal format as it mentioned in SMBIOS spec, I had typo in above which said '44h'. However, that's good to mention this in RISCV_SMBIOS.md. Thanks for the recommendation. > > Best regards > > Heinrich > > > > > Abner > > > >> > >> Added Leif and Abner for the opinion. > >> > >> > >> > >> -- > >> Regards, > >> Atish
RE: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
Chang, Abner (HPS SW/FW Technologist) Thu, 13 Feb 2020 03:38:11 -0800
- RE: [PATCH v2 1/1] efi_loader: archi... Chang, Abner (HPS SW/FW Technologist)
- Re: [PATCH v2 1/1] efi_loader: ... Atish Patra
- Re: [PATCH v2 1/1] efi_load... Ard Biesheuvel
- Re: [PATCH v2 1/1] efi_... Atish Patra
- RE: [PATCH v2 1/1] ... Chang, Abner (HPS SW/FW Technologist)
- Re: [PATCH v2 ... Alexander Graf
- RE: [PATCH... Chang, Abner (HPS SW/FW Technologist)