> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, February 25, 2020 4:48 PM > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> > Cc: Atish Patra <ati...@atishpatra.org>; Heinrich Schuchardt > <xypron.g...@gmx.de>; Atish Patra <atish.pa...@wdc.com>; U-Boot Mailing > List <u-boot@lists.denx.de>; Alexander Graf <ag...@csgraf.de>; Anup Patel > <anup.pa...@wdc.com>; Bin Meng <bmeng...@gmail.com>; Joe > Hershberger <joe.hershber...@ni.com>; Loic Pallardy > <loic.palla...@st.com>; Lukas Auer <lukas.a...@aisec.fraunhofer.de>; > Marek BehĂșn <marek.be...@nic.cz>; Marek Vasut > <marek.va...@gmail.com>; Patrick Delaunay <patrick.delau...@st.com>; > Peng Fan <peng....@nxp.com>; Philippe Reynes > <philippe.rey...@softathome.com>; Simon Glass <s...@chromium.org>; > Simon Goldschmidt <simon.k.r.goldschm...@gmail.com>; Stefano Babic > <sba...@denx.de>; Thierry Reding <tred...@nvidia.com>; Tom Rini > <tr...@konsulko.com>; l...@nuviainc.com; Schaefer, Daniel (DualStudy) > <daniel.schae...@hpe.com> > 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) > <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? 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