> -----Original Message----- > From: Atish Patra [mailto:ati...@atishpatra.org] > Sent: Tuesday, February 25, 2020 7:52 AM > To: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: 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; Chang, Abner (HPS SW/FW Technologist) > <abner.ch...@hpe.com>; Schaefer, Daniel (DualStudy) > <daniel.schae...@hpe.com> > Subject: Re: [RFC PATCH 0/1] Add boot hartid to a Device tree > > 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.
> 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
