On Wed, May 17, 2023 at 6:45 PM Andrea Bolognani <abolo...@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 <abolo...@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 >
