[RFC PATCH 0/1] Add boot hartid to a Device tree

[Atish Patra]

On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
>
> On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt <xypron.glpk at gmx.de> 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.
> > >
> > > https://patchwork.ozlabs.org/patch/1233664/
> >
> > 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.
Abner agreed that similar patch can be added to EDK2 as well in the
previous thread.

> > I guess boot loaders like GRUB would not have to care about the extra
> > property?
> >
>
> Yes, that is basically the point.



-- 
Regards,
Atish