[PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64

[Simon Glass]

Hi Tom,

On Mon, 1 Nov 2021 at 12:07, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote:
> > Hi Simon
> >
> > Le lun. 1 nov. 2021 à 17:58, Simon Glass <sjg at chromium.org> a écrit :
> >
> > > Hi Peter,
> > >
> > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell <peter.maydell at linaro.org>
> > > wrote:
> > > >
> > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass <sjg at chromium.org> wrote:
> > > > >
> > > > > Add this file, generated from qemu, so there is a reference devicetree
> > > > > in the U-Boot tree.
> > > > >
> > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > >
> > > > Note that the dtb you get from QEMU is only guaranteed to work if:
> > > >  1) you run it on the exact same QEMU version you generated it with
> > > >  2) you pass QEMU the exact same command line arguments you used
> > > >     when you generated it
> > >
> > > Yes, I certainly understand that. In general this is not safe, but in
> > > practice it works well enough for development and CI.
> >
> > You recognize that you hijack a product directory with development hack
> > facility. There is a test directory to keep things clear. There can be a
> > dev-dts or something similar for Dev time tools.
> > I have only seen push back on those fake dts files in the dts directory: I
> > guess that unless someone strongly favors a continuation of the discussion,
> > you may consider re-shaping the proposal to address concerns.
>
> Yes.  We need to document how to make development easier.  But I'm still
> not on board with the notion of including DTS files for platforms where
> the source of truth for the DTB is elsewhere.  That's going to bring us
> a lot more pain.

Are you talking about QEMU specifically, or Raspberry Pi?

How can we get this resolved? I very much want to get to just having
OF_SEPARATE and OF_EMBED as the only available build-time options,
with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for
runtime support. I feel that separating the build-time and run-time
behaviour is very important. Over time perhaps we will have some
success in upstreaming bindings, but for now we have what we have.
There is still a lot of pushback on U-Boot having things in the
devicetree, although I do see that softening somewhat.

>
> It is important to make sure our "develop our project" workflow is sane
> and relatively pain free.  But that needs to not come by making
> sacrifices to the "use our project" outcome.  I would hope for example
> that the new Pi zero platform is just dtb changes, as far as the linux
> kernel is concerned which means that for rpi_arm64 (which uses run time
> dtb) it also just works.  And that's what we want to see.

So long as OF_BOARD is enabled then the flow should work as you expect.

Regards,
Simon