[PATCH v7 14/31] arm: highbank: Add devicetree files

[Tom Rini]

On Tue, Dec 07, 2021 at 09:09:54AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 7 Dec 2021 at 09:07, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Dec 07, 2021 at 09:02:23AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 7 Dec 2021 at 08:39, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Tue, Dec 07, 2021 at 08:33:49AM -0700, Simon Glass wrote:
> > > > > Hi Andre,
> > > > >
> > > > > On Tue, 7 Dec 2021 at 08:25, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Dec 07, 2021 at 12:59:48AM +0000, Andre Przywara wrote:
> > > > > > > On Mon,  6 Dec 2021 17:11:52 -0700
> > > > > > > Simon Glass <sjg at chromium.org> wrote:
> > > > > > >
> > > > > > > > Sync these files, obtained from Linux v5.15.
> > > > > > >
> > > > > > > Sorry, but this would be wrong.
> > > > > > > How do you know which board it is? Highbank or Midway? We use the
> > > > > > > same binary for both, and decide either by the DT nodes we find in DRAM
> > > > > > > or by some autodetection (Cortex-A9 vs. Cortex-A15) if there are
> > > > > > > differences. The memory size would possibly be wrong (it's a DIMM slot).
> > > > > > > If you need *some* DT for build reasons, whatever, but at least go with
> > > > > > > the empty stub.
> > > > > > >
> > > > > > > And I still don't get this whole development argument: Why would
> > > > > > > anyone need some random or partial DT sample in the U-Boot tree to do
> > > > > > > development?
> > > > > > > If people develop a driver, the document to code against is the
> > > > > > > *binding* documentation, which describes what to expect from the DT
> > > > > > > nodes. Then you *test* it against an actual tree, but on the actual
> > > > > > > hardware, in which case you get the actual DTB, from the board.
> > > > > > > If a developer needs to take a sneak peek into an actual DTB,
> > > > > > > there are so many simple ways to do that: QEMU's dumpdtb, RPi's SD
> > > > > > > card content, U-Boot's "fdt addr $fdtcontroladdr; fdt print", the
> > > > > > > kernel's /sys/firmware/devicetree/base, ... When you port U-Boot to a
> > > > > > > board, getting hands on the actual DT is probably the least of your
> > > > > > > problems.
> > > > > > >
> > > > > > > So why would we need some mostly wrong DTs in the U-Boot tree?
> > > > > > > It seems to suggest that you can hack the DT to make things work, but
> > > > > > > this sounds bonkers, as the real DTB comes from somewhere else (SPI
> > > > > > > flash, SD card, generated based on command line), and patching U-Boot's
> > > > > > > copy to make things work is just wishful thinking.
> > > > > > >
> > > > > > > I can see the hacker's desire to play around with the DTB from time
> > > > > > > to time (What happens if the GPIO is wrong? Can we deal with two
> > > > > > > instances of the same device?), but for those experiments there are
> > > > > > > plenty of ways to achieve this - and be it temporarily replacing the
> > > > > > > empty DT stub. I just feel that bending the (board's) DT design ideas
> > > > > > > for a hacker's pleasure is not justified.
> > > > >
> > > > > Andre, if you'd like to attend the U-Boot contributor call in an hour,
> > > > > please do.
> > > > >
> > > > > https://bit.ly/3bFvwA1:
> > > > >
> > > > > >
> > > > > > This, largely, is why I still don't understand or agree with the
> > > > > > direction this series is taking platforms that currently use
> > > > > > CONFIG_OF_BOARD=y today.
> > > > >
> > > > > I am not sure what else to do at this point. For real boards, there
> > > > > has to be some base devicetree somewhere that is put into the
> > > > > firmware.
> > > >
> > > > Yes, there is.  It's in the firmware on the hardware.  That's where it
> > > > lives.
> > > >
> > > > > Just because it changes at runtime does not change that
> > > > > fact. So we can inject any DT into the firmware and the same
> > > > > transformations should happen. We just need to have the same one as
> > > > > everyone else uses.
> > > >
> > > > I think you're missing the point here still.  The DT lives IN the
> > > > firmware.  In that an official dts for that firmware exists somewhere,
> > > > I gather it's not public, because it doesn't have to be.
> > >
> > > That was my question to François a while back and I gathered from the
> > > answer that everything is public / open-source.
> >
> > We already know every DT-using platform doesn't have public DTS files,
> > there's the broadcom platform that was talked about an iteration or
> > three back.
> >
> > > Also this is just copied from Linux, which I understand you were
> > > comfortable with.
> >
> > I also said when the custodian doesn't object.
> 
> So what is the fallback? Another empty tree?

As v7 stands yes.  But I'm still drafting my reply to the first patch in
the series.

> > > If it isn't public, why do we have the board in U-Boot? If one board
> > > is public and the other isn't, we should only care about the public
> > > board, IMO. I hope I just have the wrong end of the stick here.
> >
> > I'm elaborating on this in a draft right now still, but we support it
> > because it works?  That's part of the point of device trees, the
> > information gets provided at run time.
> 
> We cannot support that stuff in mainline. It is up to the maintainer
> to keep things working.

I don't understand.  What can't we support in mainline anymore?  As
Andre noted, you implement versus bindings.

-- 
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/20211207/a45339c2/attachment.sig>