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

[Tom Rini]

On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote:
> 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?

I was using two of the more common and readily available platforms where
the source of truth for the DTS/DTB is not (and will not be) U-Boot.

> 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.

To reiterate, the uniform bit of feedback on this series has been that
everyone else disagrees with your notion that we _must_ have a dts
in-tree.

> > 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.

Then we need to get things spun such that we can build the platforms
where the dtb is given to us, complete and correct, at run time, to not
require an in-tree dts that's not going to be used.  Documentation
(another area we have much improved on these past few years and for
which I am grateful for all of the effort behind!) is how we make the
developer use-case for those platforms better.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211102/dc6f555e/attachment.sig>