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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Thu, 6 Feb 2020 at 21:06, Atish Patra <atishp@atishpatra.org> wrote:
>
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf <agraf@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@linaro.org> wrote:
> > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt <xypron.glpk@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@gmx.de>
> > >>> Reviewed-by: Atish Patra <atish.patra@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.