[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 10:06:33 -0700
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.
> 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 1/5] hw/riscv: Split out the boot functions, (continued)
- [Qemu-riscv] [PATCH v1 1/5] hw/riscv: Split out the boot functions, Alistair Francis, 2019/06/24
- [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 <=