On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> wrote: > > > > > -----Original Message----- > > From: Atish Patra [mailto:ati...@atishpatra.org]
<snip header soup> > > > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel > > <ard.biesheu...@linaro.org> wrote: > > > > > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt <xypron.g...@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. > > > > > > > > > > INVALID URI REMOVED > > > > > > > abs.org_patch_1233664_&d=DwIBaQ&c=C5b8zRQO1miGmBeVZ2LFWg&r=_S > > N6FZB > > > > > > > N4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=J8GY_HS3fV_cJH9duXP739y > > 0hDK > > > > > 3qfHGNx2Dpcf-UBY&s=iVpRlpTOME_A- > > O5STNbXXawkW24gxy2yi56Q8AtZ2bI&e= > > > > > > > > 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. > Yes, currently we are working on edk2 CI testing for RISCV64 arch. We hope > edk2 RISC-V port could be in mainstream in Mar. > Excellent! Is this core support? Or do you have a platform implemented as well that can be upstreamed? > > Abner agreed that similar patch can be added to EDK2 as well in the previous > > thread. > Yes, this will be another TODO for edk2 to add similar DT changes if we want > to boot system from edk2 firmware to EFI Stub and Linux kernel. We do not > have that so far. > > > > > > > I guess boot loaders like GRUB would not have to care about the > > > > extra property? > > > > > > > > > > Yes, that is basically the point. > > > > > > > > -- > > Regards, > > Atish
