Hi Andre,
On Mon, 6 Dec 2021 at 18:01, Andre Przywara andre.przywara@arm.com wrote:
On Mon, 6 Dec 2021 17:11:52 -0700 Simon Glass sjg@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.
Regards, Simon