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, 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 wrote:
> > >
> > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> > > >
> > > > François Ozog 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
>
