| Message ID | cover.1560904640.git.alistair.francis@wdc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | RISC-V: Add firmware loading support and default | expand |
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?
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!
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?