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

[François Ozog]

Hi

On Tue, 7 Dec 2021 at 18:14, Andre Przywara <andre.przywara at arm.com> wrote:

> On Tue, 7 Dec 2021 09:21:40 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
> Hi Simon,
>
> > Hi Tom,
> >
> > On Tue, 7 Dec 2021 at 09:14, Tom Rini <trini at konsulko.com> 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 <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.
> >
> > 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.
>
> I think the point is that U-Boot here is not the main firmware per-se,
> but just a bootloader, part of a whole firmware package. It *consumes* the
> DT provided by the former firmware, and hands it on to the loaded
> application (Linux, *BSD, you name it).
> The U-Boot binary is just another blob living in one of the SPI flash
> partitions, next to the DTB.
> There is no need for U-Boot to provide packaging of any kind. I never
> thought that would be something that U-Boot was opposed against?
>
> > So in other words, if Midway doesn't exist in Linux, it doesn't need
> > to existing in U-Boot either.
>
> Why does Midway not "exist in Linux"? Does this break down to: "if a board
> does not have a .dts file in the Linux kernel tree, it is not supported"?
> (Ignoring all the "real hardware(TM)" that uses ACPI for a moment, and
> QEMU and kvmtool and Xen, ...)
> To have Linux working, you would need to have your peripherals supported
> by drivers, and provide DT nodes complying to the documented bindings for
> those drivers. In reality this mostly boils down to have the SoC
> peripherals supported, and not having exotic chips on the board, but then
> Linux would just work, even if the .dts files are not merged into the tree.
> Granted, you should send your DT, but this is not really a technical
> necessity.
>
> > Actually I cannot find Midway in Linux either, so perhaps Andre can
> > clarify that?
>
> I don't want to give you funny ideas, but it's ecx-2000.dts in
> arch/arm/boot/dts ;-) But that really doesn't matter, the .dts files are
> just there for documentation purposes, have ever been, the actual DT comes
> from the SPI flash, loaded into DRAM by the BMC.
> So please do not include ecx-2000.dts in v8 ;-)
>
> I think similar things applies to a number of boards. For instance the
SolidRun Honeycomb board is based on an NXP chip that has a Serdes. U-Boot
needs to see the SerDes to properly configure it and make it either PCI or
MDIO devices for Linux. So the board DTB that U-Boot receives contains
SerDes nodes. It should remove it and add necessary PCI or MDIO nodes for
the operating system. The way to achieve this is to be decided board per
board:
- You can have a second device tree that you will hand over to the OS,
- you can apply an overlay,
- you can apply fixups to the one provided by the previous firmware.
On the Honeycomb, compile options (SERDES=SD1_SD2_SD3) configures the hw
properly and hands over the right DTB nodes to the OS.
Bottom line, you should not copy the Linux DTS of honeycomb into U-Boot too.

> Cheers,
> Andre
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog