[PATCH v6 00/25] fdt: Make OF_BOARD a boolean option

[Mark Kettenis]

> Date: Fri, 3 Dec 2021 09:50:44 +0200
> From: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> 
> Hi Mark,
> 
> > > > > >
> 
> [...]
> 
> > > > > > Changes in v6:
> > > > > > - Fix description of OF_BOARD so it refers just to the current state
> > > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees
> > > > > > - Expand the commit message based on comments
> > > > > > - Expand the commit message based on comments
> > > > >
> > > > > You haven’t addressed any concerns expressed on the mailing list.so I am
> > > > > not in favor of this new version either.
> > > > > If you make a version without « fake DTs » as you name them, there are good
> > > > > advances in the documentation and other areas that would be better in
> > > > > mainline….
> > > > > If I am the only one thinking this way and the patch can be accepted, I
> > > > > would love there is a warning in capital letters at the top of the DTS fake
> > > > > files that explains the intent of this fake DT, the possible outcomes of
> > > > > not using the one provided by the platform and the right way of dealing
> > > > > with DTs for the platform.
> > > >
> > > > This is the part that I too am still unhappy about.  I do not want
> > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > We should be able to _remove_ the ones we have, that are not required,
> > > > with doc/board/...rst explaining how to get / view one.  Not adding
> > > > more.
> > > 
> > > So this is a key point for me and the reason I completely disagree
> > > with this approach.  This proposal is working in the *exact* opposite
> > > direction and we'll never be able to get rid of device trees from
> > > U-Boot, even if at some point they move out of the kernel to a
> > > 'common' repo'.  I'll just repeat what I've been saying since v1.
> > > Personally I'd be way happier if we could figure out were the specific
> > > U-Boot config nodes are needed and when are they needed.  Based on
> > > what we figure out we could, pick up the device tree from a previous
> > > state bootloader and fix it up with our special nodes before we start
> > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > that indeed belong in the u-boot tree.
> > 
> > I don't think it makes sense to put stuff in the DT that is specific
> > for U-Boot only to pull it out moments later.  Maybe it does make some
> > sense to do this to pass information between TPL/SPL and U-Boot
> > proper.  But otherwise you can just use global variables...
> 
> Last time we said we don't really have to remove them,  but I get the
> point.

Ah, when I said "pull it out" I meant "read it back"; not "delete it".

> > Now I just ran into an issue on Apple M1 that may have some relevance
> > here.  I'm adding support for power domains and the serial port
> > requires certain power domains to be on.  Since the serial port is
> > initialized in the pre-relocation phase this means that the device
> > tree nodes for the power domain controllers need to have the
> > "u-boot,dm-pre-reloc" property on them.  Otherwise the DM code won't
> > be able to bind the power domain controller driver in this phase and
> > binding the serial port driver itself will fail.  Which makes U-Boot
> > hang without any visible output on the serial console.
> 
> Very relevant indeed.  That's close to what I was afraid of when I said 
> "if we could figure out were the specific U-Boot config nodes are needed 
> and *when* are they needed".  Obviously this is a clear no go, since more
> boards will have similar requirements in the future.
> 
> > 
> > Within the Asahi Linux group we're currently discussing how to solve
> > this.  We could just add the "u-boot,dm-pre-reloc" properties in the
> > device trees that we're going to distribute as part of m1n1 (the
> > "bootloader" than embeds U-Boot).  Or we can write some code that adds
> > those properties to the device tree nodes that are dependencies for
> > the serial port.
> 
> That might make sense for a project like m1n1 were you are dealing with a
> handful of devices,  but I think it's going to be a pain on a larger scale,
> unless of course the bindings are documented in upstream.  In that case we
> could ask previous bootloaders to add them etc.
> 
> > 
> > I don't think the suggestion of applying an overlay embedded in U-Boot
> > would work here.  The code applying the overlay would need to run very
> > early on in the pre-relocation phase.
> 
> Yep it wouldn't
> 
> > We'd also have to include
> > overlays for all the models that Apple offers and pick the right one.
> > And if a new model appears we can no longer just add a new device tree
> > to m1n1.
> > 
> > But maybe there is a case where the overlay approach would make sense...
> 
> I think there is, for example I was thinking of TF-A doing all the hardware init
> and then handover a DTB into u-boot on a register.  In that case U-boot
> could fixup the DTB before initialing the rest of the subsystems and make DM
> happy.  However as you pointed out that's not the case for all boards and
> dealing with this in the early pre-relocation stage is close to
> impossible, so let's drop that.
> 
> 
> Thanks!
> /Ilias
>