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

Wed Oct 27 15:38:40 CEST 2021

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211027/13c783a3/attachment.sig>