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

[François Ozog]

On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini at konsulko.com> wrote:

> On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini at konsulko.com> wrote:
> >
> > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > > A bit late to the party, sorry!
> > > >
> > > > [...]
> > > >
> > > > > >
> > > > > > I really want to see what the binary case looks like since we
> could
> > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > don't
> > > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry
> on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to
> the
> > > > > different components. Binman was one effort there. I feel that
> putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the
> past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > devicetree standard, like the /chosen node but with less history.
> We
> > > > > should sacrifice efficiency, expedience and expandability on the
> altar
> > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> > > > > for its own purposes, as well as for booting the OS. I am not
> saying
> > > > > it always has to have those properties, but with existing features
> > > > > like verified boot, SPL as well as complex firmware images where
> > > > > U-Boot needs to be able to find things in the image, it is
> essential.
> > > > > So let's just assume that we need this everywhere, since we
> certainly
> > > > > need it in at least some places.
> > > > >
> > > > > (stop reading here if you disagree, because nothing below will make
> > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > OF_CONTROL :-)
> > > >
> > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> > > > that to the DTs that are copied over from linux isn't imho.  There
> are
> > > > various reasons for that.  First of all syncing device trees is a
> huge
> > > pain
> > > > and that's probably one of the main reasons our DTs are out of sync
> for a
> > > > large number of boards.
> > >
> > > This re-sync is only a pain because:
> > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > >    NOT SUPPOSED TO.
> > > 2. DTS files are getting closer to being the super stable API that has
> > >    been promised now that there's validation tools.
> > >
> > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > sync, every release.  Others like NXP are violating rule #1.
> >
> > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > changing,
> > at least for the SystemReady boards.
>
> I'd really like to see some progress (as would the other non-NXP folks
> working on NXP SoCs) in that regard.
>
> > > Still
> > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > need to cycle back to the one you and I talked about on IRC a while
> > > back, I bet it's another node name dash changed to underbar).
> > >
> > > > The point is this was fine in 2011 were we had SPL only,  but the
> reality
> > > > today is completely different.  There's previous stage boot loaders
> (and
> > > > enough cases were vendors prefer those over SPL).  If that bootloader
> > > needs
> > > > to use it's own device tree for whatever reason,  imposing
> restrictions
> > > on
> > > > it wrt to the device tree it has to include,  and require them to
> have
> > > > knowledge of U-Boot and it's internal config mechanism makes no
> sense not
> > > > to mention it doesn't scale at all.
> > >
> > > If you are passing the full device tree around, a few more
> > > nodes/properties aren't going to make the situation worse.  If we're
> > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > the line, especially since if we wait another 6 months it'll be a 62
> > > kilobyte file coming in from Linux instead.
> >
> > This is not about size but about firmware supply chain organization.
>
> That's great since it means we just need the bindings reviewed then
> everyone can pass whatever everyone else needs.
>
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"),
> we
> > > > > have binman definitions, etc. So we need a way to overlay those
> things
> > > > > into the DT. We already support this for in-tree DTs, so IMO this
> is
> > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > discoverability and documentation, anyway. That is this series.
> > > >
> > > > Again, the board might decide for it's own reason to provide it's own
> > > DT.
> > > > IMHO U-Boot must be able to cope with that and asking DTs to be
> included
> > > in
> > > > U-Boot source is not the right way to do that,  not to mention cases
> were
> > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > from
> > > > it's flash).
> > > >
> > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > and worried about step 3)
> > > > >
> > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > flow only, or boards that sometimes use a flow) which need the DT
> to
> > > > > come from a prior stage. How to handle that? IMO that is only
> going to
> > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > business.
> > > >
> > > > And that's exactly why we have to come up with something that scales,
> > > without
> > > > having to add a bunch of unusable DTs in U-Boot.
> > >
> > > Both of these are solved by having our bindings reviewed and upstreamed
> > > and then what we need included in the authoritative dts files.
> > >
> > There shall be authoritative System Device Trees as vendors are working
> on.
> > Those System Device Trees cover all aspects of a board, not just the
> > Cortex-A part that U-Boot cares about.
> > Out of those system device trees, a tool (lopper) is going to carve out
> the
> > "authoritative dts for the cortex-A".
> > Essentially, that carve out will correspond to what would come out of
> Linux.
>
> s/Linux/software/
>
> > This scheme will not be generalized, just adopted by vendors on some
> > boards.
> > DT for those board become part of the OS ABI (meaning, the driver
> > developper is constrained).
>
> OK?  And is going to pick and choose which valid bindings to implement?
> Or is it going to provide half a node for Linux?  No?  I assume no.  So
> it will also provide whatever bindings we've upstreamed and say need to
> be passed.
>
Until we can agree on a better scheme, Linux will server as the basis for
most of the bindings.
Some projects, like TF-A maintain their own bindings specifications. I
guess U-Boot shall do the same.
The U-Boot DT (for properties or whatever purpose) can be stored in a
various of U-Boot decided ways and as part of the TF-A FIP image in the
ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve
the NF_FW_CONFIG should be part of the blob_list discussion that started a
while ago.
For System Device Tree, the bindings and the master repo will be maintained
in devicetree.org (AFAIK).

>
> --
> Tom
>


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