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.adoc > >>> > >>> 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 ? > > > > > >> 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 :). > > > Alex > > -- Regards, Atish