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

[Simon Glass]

Hi Peter,

On Wed, 25 Sept 2024 at 16:23, Peter Maydell <peter.maydell at linaro.org> wrote:
>
> 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.

OK, I see, thanks.

So I suppose it would be OK for U-Boot to include its own devicetree,
just for its own use, to configure the devices and generate the ACPI
tables?

>
> 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.

OK, thank you. Patrick please get in touch as needed.

Re my patch, did you take another look? Should I try again on that
mailing list? I would very much like to get it into QEMU.

Regards,
SImon