Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64

[Alex Bennée]

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