qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-b


From: Alistair Francis
Subject: Re: [PATCH v2] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none"
Date: Thu, 18 May 2023 14:53:05 +1000

On Wed, May 17, 2023 at 6:45 PM Andrea Bolognani <abologna@redhat.com> wrote:
>
> On Wed, May 17, 2023 at 02:57:12PM +1000, Alistair Francis wrote:
> > On Mon, May 8, 2023 at 9:45 PM Andrea Bolognani <abologna@redhat.com> wrote:
> > > > > Taking a step back, what is even the use case for having M-mode code
> > > > > in pflash0? If you want to use an M-mode firmware, can't you just use
> > > > > -bios instead? In other words, can we change the behavior so that
> > > > > pflash being present always mean loading S-mode firmware off it?
> >
> > It was originally added to support Oreboot (the Rust version of
> > Coreboot). The idea was that Oreboot (ROM) would be in flash and then
> > go from there.
> >
> > It also applies to other ROM code that a user might want to test that
> > runs before OpenSBI.
>
> Is there a reason why these would have to be loaded into pflash
> instead of being passed to -bios? From a quick look at the
> documentation for oreboot[1], it looks like they're doing the latter.

At one point we loaded Oreboot in in flash and booted from that. I
think Oreboot then loaded OpenSBI into memory. The idea was to mimic
what a physical board would do, so we could allow testing.

It doesn't look like it's used any more.

>
> Either way, assuming that there's a genuine reason why pflash must be
> used, I think the behavior implemented in v1 (pflash0 is M-mode when
> -bios none is used, S-mode otherwise) maps very well conceptually,
> and results in behavior matching that of other architectures out of
> the box. That's good enough for me :) I was just wondering whether we
> could keep things even simpler.

I don't see a reason to remove the boot from pflash if no -bios
argument is supplied. If there is a good reason to, I think we can
(via deprecation) but the current functionality seems fine to me.

Alistair

>
>
> [1] 
> https://github.com/oreboot/oreboot/blob/main/src/mainboard/emulation/qemu-riscv/QEMU.md
> --
> Andrea Bolognani / Red Hat / Virtualization
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]