There are QEMU targets that have fixed hardware which do rely on the firmware to have a fixed view of the hardware. sbsa-ref is one such board although there will be some versioning required for later levels.
On Wed, 27 Oct 2021, 19:39 Tom Rini, <tr...@konsulko.com> wrote: > On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote: > > Hi all, > > > > On Wed, 27 Oct 2021 at 08:56, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > > > > > François Ozog <francois.o...@linaro.org> writes: > > > > > > > > > Hi Simon > > > > > > > > > > The only place I could agree with this file presence is in the > documentation directory, not in dts. It creates a mental picture for the > reader > > > > > an entirely bad mind scheme around Qemu and DT. > > > > > > > > > > And even in a documentation directory I would place a bug warning: > don’t use this with any kernel , Qemu generates a DT dynamically > > > > > based on cpu, memory and devices specified at the command line. > > > > > > > > Certainly for the arm, aarch64 and riscv "virt" machines you should > > > > always use the QEMU generated DTB. I'm not entirely clear what a > > > > qemu_arm and qemu_arm64 def targets are meant to be in this context. > > > > > > Agreed. We cannot include random device trees in U-Boot for devices > > > that generate their own at run time or otherwise have the source of > > > truth elsewhere. > > > > Until we have a way of bringing in the u-boot.dtsi that people in QEMU > > can agree on, I don't see an alternative. I will send a series for the > > bloblist handoff next week and I think you will all see what I mean. > > I think the alternative is that QEMU in U-Boot just can't be used for > certain features. Which is annoying in that it would be good to use it > to test certain feature, yes. It's generating a good and valid enough > dtb for Linux, so it should be good enough for us in general. > > -- > Tom >
