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

[Tom Rini]

On Tue, Dec 07, 2021 at 08:07:17AM -0700, Simon Glass wrote:
> Hi Andre,
> 
> On Mon, 6 Dec 2021 at 18:01, Andre Przywara <andre.przywara at arm.com> 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.
> 
> What, there are two boards? How was I supposed to know that?
> 
> Where do the devicetree files come from? I was assuming it was Linux,
> but are they not even there? It doesn't really matter what the tree
> is, but I assume the base tree must come from *somewhere*. We want to
> sync that to U-Boot.
> 
> Please add a doc/board/highbank.rts or similar.
> 
> I think you have missed a lot of discussion about all this.

I think you missed where it was explained already that the DTS files
come from the hardware.

-- 
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/3e7ca67d/attachment.sig>