.gitmodules | 3 + Makefile | 3 +- configure | 1 + hw/riscv/Makefile.objs | 1 + hw/riscv/boot.c | 143 ++++++++++++++++++++++++++++ hw/riscv/sifive_e.c | 17 +--- hw/riscv/sifive_u.c | 19 +--- hw/riscv/spike.c | 21 +--- hw/riscv/virt.c | 54 ++--------- include/hw/riscv/boot.h | 30 ++++++ pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes roms/Makefile | 17 ++++ roms/opensbi | 1 + 14 files changed, 216 insertions(+), 94 deletions(-) create mode 100644 hw/riscv/boot.c create mode 100644 include/hw/riscv/boot.h create mode 100644 pc-bios/opensbi-riscv32-fw_jump.elf create mode 100644 pc-bios/opensbi-riscv64-fw_jump.elf create mode 160000 roms/opensbi
This is an RFC as it will break ALL current users! See below for details. This series consolidates the current RISC-V kernel loading impelementation while also adding support for the -bios option and more advanced kernel image types. After consolidating the kernel loading we can extend the boot loader to support a -bios option. We can also extend the kernel loading options to support not just ELF files but other standard formats. Finally we can include the OpenSBI firmware by default for QEMU users. At the end of this series we are in the good place of no longer requiring users to build firmware to boot a kernel. Instead users can just run QEMu with the -kernel option and everything will work. They can also override the firmware with their own using the -bios option. Using "-bios none" will result in no firmware being loaded (as it is today). !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Unfortunately this series (patch 5 specifically) results in all current Linux boots being broken as users are already loading in their own firmware, which overlaps with the now included default. They will see this error: rom: requested regions overlap (rom phdr #0: ./images/qemuriscv64/fw_jump.elf. free=0x0000000080008090, addr=0x0000000080000000) qemu-system-riscv64: rom check and register reset failed If a current user specieifies "-bios none" their flow will continue working. A user can instead no longer load their firmware and use the default or they can load their firmware with the -bios option. At the moment the best idea I have to not break all users is to only include the default firmware if the user specifies "-bios opensbi". That is change the default to not loading the firmware. Then we can work on updating documentation and maybe in future change the default to include a firmware and anyone who doesn't want a default firmware can specify "-bios none". Any other ideas on how to not break everything? Alistair Francis (5): hw/riscv: Split out the boot functions hw/riscv: Add support for loading a firmware hw/riscv: Extend the kernel loading support roms: Add OpenSBI version 0.3 hw/riscv: Load OpenSBI as the default firmware .gitmodules | 3 + Makefile | 3 +- configure | 1 + hw/riscv/Makefile.objs | 1 + hw/riscv/boot.c | 143 ++++++++++++++++++++++++++++ hw/riscv/sifive_e.c | 17 +--- hw/riscv/sifive_u.c | 19 +--- hw/riscv/spike.c | 21 +--- hw/riscv/virt.c | 54 ++--------- include/hw/riscv/boot.h | 30 ++++++ pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes roms/Makefile | 17 ++++ roms/opensbi | 1 + 14 files changed, 216 insertions(+), 94 deletions(-) create mode 100644 hw/riscv/boot.c create mode 100644 include/hw/riscv/boot.h create mode 100644 pc-bios/opensbi-riscv32-fw_jump.elf create mode 100644 pc-bios/opensbi-riscv64-fw_jump.elf create mode 160000 roms/opensbi -- 2.22.0
On Wed, Jun 19, 2019 at 8:56 AM Alistair Francis <alistair.francis@wdc.com> wrote: > > This is an RFC as it will break ALL current users! See below for details. > > This series consolidates the current RISC-V kernel loading > impelementation while also adding support for the -bios option and more > advanced kernel image types. > > After consolidating the kernel loading we can extend the boot loader to > support a -bios option. We can also extend the kernel loading options to > support not just ELF files but other standard formats. > > Finally we can include the OpenSBI firmware by default for QEMU users. > > At the end of this series we are in the good place of no longer > requiring users to build firmware to boot a kernel. Instead users can > just run QEMu with the -kernel option and everything will work. They can This is great. I like booting kernel directly for testing without bothering the firmware stuff. > also override the firmware with their own using the -bios option. Using > "-bios none" will result in no firmware being loaded (as it is today). > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Unfortunately this series (patch 5 specifically) results in all current > Linux boots being broken as users are already loading in their own > firmware, which overlaps with the now included default. They will > see this error: > > rom: requested regions overlap (rom phdr #0: ./images/qemuriscv64/fw_jump.elf. free=0x0000000080008090, addr=0x0000000080000000) > qemu-system-riscv64: rom check and register reset failed > > If a current user specieifies "-bios none" their flow will continue > working. A user can instead no longer load their firmware and > use the default or they can load their firmware with the -bios option. > > At the moment the best idea I have to not break all users is to only > include the default firmware if the user specifies "-bios opensbi". > That is change the default to not loading the firmware. Then we can work > on updating documentation and maybe in future change the default to > include a firmware and anyone who doesn't want a default firmware can > specify "-bios none". > > Any other ideas on how to not break everything? > > > > Alistair Francis (5): > hw/riscv: Split out the boot functions > hw/riscv: Add support for loading a firmware > hw/riscv: Extend the kernel loading support > roms: Add OpenSBI version 0.3 > hw/riscv: Load OpenSBI as the default firmware > > .gitmodules | 3 + > Makefile | 3 +- > configure | 1 + > hw/riscv/Makefile.objs | 1 + > hw/riscv/boot.c | 143 ++++++++++++++++++++++++++++ > hw/riscv/sifive_e.c | 17 +--- > hw/riscv/sifive_u.c | 19 +--- > hw/riscv/spike.c | 21 +--- > hw/riscv/virt.c | 54 ++--------- > include/hw/riscv/boot.h | 30 ++++++ > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes Since we are considering adding "bios" images, I prefer to add the pure binary images instead of ELF images here. > roms/Makefile | 17 ++++ > roms/opensbi | 1 + > 14 files changed, 216 insertions(+), 94 deletions(-) > create mode 100644 hw/riscv/boot.c > create mode 100644 include/hw/riscv/boot.h > create mode 100644 pc-bios/opensbi-riscv32-fw_jump.elf > create mode 100644 pc-bios/opensbi-riscv64-fw_jump.elf > create mode 160000 roms/opensbi Regards, Bin
On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Wed, Jun 19, 2019 at 8:56 AM Alistair Francis > <alistair.francis@wdc.com> wrote: > > > > This is an RFC as it will break ALL current users! See below for details. > > > > This series consolidates the current RISC-V kernel loading > > impelementation while also adding support for the -bios option and more > > advanced kernel image types. > > > > After consolidating the kernel loading we can extend the boot loader to > > support a -bios option. We can also extend the kernel loading options to > > support not just ELF files but other standard formats. > > > > Finally we can include the OpenSBI firmware by default for QEMU users. > > > > At the end of this series we are in the good place of no longer > > requiring users to build firmware to boot a kernel. Instead users can > > just run QEMu with the -kernel option and everything will work. They can > > This is great. I like booting kernel directly for testing without > bothering the firmware stuff. That's the goal! Now we just need to not break everything. > > > also override the firmware with their own using the -bios option. Using > > "-bios none" will result in no firmware being loaded (as it is today). > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > Unfortunately this series (patch 5 specifically) results in all current > > Linux boots being broken as users are already loading in their own > > firmware, which overlaps with the now included default. They will > > see this error: > > > > rom: requested regions overlap (rom phdr #0: ./images/qemuriscv64/fw_jump.elf. free=0x0000000080008090, addr=0x0000000080000000) > > qemu-system-riscv64: rom check and register reset failed > > > > If a current user specieifies "-bios none" their flow will continue > > working. A user can instead no longer load their firmware and > > use the default or they can load their firmware with the -bios option. > > > > At the moment the best idea I have to not break all users is to only > > include the default firmware if the user specifies "-bios opensbi". > > That is change the default to not loading the firmware. Then we can work > > on updating documentation and maybe in future change the default to > > include a firmware and anyone who doesn't want a default firmware can > > specify "-bios none". > > > > Any other ideas on how to not break everything? > > > > > > > > Alistair Francis (5): > > hw/riscv: Split out the boot functions > > hw/riscv: Add support for loading a firmware > > hw/riscv: Extend the kernel loading support > > roms: Add OpenSBI version 0.3 > > hw/riscv: Load OpenSBI as the default firmware > > > > .gitmodules | 3 + > > Makefile | 3 +- > > configure | 1 + > > hw/riscv/Makefile.objs | 1 + > > hw/riscv/boot.c | 143 ++++++++++++++++++++++++++++ > > hw/riscv/sifive_e.c | 17 +--- > > hw/riscv/sifive_u.c | 19 +--- > > hw/riscv/spike.c | 21 +--- > > hw/riscv/virt.c | 54 ++--------- > > include/hw/riscv/boot.h | 30 ++++++ > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > Since we are considering adding "bios" images, I prefer to add the > pure binary images instead of ELF images here. I didn't think about that. Can we just boot them in QEMU like we do with the ELFs? Alistair > > > roms/Makefile | 17 ++++ > > roms/opensbi | 1 + > > 14 files changed, 216 insertions(+), 94 deletions(-) > > create mode 100644 hw/riscv/boot.c > > create mode 100644 include/hw/riscv/boot.h > > create mode 100644 pc-bios/opensbi-riscv32-fw_jump.elf > > create mode 100644 pc-bios/opensbi-riscv64-fw_jump.elf > > create mode 160000 roms/opensbi > > Regards, > Bin
On Wed, Jun 19, 2019 at 10:30 PM Alistair Francis <alistair23@gmail.com> wrote: > > On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > On Wed, Jun 19, 2019 at 8:56 AM Alistair Francis > > <alistair.francis@wdc.com> wrote: > > > > > > This is an RFC as it will break ALL current users! See below for details. > > > > > > This series consolidates the current RISC-V kernel loading > > > impelementation while also adding support for the -bios option and more > > > advanced kernel image types. > > > > > > After consolidating the kernel loading we can extend the boot loader to > > > support a -bios option. We can also extend the kernel loading options to > > > support not just ELF files but other standard formats. > > > > > > Finally we can include the OpenSBI firmware by default for QEMU users. > > > > > > At the end of this series we are in the good place of no longer > > > requiring users to build firmware to boot a kernel. Instead users can > > > just run QEMu with the -kernel option and everything will work. They can > > > > This is great. I like booting kernel directly for testing without > > bothering the firmware stuff. > > That's the goal! Now we just need to not break everything. > > > > > > also override the firmware with their own using the -bios option. Using > > > "-bios none" will result in no firmware being loaded (as it is today). > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > Unfortunately this series (patch 5 specifically) results in all current > > > Linux boots being broken as users are already loading in their own > > > firmware, which overlaps with the now included default. They will > > > see this error: > > > > > > rom: requested regions overlap (rom phdr #0: ./images/qemuriscv64/fw_jump.elf. free=0x0000000080008090, addr=0x0000000080000000) > > > qemu-system-riscv64: rom check and register reset failed > > > > > > If a current user specieifies "-bios none" their flow will continue > > > working. A user can instead no longer load their firmware and > > > use the default or they can load their firmware with the -bios option. > > > > > > At the moment the best idea I have to not break all users is to only > > > include the default firmware if the user specifies "-bios opensbi". > > > That is change the default to not loading the firmware. Then we can work > > > on updating documentation and maybe in future change the default to > > > include a firmware and anyone who doesn't want a default firmware can > > > specify "-bios none". > > > > > > Any other ideas on how to not break everything? > > > > > > > > > > > > Alistair Francis (5): > > > hw/riscv: Split out the boot functions > > > hw/riscv: Add support for loading a firmware > > > hw/riscv: Extend the kernel loading support > > > roms: Add OpenSBI version 0.3 > > > hw/riscv: Load OpenSBI as the default firmware > > > > > > .gitmodules | 3 + > > > Makefile | 3 +- > > > configure | 1 + > > > hw/riscv/Makefile.objs | 1 + > > > hw/riscv/boot.c | 143 ++++++++++++++++++++++++++++ > > > hw/riscv/sifive_e.c | 17 +--- > > > hw/riscv/sifive_u.c | 19 +--- > > > hw/riscv/spike.c | 21 +--- > > > hw/riscv/virt.c | 54 ++--------- > > > include/hw/riscv/boot.h | 30 ++++++ > > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > > > Since we are considering adding "bios" images, I prefer to add the > > pure binary images instead of ELF images here. > > I didn't think about that. Can we just boot them in QEMU like we do > with the ELFs? Yes, use load_image_targphys() instead of load_elf(). Regards, Bin
On Wed, Jun 19, 2019 at 7:42 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Wed, Jun 19, 2019 at 10:30 PM Alistair Francis <alistair23@gmail.com> wrote: > > > > On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > On Wed, Jun 19, 2019 at 8:56 AM Alistair Francis > > > <alistair.francis@wdc.com> wrote: > > > > > > > > This is an RFC as it will break ALL current users! See below for details. > > > > > > > > This series consolidates the current RISC-V kernel loading > > > > impelementation while also adding support for the -bios option and more > > > > advanced kernel image types. > > > > > > > > After consolidating the kernel loading we can extend the boot loader to > > > > support a -bios option. We can also extend the kernel loading options to > > > > support not just ELF files but other standard formats. > > > > > > > > Finally we can include the OpenSBI firmware by default for QEMU users. > > > > > > > > At the end of this series we are in the good place of no longer > > > > requiring users to build firmware to boot a kernel. Instead users can > > > > just run QEMu with the -kernel option and everything will work. They can > > > > > > This is great. I like booting kernel directly for testing without > > > bothering the firmware stuff. > > > > That's the goal! Now we just need to not break everything. > > > > > > > > > also override the firmware with their own using the -bios option. Using > > > > "-bios none" will result in no firmware being loaded (as it is today). > > > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > > > > Unfortunately this series (patch 5 specifically) results in all current > > > > Linux boots being broken as users are already loading in their own > > > > firmware, which overlaps with the now included default. They will > > > > see this error: > > > > > > > > rom: requested regions overlap (rom phdr #0: ./images/qemuriscv64/fw_jump.elf. free=0x0000000080008090, addr=0x0000000080000000) > > > > qemu-system-riscv64: rom check and register reset failed > > > > > > > > If a current user specieifies "-bios none" their flow will continue > > > > working. A user can instead no longer load their firmware and > > > > use the default or they can load their firmware with the -bios option. > > > > > > > > At the moment the best idea I have to not break all users is to only > > > > include the default firmware if the user specifies "-bios opensbi". > > > > That is change the default to not loading the firmware. Then we can work > > > > on updating documentation and maybe in future change the default to > > > > include a firmware and anyone who doesn't want a default firmware can > > > > specify "-bios none". > > > > > > > > Any other ideas on how to not break everything? > > > > > > > > > > > > > > > > Alistair Francis (5): > > > > hw/riscv: Split out the boot functions > > > > hw/riscv: Add support for loading a firmware > > > > hw/riscv: Extend the kernel loading support > > > > roms: Add OpenSBI version 0.3 > > > > hw/riscv: Load OpenSBI as the default firmware > > > > > > > > .gitmodules | 3 + > > > > Makefile | 3 +- > > > > configure | 1 + > > > > hw/riscv/Makefile.objs | 1 + > > > > hw/riscv/boot.c | 143 ++++++++++++++++++++++++++++ > > > > hw/riscv/sifive_e.c | 17 +--- > > > > hw/riscv/sifive_u.c | 19 +--- > > > > hw/riscv/spike.c | 21 +--- > > > > hw/riscv/virt.c | 54 ++--------- > > > > include/hw/riscv/boot.h | 30 ++++++ > > > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > > > > > Since we are considering adding "bios" images, I prefer to add the > > > pure binary images instead of ELF images here. > > > > I didn't think about that. Can we just boot them in QEMU like we do > > with the ELFs? > > Yes, use load_image_targphys() instead of load_elf(). Ah, that is obvious. I'll update it to use the bin files then. Alistair > > Regards, > Bin
On Wed, 2019-06-19 at 11:23 -0700, Alistair Francis wrote: > On Wed, Jun 19, 2019 at 7:42 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Wed, Jun 19, 2019 at 10:30 PM Alistair Francis <alistair23@gmail.com> wrote: > > > On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > > > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > > > > > > > Since we are considering adding "bios" images, I prefer to add the > > > > pure binary images instead of ELF images here. > > > > > > I didn't think about that. Can we just boot them in QEMU like we do > > > with the ELFs? > > > > Yes, use load_image_targphys() instead of load_elf(). > > Ah, that is obvious. I'll update it to use the bin files then. I'm unclear on the advantages of using one format over the other, but one question comes to mind: once this is in, we will probably want to have OpenSBI packaged separately in distributions, the same way it already happens for SeaBIOS, SLOF and edk2-based firmwares. Will using either of the formats prevent that from happening? -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Jun 20, 2019 at 1:16 AM Andrea Bolognani <abologna@redhat.com> wrote: > > On Wed, 2019-06-19 at 11:23 -0700, Alistair Francis wrote: > > On Wed, Jun 19, 2019 at 7:42 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > On Wed, Jun 19, 2019 at 10:30 PM Alistair Francis <alistair23@gmail.com> wrote: > > > > On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > > > > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > > > > > > > > > Since we are considering adding "bios" images, I prefer to add the > > > > > pure binary images instead of ELF images here. > > > > > > > > I didn't think about that. Can we just boot them in QEMU like we do > > > > with the ELFs? > > > > > > Yes, use load_image_targphys() instead of load_elf(). > > > > Ah, that is obvious. I'll update it to use the bin files then. > > I'm unclear on the advantages of using one format over the other, The main one that I see is that everyone else is already using .bin and no one else is using .elf. > but one question comes to mind: once this is in, we will probably > want to have OpenSBI packaged separately in distributions, the same > way it already happens for SeaBIOS, SLOF and edk2-based firmwares. > > Will using either of the formats prevent that from happening? Both options allow this. OE-Core already packages OpenSBI by default, Fedora and Debian are moving to OpenSBI for RISC-V targets as well. Any distro that supports the RISC-V toolchain (which is all upstreamed) can build OpenSBI. Alistair > > -- > Andrea Bolognani / Red Hat / Virtualization >
On Thu, Jun 20, 2019 at 9:18 PM Alistair Francis <alistair23@gmail.com> wrote: > > On Thu, Jun 20, 2019 at 1:16 AM Andrea Bolognani <abologna@redhat.com> wrote: > > > > On Wed, 2019-06-19 at 11:23 -0700, Alistair Francis wrote: > > > On Wed, Jun 19, 2019 at 7:42 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > On Wed, Jun 19, 2019 at 10:30 PM Alistair Francis <alistair23@gmail.com> wrote: > > > > > On Wed, Jun 19, 2019 at 7:26 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > pc-bios/opensbi-riscv32-fw_jump.elf | Bin 0 -> 197988 bytes > > > > > > > pc-bios/opensbi-riscv64-fw_jump.elf | Bin 0 -> 200192 bytes > > > > > > > > > > > > Since we are considering adding "bios" images, I prefer to add the > > > > > > pure binary images instead of ELF images here. > > > > > > > > > > I didn't think about that. Can we just boot them in QEMU like we do > > > > > with the ELFs? > > > > > > > > Yes, use load_image_targphys() instead of load_elf(). > > > > > > Ah, that is obvious. I'll update it to use the bin files then. > > > > I'm unclear on the advantages of using one format over the other, > > The main one that I see is that everyone else is already using .bin > and no one else is using .elf. > > > but one question comes to mind: once this is in, we will probably > > want to have OpenSBI packaged separately in distributions, the same > > way it already happens for SeaBIOS, SLOF and edk2-based firmwares. > > > > Will using either of the formats prevent that from happening? > > Both options allow this. > > OE-Core already packages OpenSBI by default, Fedora and Debian are > moving to OpenSBI for RISC-V targets as well. Fedora uses OpenSBI for the last 2 or 3 months now. I don't plan to update BBL builds. OpenSBI packages in Fedora/RISCV isn't finalized, but it does ship *.elf and *.bin files. > > Any distro that supports the RISC-V toolchain (which is all > upstreamed) can build OpenSBI. > > Alistair > > > > > -- > > Andrea Bolognani / Red Hat / Virtualization > > >
On Thu, 2019-06-20 at 21:43 +0300, David Abdurachmanov wrote: > On Thu, Jun 20, 2019 at 9:18 PM Alistair Francis <alistair23@gmail.com> wrote: > > On Thu, Jun 20, 2019 at 1:16 AM Andrea Bolognani <abologna@redhat.com> wrote: > > > but one question comes to mind: once this is in, we will probably > > > want to have OpenSBI packaged separately in distributions, the same > > > way it already happens for SeaBIOS, SLOF and edk2-based firmwares. > > > > > > Will using either of the formats prevent that from happening? > > > > Both options allow this. > > > > OE-Core already packages OpenSBI by default, Fedora and Debian are > > moving to OpenSBI for RISC-V targets as well. > > > > Any distro that supports the RISC-V toolchain (which is all > > upstreamed) can build OpenSBI. > > Fedora uses OpenSBI for the last 2 or 3 months now. I don't plan to update > BBL builds. OpenSBI packages in Fedora/RISCV isn't finalized, but it does > ship *.elf and *.bin files. Sounds good to me, thanks for confirming! -- Andrea Bolognani / Red Hat / Virtualization
On Fri, 2019-06-21 at 14:35 +0200, Andrea Bolognani wrote: > On Thu, 2019-06-20 at 21:43 +0300, David Abdurachmanov wrote: > > On Thu, Jun 20, 2019 at 9:18 PM Alistair Francis <alistair23@gmail.com> wrote: > > > OE-Core already packages OpenSBI by default, Fedora and Debian are > > > moving to OpenSBI for RISC-V targets as well. > > > > > > Any distro that supports the RISC-V toolchain (which is all > > > upstreamed) can build OpenSBI. > > > > Fedora uses OpenSBI for the last 2 or 3 months now. I don't plan to update > > BBL builds. OpenSBI packages in Fedora/RISCV isn't finalized, but it does > > ship *.elf and *.bin files. > > Sounds good to me, thanks for confirming! From further off-list discussion with David, I have learned that recent Fedora images include an OpenSBI build with embedded U-Boot payload, such that you only need to have that single file on the host and pass it to QEMU via -kernel[1] for RISC-V guest boot to work. I played with it over the past few days, and it works very nicely. I think this is the result that we want to ultimately reach: a single RISC-V "firmware" binary installed on the host through an appropriate distro package, shared among guests, with everything else that is guest-specific being contained in the corresponding disk image. This is what other architectures are already doing, with SeaBIOS and OVMF on x86_64, AAVMF on aarch64 and SLOF on ppc64 all being handled this way: RISC-V should, where it makes sense, follow suit. QEMU also recently introduced a JSON-based specification that can be used to advertise guest firmwares and libvirt already supports it, which makes firmware configuration either extremely convenient or entirely automatic for the user: the OpenSBI support should also be advertised this way. [1] I guess that'd be -bios after these patches? -- Andrea Bolognani / Red Hat / Virtualization
© 2016 - 2025 Red Hat, Inc.