[PATCH v3 22/30] board: emulation: Add QEMU sbsa support

[Peter Maydell]

On Fri, 20 Sept 2024 at 16:59, Simon Glass <sjg at chromium.org> wrote:
> On Fri, 20 Sept 2024 at 12:29, Patrick Rudolph
> <patrick.rudolph at 9elements.com> wrote:
> > On Fri, Sep 20, 2024 at 11:37 AM Simon Glass <sjg at chromium.org> wrote:
> > > On Fri, 20 Sept 2024 at 09:54, Patrick Rudolph
> > > <patrick.rudolph at 9elements.com> wrote:
> > > >
> > > > On Thu, Sep 19, 2024 at 4:10 PM Simon Glass <sjg at chromium.org> wrote:
> > > > The QEMU generated FDT contains a bare minimum of nodes and isn't
> > > > suitable to boot an OS.
> > >
> > > Yes, I am not very pleased about that, particularly as my patch to
> > > allow passing a proper FDT to QEMU[1] has still not been accepted.
> > >
> > The SBSA ref machine was designed that way, to make sure that only ACPI is used
> > to boot the OS.
>
> Er, but doesn't firmware run before the OS? It seems like a strange
> design decision.

The sbsa-ref platform is supposed to be a reference platform
that works like a real hardware system. On that kind of
system (as I understand it) the firmware knows exactly
what hardware it is running on (subject to some minor
variations, which on real hardware it can query via
a board-management-processor subsystem and which on QEMU
for the moment are passed to it via a cut-down device
tree format). Anything that wants to be first-booted software
on this QEMU board should know (hard-coded, in any way it likes)
what the hardware it is running on is.

The general assumption is that that first-booted firmware
will be the usual OP-TEE + UEFI stack. But if you wanted
to write some other firmware to run on it there's nothing
particular stopping you, same as there's nothing inherently
stopping you from writing your own BIOS for your PC. (Though
we do make revisions to the board occasionally which the
firmware has to keep up with, in the same way that the BIOS
needs to be aware of new motherboard revisions.)

But if you want more detailed information about this board
you'd be better off cc'ing qemu-devel and the listed
maintainers for it, not me personally: it's not something
I actively use.

-- PMM