[RFC PATCH 0/1] Add boot hartid to a Device tree

[Chang, Abner (HPS SW/FW Technologist)]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: Tuesday, February 25, 2020 4:48 PM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com>
> Cc: Atish Patra <atishp at atishpatra.org>; Heinrich Schuchardt
> <xypron.glpk at gmx.de>; Atish Patra <atish.patra at wdc.com>; U-Boot Mailing
> List <u-boot at lists.denx.de>; Alexander Graf <agraf at csgraf.de>; Anup Patel
> <anup.patel at wdc.com>; Bin Meng <bmeng.cn at gmail.com>; Joe
> Hershberger <joe.hershberger at ni.com>; Loic Pallardy
> <loic.pallardy at st.com>; Lukas Auer <lukas.auer at aisec.fraunhofer.de>;
> Marek Behún <marek.behun at nic.cz>; Marek Vasut
> <marek.vasut at gmail.com>; Patrick Delaunay <patrick.delaunay at st.com>;
> Peng Fan <peng.fan at nxp.com>; Philippe Reynes
> <philippe.reynes at softathome.com>; Simon Glass <sjg at chromium.org>;
> Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>; Stefano Babic
> <sbabic at denx.de>; Thierry Reding <treding at nvidia.com>; Tom Rini
> <trini at konsulko.com>; leif at nuviainc.com; Schaefer, Daniel (DualStudy)
> <daniel.schaefer at 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.chang at hpe.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Atish Patra [mailto:atishp at atishpatra.org]
> 
> <snip header soup>
> 
> > >
> > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel
> > > <ard.biesheuvel at linaro.org> wrote:
> > > >
> > > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt
> > > > <xypron.glpk at 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