[PATCH 0/7] Add support for CONFIG_API on RISC-V

[Mitchell Horne]

On Sat, Apr 25, 2020 at 4:31 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 4/24/20 10:52 PM, Tom Rini wrote:
> > On Fri, Apr 24, 2020 at 05:46:43PM -0300, Mitchell Horne wrote:
> >> On Fri, Apr 24, 2020 at 1:52 PM Tom Rini <trini at konsulko.com> wrote:
> >>>
> >>> On Mon, Apr 20, 2020 at 06:34:11PM -0400, mhorne at FreeBSD.org wrote:
> >>>
> >>>> From: Mitchell Horne <mhorne at FreeBSD.org>
> >>>>
> >>>> FreeBSD makes use of u-boot's CONFIG_API to provide a version of its
> >>>> standard bootloader for embedded architectures. This series adds the
> >>>> necessary support for the RISC-V architecture, along with some small
> >>>> fixes to the API demo program for 64-bit systems.
> >>>
> >>> Adding in the RISC-V maintainer and EFI maintainer.  I thought the
> >>> intention was for OSes to use the EFI loader here, even for "embedded" ?
> >>> Thanks!
> >>>
> >>
> >> Hi Tom,
> >>
> >> You are right, EFI is preferred. FreeBSD's loader has two
> >> implementations on arm: one that is an EFI application, and one based
> >> on this u-boot API (known as "ubldr"). ubldr precedes the EFI
> >> implementation by a few years.
> >>
> >> For RISC-V my intention is also to implement both versions, and ubldr
> >> was simpler on FreeBSD's side, so I chose to do that first. Do you
> >> think this series is still worth pursuing if u-boot is going the way
> >> of EFI?
> >
> > In my mind at least, the EFI interface is preferred as it's a defined
> > external standard interface.  If the architecture maintainers want to
> > support both the U-Boot API and EFI on RISC-V, I don't object.  But one
> > of the intentions is to have there be less work for OS folks to have to
> > do for example.  So that you found this a good first step for your use
> > case means perhaps we need to continue to have the U-Boot API method be
> > around (not that we had planned any sort of removal).  Thanks!
> >
>
> Hello Mitchell,
>
> let me just give me an overview of where we currently are with UEFI
> support for RISC-V:
>
> U-Boot supports UEFI to the point that we can start GRUB as EFI binary.
>
> In Linux the UEFI support for RISC-V is being set up, cf.
> https://lkml.org/lkml/2020/4/20/1800
>
> In EDK2 RISC-V support is under active development
> (https://edk2.groups.io/g/devel/search?q=RISC-V). In EDK2's staging
> repository (https://github.com/tianocore/edk2-staging.git) you can find
> a branch RISC-V-V2-CI-log-all-archs.
>
> One challenge is the transfer of the HART id which is used for booting.
> In U-Boot this has been addressed by the patch 5370478d1c7a ("riscv: Add
> boot hartid to device tree").

Hi, just so this thread isn't left dangling, I eventually went the EFI
route. I found this to be easier because the hart-id fixups aren't
applied when executing plain binaries via the "go" command. I don't
think this patchset will be needed. Thanks!

Mitchell

>
> @Atish:
> Is there a corresponding patch for EDK2?
>
> Best regards
>
> Heinrich