Hi Tom, On Tue, 7 Dec 2021 at 09:14, Tom Rini <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.
So that's actually worse than Linux. I think that would be a great shame. > > > > > 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. I mean, we don't have to worry about it, nor include the devicetree in U-Boot, etc. It is effectively a downstream board and it's up to the maintainer to worry about it. We cannot use Binman with it anyway, since we don't have the devicetree, so the long-term aims of all this effort are not relevant for that board. So in other words, if Midway doesn't exist in Linux, it doesn't need to existing in U-Boot either. Actually I cannot find Midway in Linux either, so perhaps Andre can clarify that? Regards, Simon
