Hi Peter, On Wed, 25 Sept 2024 at 16:23, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Fri, 20 Sept 2024 at 16:59, Simon Glass <s...@chromium.org> wrote: > > On Fri, 20 Sept 2024 at 12:29, Patrick Rudolph > > <patrick.rudo...@9elements.com> wrote: > > > On Fri, Sep 20, 2024 at 11:37 AM Simon Glass <s...@chromium.org> wrote: > > > > On Fri, 20 Sept 2024 at 09:54, Patrick Rudolph > > > > <patrick.rudo...@9elements.com> wrote: > > > > > > > > > > On Thu, Sep 19, 2024 at 4:10 PM Simon Glass <s...@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
