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

[Ilias Apalodimas]

Hi Heinrich, 

On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote:
> On 12/3/21 11:27, Mark Kettenis wrote:
> > > 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.

> 
> Applying a devicetree overlay can be implemented in common/board_f.c
> before the first usage of the devicetree to initialize devices (there
> are some that are initialized before relocation).

Thanks for digging this up.  Tbh I misunderstood the original mail from
Mark.  When I read pre-reloc I assumed no C environment was up yet.
However this raises a few questions.
1. The .dtbos will need to be embedded in the u-boot binary since
there's no FS access (or in some cases storage access to begin with)
2. The RAM we have is going to be limited if we want to apply the overlays
before consoles etc are up, since it basically has to happen at some point
near 'fdtdec_setup'
3.Are we are going to need some logic on how to apply the .dtbos? E.g think of
the same hardware with different configuration.  You'll be able to use the
same binary, if you can somehow configure which overlays you want to apply.

Thanks
/Ilias
> 
> > > > 
> > > > 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...
> 
> Linux will silently ignore any node for which it does not have a
> compatible string. So application of an overlay once in U-Boot is
> sufficient.
> 
> Best regards
> 
> Heinrich
> 
> > > 
> > > 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
> > > 
>