On Fri, 20 Sept 2024 at 16:59, Simon Glass sjg@chromium.org wrote:
On Fri, 20 Sept 2024 at 12:29, Patrick Rudolph patrick.rudolph@9elements.com wrote:
On Fri, Sep 20, 2024 at 11:37 AM Simon Glass sjg@chromium.org wrote:
On Fri, 20 Sept 2024 at 09:54, Patrick Rudolph patrick.rudolph@9elements.com wrote:
On Thu, Sep 19, 2024 at 4:10 PM Simon Glass sjg@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