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

[Simon Glass]

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

What all this is showing for me is how murky some of these platforms
are. It has been a real education...

Regards,
Simon