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

Thu Dec 2 20:00:15 CET 2021

> From: François Ozog <francois.ozog at linaro.org>
> Date: Thu, 2 Dec 2021 19:32:17 +0100
> 
> On Thu, 2 Dec 2021 at 19:15, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> 
>  > From: Ilias Apalodimas <ilias.apalodimas at linaro.org>
>  > Date: Thu, 2 Dec 2021 19:03:46 +0200
>  > 
>  > On Thu, 2 Dec 2021 at 18:38, Tom Rini <trini at konsulko.com> wrote:
>  > >
>  > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote:
>  > > > Hi Simon
>  > > >
>  > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <sjg at chromium.org> a
>  écrit :
>  > > >
>  > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and
>  OF_HOSTFILE so
>  > > > > there are only three ways to obtain a devicetree:
>  > > > >
>  > > > >    - OF_SEPARATE - the normal way, where the devicetree is built
>  and
>  > > > >       appended to U-Boot
>  > > > >    - OF_EMBED - for development purposes, the devicetree is
>  embedded in
>  > > > >       the ELF file (also used for EFI)
>  > > > >    - OF_BOARD - the board figures it out on its own
>  > > > >
>  > > > > The last one is currently set up so that no devicetree is needed
>  at all
>  > > > > in the U-Boot tree. Most boards do provide one, but some don't.
>  Some
>  > > > > don't even provide instructions on how to boot on the board.
>  > > > >
>  > > > > The problems with this approach are documented in another patch
>  in this
>  > > > > series: "doc: Add documentation about devicetree usage"
>  > > > >
>  > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE.
>  Any board
>  > > > > can obtain its devicetree at runtime, even it is has a
>  devicetree built
>  > > > > in U-Boot. This is because U-Boot may be a second-stage
>  bootloader and its
>  > > > > caller may have a better idea about the hardware available in
>  the machine.
>  > > > > This is the case with a few QEMU boards, for example.
>  > > > >
>  > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should
>  be an
>  > > > > option, available with either OF_SEPARATE or OF_EMBED.
>  > > > >
>  > > > > This series makes this change, adding various missing devicetree
>  files
>  > > > > (and placeholders) to make the build work.
>  > > > >
>  > > > > Note: If board maintainers are able to add their own patch to
>  add the
>  > > > > files, some patches in this series can be dropped.
>  > > > >
>  > > > > It also provides a few qemu clean-ups discovered along the way.
>  The
>  > > > > qemu-riscv64_spl problem is fixed.
>  > > > >
>  > > > > [1]
>  > > > >
>  https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>  
>  > > > >
>  > > > > 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...
> 
>  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.
> 
> Does this hint at a bigger issue that DT shall be parsed and handled in the
> U-Boot process way early than it is today?

No it doesn't.  It indicates that it is already parsed and handled
very early on in the U-Boot process, which implies that applying
modifications in U-Boot itself will be a challenge.

> Ilias reported a similar problem with TPM handling where you need to
> discover TPM very early to deal with it.
> There may be one early parse and two scans (one early, one normal
> enumeration)

Serial ports are explicitly handled early on.  I suppose the TPM could
be handled in a similar way if there is a valid reason to do so.  But
in my opinion the TPM is way to complex for doing something like that.

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