| Message ID | 20200420223418.117186-1-mhorne@FreeBSD.org |
|---|---|
| Headers | show |
| Series | Add support for CONFIG_API on RISC-V | expand |
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!
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? Cheers, Mitchell > -- > Tom
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!
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"). @Atish: Is there a corresponding patch for EDK2? Best regards Heinrich
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
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. Mitchell Horne (7): examples: generate demo.bin examples: rename __start to _start on MIPS examples: add a linker script for the API demo examples: fix the type of search_hint examples: fix incompatible type casts riscv: add CONFIG_API support api: enumerate virtio-blk devices api/Makefile | 1 + api/api_platform-riscv.c | 33 +++++++++++++++++++++++++++++++++ api/api_storage.c | 14 +++++++++++++- examples/api/Makefile | 10 +++++++--- examples/api/crt0.S | 25 +++++++++++++++++++++---- examples/api/demo.c | 21 +++++++++++---------- examples/api/demo.lds | 14 ++++++++++++++ examples/api/glue.c | 6 +++--- examples/api/glue.h | 2 +- include/api_public.h | 1 + 10 files changed, 105 insertions(+), 22 deletions(-) create mode 100644 api/api_platform-riscv.c create mode 100644 examples/api/demo.lds