On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote:
> On Wed, 27 Oct 2021 at 15:38, Tom Rini <tr...@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 <tr...@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.Yes, this is the de-facto standard since the beginning. > Some projects, like TF-A maintain their own bindings specifications. I And as I keep saying I believe this to be totally wrong. Unless and only unless the TF-A bindings are for TF-A only to care about, and then it's just one-off do what you guys want non-standard stuff. > guess U-Boot shall do the same. No, U-Boot is going to upstream the bindings that we want to have be considered official. > 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. Yes, we'll have to see where things progress about what bindings are needed, and where. > For System Device Tree, the bindings and the master repo will be maintained > in devicetree.org (AFAIK). Interesting, okay. -- Tom
signature.asc
Description: PGP signature
