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

Wed Oct 27 16:26:08 CEST 2021

On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote:
> Hi trying to reply to all at the same time!
> 
> On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini 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.
> 
> Agree on both, but still this is the reality we have to deal with right now
> 
> > > >
> > > > 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.
> > 
> 
> Size here is not my concern.  If the bindings u-boot expects gets
> upstreamed I am obviously fine with the previous stage bootloader passing
> them over.  What I strongly disagree,  is *demand* the previous stage boot
> loader have knowledge about them if they are not in upstream.

I also agree that bindings MUST be upstreamed for there to be a
reasonable expectation that any other project (or human creating a dts)
be adding them, either statically or any sort of run-time modification
(think memory information, this gets fixed up at run-time often still).

And it may end up being zero "u-boot,FOO" bindings where this is the
case.  Or it may end up being related to secure / verified boot stuff
only.

-- 
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/cd487f42/attachment-0001.sig>