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

[Tom Rini <trini@konsulko.com>]

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@konsulko.com> wrote:
> >
> > On Mon, Apr 20, 2020 at 06:34:11PM -0400, mhorne at FreeBSD.org wrote:
> >
> > > From: Mitchell Horne <mhorne@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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200424/67c8a3bf/attachment.sig>