[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-riscv] [PATCH v1 0/5] RISC-V: Add firmware loading support and
Re: [Qemu-riscv] [PATCH v1 0/5] RISC-V: Add firmware loading support and default
Tue, 25 Jun 2019 23:21:45 -0700 (PDT)
On Tue, 25 Jun 2019 10:06:33 PDT (-0700), address@hidden wrote:
On Mon, Jun 24, 2019 at 3:14 PM Alistair Francis
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 for QEMU 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).
@Palmer Dabbelt can this go in your 4.1 PR? It has been reviewed and tested.
I don't see any reason why not. It's top of my list, after I get through my
first pass at email.
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 | 5 +-
hw/riscv/Makefile.objs | 1 +
hw/riscv/boot.c | 154 +++++++++++++++++++
hw/riscv/sifive_e.c | 17 +-
hw/riscv/sifive_u.c | 22 +--
hw/riscv/spike.c | 21 +--
hw/riscv/virt.c | 60 ++------
include/hw/riscv/boot.h | 32 ++++
pc-bios/opensbi-riscv32-virt-fw_jump.bin | Bin 0 -> 28848 bytes
pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 28904 bytes
pc-bios/opensbi-riscv64-virt-fw_jump.bin | Bin 0 -> 28904 bytes
qemu-deprecated.texi | 20 +++
roms/Makefile | 48 ++++--
roms/opensbi | 1 +
15 files changed, 278 insertions(+), 106 deletions(-)
create mode 100644 hw/riscv/boot.c
create mode 100644 include/hw/riscv/boot.h
create mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
create mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
create mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
create mode 160000 roms/opensbi
- [Qemu-riscv] [PATCH v1 3/5] hw/riscv: Extend the kernel loading support, (continued)
- [Qemu-riscv] [PATCH v1 3/5] hw/riscv: Extend the kernel loading support, Alistair Francis, 2019/06/24
- [Qemu-riscv] [PATCH v1 2/5] hw/riscv: Add support for loading a firmware, Alistair Francis, 2019/06/24
- [Qemu-riscv] [PATCH v1 5/5] hw/riscv: Load OpenSBI as the default firmware, Alistair Francis, 2019/06/24
- [Qemu-riscv] [PATCH v1 4/5] roms: Add OpenSBI version 0.3, Alistair Francis, 2019/06/24
- Re: [Qemu-riscv] [PATCH v1 0/5] RISC-V: Add firmware loading support and default, Alistair Francis, 2019/06/25
- Re: [Qemu-riscv] [PATCH v1 0/5] RISC-V: Add firmware loading support and default,
Palmer Dabbelt <=