[Qemu-devel] [PATCH v1 0/2] RISC-V: Add default OpenSBI ROM

Alistair Francis posted 2 patches 4 years, 8 months ago
Test docker-clang@ubuntu passed
Test s390x passed
Test asan passed
Test docker-mingw@fedora passed
Test FreeBSD passed
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/cover.1562611535.git.alistair.francis@wdc.com
Maintainers: Palmer Dabbelt <palmer@sifive.com>, Bastian Koppelmann <kbastian@mail.uni-paderborn.de>, Alistair Francis <Alistair.Francis@wdc.com>, Sagar Karandikar <sagark@eecs.berkeley.edu>
There is a newer version of this series
.gitmodules                                  |   3 ++
LICENSE                                      |  21 +++++---
Makefile                                     |   5 +-
hw/riscv/boot.c                              |  49 +++++++++++++++++++
hw/riscv/sifive_u.c                          |   7 +--
hw/riscv/virt.c                              |  11 +++--
include/hw/riscv/boot.h                      |   3 ++
pc-bios/README                               |  11 +++++
pc-bios/opensbi-riscv32-virt-fw_jump.bin     | Bin 0 -> 36888 bytes
pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 40968 bytes
pc-bios/opensbi-riscv64-virt-fw_jump.bin     | Bin 0 -> 40968 bytes
qemu-deprecated.texi                         |  20 ++++++++
roms/Makefile                                |  48 +++++++++++++-----
roms/opensbi                                 |   1 +
14 files changed, 152 insertions(+), 27 deletions(-)
create mode 100755 pc-bios/opensbi-riscv32-virt-fw_jump.bin
create mode 100755 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
create mode 100755 pc-bios/opensbi-riscv64-virt-fw_jump.bin
create mode 160000 roms/opensbi
[Qemu-devel] [PATCH v1 0/2] RISC-V: Add default OpenSBI ROM
Posted by Alistair Francis 4 years, 8 months ago
This series includes the OpenSBI firmware for QEMU RISC-V users.

To avoid breakages we have not changed the default behaviour of QEMU.
The plan is to change the default though, which is why an entry to the
qemu-deprecated.texi file has been added as well as a new warning.

After this series QEMU 4.1 has three options:
 1. ``-bios none`` - This is the current default behavior if no -bios option
      is included. QEMU will not automatically load any firmware. It is up
      to the user to load all the images they need.
 2. ``-bios default`` - In a future QEMU release this will become the default
      behaviour if no -bios option is specified. This option will load the
      default OpenSBI firmware automatically. The firmware is included with
      the QEMU release and no user interaction is required. All a user needs
      to do is specify the kernel they want to boot with the -kernel option
 3. ``-bios <file>`` - Tells QEMU to load the specified file as the firmwrae.

All users should transition to using a -bios option. We can start
updating all documentation after the release of 4.1.

At the end of this series and the transition period 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).

This is based on my original series adding OpenSBI support but now has
improved documentation changes around the license.

Alistair Francis (2):
  roms: Add OpenSBI version 0.4
  hw/riscv: Load OpenSBI as the default firmware

 .gitmodules                                  |   3 ++
 LICENSE                                      |  21 +++++---
 Makefile                                     |   5 +-
 hw/riscv/boot.c                              |  49 +++++++++++++++++++
 hw/riscv/sifive_u.c                          |   7 +--
 hw/riscv/virt.c                              |  11 +++--
 include/hw/riscv/boot.h                      |   3 ++
 pc-bios/README                               |  11 +++++
 pc-bios/opensbi-riscv32-virt-fw_jump.bin     | Bin 0 -> 36888 bytes
 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 40968 bytes
 pc-bios/opensbi-riscv64-virt-fw_jump.bin     | Bin 0 -> 40968 bytes
 qemu-deprecated.texi                         |  20 ++++++++
 roms/Makefile                                |  48 +++++++++++++-----
 roms/opensbi                                 |   1 +
 14 files changed, 152 insertions(+), 27 deletions(-)
 create mode 100755 pc-bios/opensbi-riscv32-virt-fw_jump.bin
 create mode 100755 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
 create mode 100755 pc-bios/opensbi-riscv64-virt-fw_jump.bin
 create mode 160000 roms/opensbi

-- 
2.22.0


Re: [Qemu-devel] [PATCH v1 0/2] RISC-V: Add default OpenSBI ROM
Posted by Palmer Dabbelt 4 years, 8 months ago
On Mon, 08 Jul 2019 11:49:35 PDT (-0700), Alistair Francis wrote:
> This series includes the OpenSBI firmware for QEMU RISC-V users.
>
> To avoid breakages we have not changed the default behaviour of QEMU.
> The plan is to change the default though, which is why an entry to the
> qemu-deprecated.texi file has been added as well as a new warning.
>
> After this series QEMU 4.1 has three options:
>  1. ``-bios none`` - This is the current default behavior if no -bios option
>       is included. QEMU will not automatically load any firmware. It is up
>       to the user to load all the images they need.
>  2. ``-bios default`` - In a future QEMU release this will become the default
>       behaviour if no -bios option is specified. This option will load the
>       default OpenSBI firmware automatically. The firmware is included with
>       the QEMU release and no user interaction is required. All a user needs
>       to do is specify the kernel they want to boot with the -kernel option
>  3. ``-bios <file>`` - Tells QEMU to load the specified file as the firmwrae.
>
> All users should transition to using a -bios option. We can start
> updating all documentation after the release of 4.1.

I haven't looked at the code yet, but as the last one was fine it's probably
OK.  My only issue here is the timing: it's after the soft freeze so if I
understand correctly we're not supposed to take any new features into 4.1.
That's kind of unfortunate because it's somewhat unobtrusive and super useful.

Peter: would you be OK taking this some time later this week?  I'd want to dig
through it and then bang on it a bit first.  If not then I'll queue it up for
4.2.

> At the end of this series and the transition period 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).
>
> This is based on my original series adding OpenSBI support but now has
> improved documentation changes around the license.
>
> Alistair Francis (2):
>   roms: Add OpenSBI version 0.4
>   hw/riscv: Load OpenSBI as the default firmware
>
>  .gitmodules                                  |   3 ++
>  LICENSE                                      |  21 +++++---
>  Makefile                                     |   5 +-
>  hw/riscv/boot.c                              |  49 +++++++++++++++++++
>  hw/riscv/sifive_u.c                          |   7 +--
>  hw/riscv/virt.c                              |  11 +++--
>  include/hw/riscv/boot.h                      |   3 ++
>  pc-bios/README                               |  11 +++++
>  pc-bios/opensbi-riscv32-virt-fw_jump.bin     | Bin 0 -> 36888 bytes
>  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 40968 bytes
>  pc-bios/opensbi-riscv64-virt-fw_jump.bin     | Bin 0 -> 40968 bytes
>  qemu-deprecated.texi                         |  20 ++++++++
>  roms/Makefile                                |  48 +++++++++++++-----
>  roms/opensbi                                 |   1 +
>  14 files changed, 152 insertions(+), 27 deletions(-)
>  create mode 100755 pc-bios/opensbi-riscv32-virt-fw_jump.bin
>  create mode 100755 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
>  create mode 100755 pc-bios/opensbi-riscv64-virt-fw_jump.bin
>  create mode 160000 roms/opensbi

Re: [Qemu-devel] [PATCH v1 0/2] RISC-V: Add default OpenSBI ROM
Posted by Peter Maydell 4 years, 8 months ago
On Tue, 9 Jul 2019 at 09:35, Palmer Dabbelt <palmer@sifive.com> wrote:
> I haven't looked at the code yet, but as the last one was fine it's probably
> OK.  My only issue here is the timing: it's after the soft freeze so if I
> understand correctly we're not supposed to take any new features into 4.1.
> That's kind of unfortunate because it's somewhat unobtrusive and super useful.
>
> Peter: would you be OK taking this some time later this week?  I'd want to dig
> through it and then bang on it a bit first.  If not then I'll queue it up for
> 4.2.

The first attempt at putting this into master got onto the list before
freeze, so it's OK. Plus this clearly will only affect users using the
riscv boards, so it's a limited-scope change. So I think we're better
off putting it into 4.1 rather than not, assuming you're happy with
the level of testing it's had.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v1 0/2] RISC-V: Add default OpenSBI ROM
Posted by Palmer Dabbelt 4 years, 8 months ago
On Tue, 09 Jul 2019 01:37:08 PDT (-0700), Peter Maydell wrote:
> On Tue, 9 Jul 2019 at 09:35, Palmer Dabbelt <palmer@sifive.com> wrote:
>> I haven't looked at the code yet, but as the last one was fine it's probably
>> OK.  My only issue here is the timing: it's after the soft freeze so if I
>> understand correctly we're not supposed to take any new features into 4.1.
>> That's kind of unfortunate because it's somewhat unobtrusive and super useful.
>>
>> Peter: would you be OK taking this some time later this week?  I'd want to dig
>> through it and then bang on it a bit first.  If not then I'll queue it up for
>> 4.2.
>
> The first attempt at putting this into master got onto the list before
> freeze, so it's OK. Plus this clearly will only affect users using the
> riscv boards, so it's a limited-scope change. So I think we're better
> off putting it into 4.1 rather than not, assuming you're happy with
> the level of testing it's had.

Awesome.  I always test stuff myself a bit, but with any luck I should be able
to get a good look at it over the next few days.