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

Ard Biesheuvel ard.biesheuvel at linaro.org
Tue Feb 25 00:35:03 CET 2020


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.
>
> >
> > 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?
> How about EDK2?
>

RISC-V is not supported at all yet in EDK2.

> I guess boot loaders like GRUB would not have to care about the extra
> property?
>

Yes, that is basically the point.


More information about the U-Boot mailing list