On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt <[email protected]> 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.
