> -----Original Message----- > From: Ard Biesheuvel [mailto:[email protected]] > Sent: Tuesday, February 25, 2020 4:48 PM > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]> > Cc: Atish Patra <[email protected]>; Heinrich Schuchardt > <[email protected]>; Atish Patra <[email protected]>; U-Boot Mailing > List <[email protected]>; Alexander Graf <[email protected]>; Anup Patel > <[email protected]>; Bin Meng <[email protected]>; Joe > Hershberger <[email protected]>; Loic Pallardy > <[email protected]>; Lukas Auer <[email protected]>; > Marek Behún <[email protected]>; Marek Vasut > <[email protected]>; Patrick Delaunay <[email protected]>; > Peng Fan <[email protected]>; Philippe Reynes > <[email protected]>; Simon Glass <[email protected]>; > Simon Goldschmidt <[email protected]>; Stefano Babic > <[email protected]>; Thierry Reding <[email protected]>; Tom Rini > <[email protected]>; [email protected]; Schaefer, Daniel (DualStudy) > <[email protected]> > Subject: Re: [RFC PATCH 0/1] Add boot hartid to a Device tree > > On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist) > <[email protected]> wrote: > > > > > > > > > -----Original Message----- > > > From: Atish Patra [mailto:[email protected]] > > <snip header soup> > > > > > > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel > > > <[email protected]> wrote: > > > > > > > > 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. > > > > > > > > > > > > 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? Yes we do have platform implementations to be upstreamed, below is the latest status of RISC-V edk2 port. We will have to update status later because we just merged OpenSBI tag 0.6 to edk2 RISC-V. https://github.com/riscv/riscv-uefi-edk2-docs
> > > > 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
