[PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Atish Patra]

On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>
> On Thu, 6 Feb 2020 at 21:06, Atish Patra <atishp at atishpatra.org> wrote:
> >
> > On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf <agraf at csgraf.de> wrote:
> > >
> > >
> > > On 06.02.20 19:28, Atish Patra wrote:
> > > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > > > <ard.biesheuvel at linaro.org> wrote:
> > > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt <xypron.glpk at 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.glpk at gmx.de>
> > > >>> Reviewed-by: Atish Patra <atish.patra at 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.

Added Leif and Abner for the opinion.



--
Regards,
Atish