From: Jonathan Behrens <jonathan@fintelia.io>
To: Alistair Francis <alistair23@gmail.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
Palmer Dabbelt <palmer@sifive.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Alistair Francis <Alistair.Francis@wdc.com>
Subject: Re: [Qemu-devel] [PATCH for-4.1 2/2] target/riscv: Add support for -bios "firmware_filename" flag
Date: Fri, 31 May 2019 18:38:12 -0400 [thread overview]
Message-ID: <CANnJOVGyY71-aZd+dmZWAOUzEfFEOHjAAzVdbGTP_XfP4CmgkA@mail.gmail.com> (raw)
In-Reply-To: <CAKmqyKM3C59_w214=mqLFpfwPhUjcLL0EuOY0Yk3DQePx8ZTQg@mail.gmail.com>
I've thought some more about this issue, and long term I think there are a
couple different useful configurations:
- For end users, having default firmware that loaded the OS from a block
device would be easiest
- Current invocation: impossible
- Proposed: empty command line (i.e. pass neither -bios nor -kernel)
- Custom firmware support would be good to test possible firmware
improvements or if the default is missing something
- Current invocation: -kernel firmware.elf
- Proposed: -bios firmware.elf
- A kernel developer may want to test a kernel binary without having
to make a full disk image or bundle firmware (on x86 and perhaps other
architectures this is done with the -kernel parameter, but for RISC-V that
invocation currently is used to load M-mode code rather than supervisor
code)
- Current invocation: impossible
- Proposed: -bios firmware.elf -kernel kernel.bin
- Ideally `-kernel kernel.bin` be the same except using default
firmware, but I don't know if QEMU would be willing to deprecate the
current syntax to allow it
For now, it is probably too early to add default firmware (but perhaps
not?) which would leave only the firmware only and firmware + kernel
variants. What do other people think about this?
Jonathan
On Mon, May 20, 2019 at 12:56 PM Alistair Francis <alistair23@gmail.com>
wrote:
> On Sat, May 18, 2019 at 2:57 PM Jonathan Behrens <jonathan@fintelia.io>
> wrote:
> >
> > > I've never been fully convinced of this, why not just use the generic
> loader?
> >
> > If I understand you are proposing passing bbl (or other firmware) with
> the -kernel flag, and then vmlinux (or another kernel) with the -initrd
> flag? Wouldn't this result in losing the ability to pass a real init
> ramdisk to Linux? It also seems to open the possibility for strange
> bugs/compatibility issues later if firmware starts recognizing any "initrd"
> entries in the device tree as kernel code to jump into.
>
> No I mean passing in OpenSBI (or some other boot loader) via the
> -kernel option and then passing in the kernel with QEMU's generic
> device loader. This is documented as part of the OpenSBI boot flow:
> https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md
>
> The only disadvantage with that is that we don't get debug symbols
> from the kernel, but it does mean that the boot loader in QEMU is much
> simpler.
>
> >
> > I do wonder though how compatible the current design is with providing
> default firmware for riscv in the future.
> >
> > > This should be in a generic boot.c file and support added to all
> RISC-V boards.
> >
> > I can do this for v2.
>
> Thanks
>
> Alistair
>
> >
> > Jonathan
>
next prev parent reply other threads:[~2019-05-31 22:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 22:23 [Qemu-devel] [PATCH for-4.1 0/2] target/riscv: Improve virt machine kernel handling Jonathan Behrens
2019-05-17 22:23 ` [Qemu-devel] [PATCH for-4.1 1/2] target/riscv: virt machine shouldn't assume ELF entry is DRAM base Jonathan Behrens
2019-05-17 22:23 ` [Qemu-devel] [PATCH for-4.1 2/2] target/riscv: Add support for -bios "firmware_filename" flag Jonathan Behrens
2019-05-17 22:36 ` Alistair Francis
2019-05-18 21:56 ` Jonathan Behrens
2019-05-20 16:53 ` Alistair Francis
2019-05-31 22:38 ` Jonathan Behrens [this message]
2019-06-06 23:08 ` Alistair Francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANnJOVGyY71-aZd+dmZWAOUzEfFEOHjAAzVdbGTP_XfP4CmgkA@mail.gmail.com \
--to=jonathan@fintelia.io \
--cc=Alistair.Francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=palmer@sifive.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=sagark@eecs.berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).