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

[Simon Glass]

Hi François,

On Thu, 28 Oct 2021 at 10:26, François Ozog  wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 17:44, Simon Glass  a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 08:50, François Ozog  wrote:
>> >
>> > Hi Simon
>> >
>> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass  a écrit :
>> >>
>> >> Hi François,
>> >>
>> >> On Thu, 28 Oct 2021 at 02:21, François Ozog  
>> >> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass  a écrit :
>> >> >>
>> >> >> Hi Ilias,
>> >> >>
>> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> >>  wrote:
>> >> >> >
>> >> >> > Hi Simon,
>> >> >> >
>> >> >> > A bit late to the party, sorry!
>> >> >>
>> >> >> (Did you remember the beer? I am replying to this but I don't think it
>> >> >> is all that helpful for me to reply to a lot of things on this thread,
>> >> >> since I would not be adding much to my cover letter and patches)
>> >> >>
>> >> >> >
>> >> >> > [...]
>> >> >> >
>> >> >> > > >
>> >> >> > > > 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.
>> >> >> > 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 

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

[Simon Glass]

Hi Ilias,

On Mon, 1 Nov 2021 at 05:05, Ilias Apalodimas
 wrote:
>
> Hi Simon,
>
> On Thu, 28 Oct 2021 at 05:51, Simon Glass  wrote:
> >
> > Hi Ilias,
> >
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >  wrote:
> > >
> > > Hi Simon,
> > >
> > > A bit late to the party, sorry!
> >
> > (Did you remember the beer?
>
> We'll probably need something stronger to sort this out :)

Yes I agree!

>
> > I am replying to this but I don't think it
> > is all that helpful for me to reply to a lot of things on this thread,
> > since I would not be adding much to my cover letter and patches)
> >
> > >
> > > [...]
> > >
> > > > >
> > > > > 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.
> > > 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.
> >
> > I think the solution here may be the binman image packer. It works
> > from a description of the image (i.e. is data-driver) and can collect
> > all the pieces together. The U-Boot properties (and the ones required
> > by TF-A, etc.) can be added at package time.
>
> I am not sure I am following you here or why binman is relevant to
> this discussion.  If the boot process doesn't require a FIP (e.g  SPL
> + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
> using binman makes a lot of sense.  If the boot process is TF-A ->
> U-Boot and requires a FIP, TF-A has it's own set of tools for
> preparing that [1] [2] ,  why would we want to teach binman 

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

[François Ozog]

On Tue, 2 Nov 2021 at 11:07, Michael Walle  wrote:

> Hi,
>
> > On Thu, 28 Oct 2021 at 05:51, Simon Glass  wrote:
> > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > >  wrote:
>
> ..
>
> > > Linux actually doesn't care if the U-Boot properties are in the tree,
> > > so long as we have proper bindings. My point here is we only need
> > > either:
> > >
> > > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > > b. two devicetrees, one for use in firmware and one for passing to
> Linux
> > >
> > > We don't need to separate out the U-Boot properties into a second (or
> > > third) devicetree. There just isn't any point.
> >
> > Again if we are talking about bindings that are upstream in the spec,
> > then we agree.  Depending on the SRAM limitation we can even do (a).
> > If the vendor messes up the DT backwards compatibility then we can do
> > (b).  If you expect TF-A and FIP to go pick up the special bindings
> > U-Boot needs, then we disagree.
>
> *puts developer at board vendor hat on* Sometimes (personally I'd say
> usually) it isn't possible to have a backwards compatible tree. Also,
> like it or not, in the device tree there *are* configuration options
> which are not hardware dependent (eg. internal ethernet connection on
> the ls1028a).

Are you referring to DPAA2 configuration to create the ethernet port itself
?
This is indeed configuration. There are many ways to handle those ones.
As well as SerDes configuration to make PCI lanes or MDIO lanes.
Yet the two are different in nature: SerDes configuration must match board
layout,
so it is about "no user choice" configuration. This configuration could be
statically
defined and attached with the board. But it there is a SoM with a carrier
board,
we may need to compose that at runtime for development, or make it static
build
for product packaging.
DPAA2 configuration is user choice driven. Those choices can be merged in
the DT
to be passed to the OS at runtime. There are multiple ways to deal with
that, from DT overlays
to U-Boot DPAA2 command line extensions that would inject the DT necessary
nodes.

> So a vendor doesn't necessarily need to "mess things up"
> to need (b). And as you know, my point is, that this device tree has
> to come from the distribution, it must not be compiled in into the
> firmware.
>
 I wouldn't bet that all distro providers will always come with a DT...

>
> I feel like I've repeated this far too many times. Therefore, this
> will be my last comment about it and I would really like to see that
> this - very real - scenario is treated as a valid use case and will be
> supported in your systemready vision.
>
I have been building (shared it on the list) a deck to go into those
details. I am almost ready to talk to it.

>
> -michael
>


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

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

[Michael Walle]

Hi,

> On Thu, 28 Oct 2021 at 05:51, Simon Glass  wrote:
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >  wrote:

..

> > Linux actually doesn't care if the U-Boot properties are in the tree,
> > so long as we have proper bindings. My point here is we only need
> > either:
> >
> > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > b. two devicetrees, one for use in firmware and one for passing to Linux
> >
> > We don't need to separate out the U-Boot properties into a second (or
> > third) devicetree. There just isn't any point.
> 
> Again if we are talking about bindings that are upstream in the spec,
> then we agree.  Depending on the SRAM limitation we can even do (a).
> If the vendor messes up the DT backwards compatibility then we can do
> (b).  If you expect TF-A and FIP to go pick up the special bindings
> U-Boot needs, then we disagree.

*puts developer at board vendor hat on* Sometimes (personally I'd say
usually) it isn't possible to have a backwards compatible tree. Also,
like it or not, in the device tree there *are* configuration options
which are not hardware dependent (eg. internal ethernet connection on
the ls1028a). So a vendor doesn't necessarily need to "mess things up"
to need (b). And as you know, my point is, that this device tree has
to come from the distribution, it must not be compiled in into the
firmware.

I feel like I've repeated this far too many times. Therefore, this
will be my last comment about it and I would really like to see that
this - very real - scenario is treated as a valid use case and will be
supported in your systemready vision.

-michael

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

[Ilias Apalodimas]

Hi Simon,

On Thu, 28 Oct 2021 at 05:51, Simon Glass  wrote:
>
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>  wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer?

We'll probably need something stronger to sort this out :)

> I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > 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.
> > 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.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.

I am not sure I am following you here or why binman is relevant to
this discussion.  If the boot process doesn't require a FIP (e.g  SPL
+ U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
using binman makes a lot of sense.  If the boot process is TF-A ->
U-Boot and requires a FIP, TF-A has it's own set of tools for
preparing that [1] [2] ,  why would we want to teach binman FIP
packaging? And if we do are you willing to keep it up to date with
everything they come up with? IOW packaging the firmware is not
U-Boot's responsibility, it's the vendors.  Why should he not be able
to choose FIP? (ST already changed that in u-boot btw).

>
> If you think about it, it doesn't matter 

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

[François Ozog]

Hi Simon

Le jeu. 28 oct. 2021 à 17:44, Simon Glass  a écrit :

> Hi François,
>
> On Thu, 28 Oct 2021 at 08:50, François Ozog 
> wrote:
> >
> > Hi Simon
> >
> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass  a écrit :
> >>
> >> Hi François,
> >>
> >> On Thu, 28 Oct 2021 at 02:21, François Ozog 
> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass  a écrit
> :
> >> >>
> >> >> Hi Ilias,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> >>  wrote:
> >> >> >
> >> >> > Hi Simon,
> >> >> >
> >> >> > A bit late to the party, sorry!
> >> >>
> >> >> (Did you remember the beer? I am replying to this but I don't think
> it
> >> >> is all that helpful for me to reply to a lot of things on this
> thread,
> >> >> since I would not be adding much to my cover letter and patches)
> >> >>
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > > >
> >> >> > > > 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.
> >> >> > 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.
> >> >>
> >> >> I think the solution here may be the binman image packer. It works
> >> >> from a description of the image (i.e. is data-driver) and can collect
> 

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

[Simon Glass]

Hi François,

On Thu, 28 Oct 2021 at 08:50, François Ozog  wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 16:30, Simon Glass  a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 02:21, François Ozog  wrote:
>> >
>> > Hi Simon,
>> >
>> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass  a écrit :
>> >>
>> >> Hi Ilias,
>> >>
>> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >>  wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > A bit late to the party, sorry!
>> >>
>> >> (Did you remember the beer? I am replying to this but I don't think it
>> >> is all that helpful for me to reply to a lot of things on this thread,
>> >> since I would not be adding much to my cover letter and patches)
>> >>
>> >> >
>> >> > [...]
>> >> >
>> >> > > >
>> >> > > > 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.
>> >> > 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.
>> >>
>> >> I think the solution here may be the binman image packer. It works
>> >> from a description of the image (i.e. is data-driver) and can collect
>> >> all the pieces together. The U-Boot properties (and the ones required
>> >> by TF-A, etc.) can be added at package time.
>> >>
>> >> If you think about it, it doesn't matter what properties are in the DT
>> >> that is put into the firmware 

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

[François Ozog]

Hi Simon

Le jeu. 28 oct. 2021 à 16:30, Simon Glass  a écrit :

> Hi François,
>
> On Thu, 28 Oct 2021 at 02:21, François Ozog 
> wrote:
> >
> > Hi Simon,
> >
> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass  a écrit :
> >>
> >> Hi Ilias,
> >>
> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >>  wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > A bit late to the party, sorry!
> >>
> >> (Did you remember the beer? I am replying to this but I don't think it
> >> is all that helpful for me to reply to a lot of things on this thread,
> >> since I would not be adding much to my cover letter and patches)
> >>
> >> >
> >> > [...]
> >> >
> >> > > >
> >> > > > 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.
> >> > 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.
> >>
> >> I think the solution here may be the binman image packer. It works
> >> from a description of the image (i.e. is data-driver) and can collect
> >> all the pieces together. The U-Boot properties (and the ones required
> >> by TF-A, etc.) can be added at package time.
> >>
> >> If you think about it, it doesn't matter what properties are in the DT
> >> that is put into the firmware image. TF-A, for example, is presumably
> >> reading a devicetree from flash, so what does it care if it has some
> >> U-Boot properties in it?
> >
> >
> > I am going to change my position in all mail threads I 

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

[Tom Rini]

On Thu, Oct 28, 2021 at 12:00:44AM +0200, François Ozog wrote:
> Hi Tom
> 
> Le mer. 27 oct. 2021 à 21:06, Tom Rini  a écrit :
> 
> > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > > Hi Mark,
> > >
> > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis 
> > wrote:
> > >
> > > > > From: François Ozog 
> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> > > > >
> > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini 
> > wrote:
> > > > > > > >
> > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini 
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> > wrote:
> > > > > > > > > > > Hi François,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > > francois.o...@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon
> > > > > > > > > > > >
> > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > > > s...@chromium.org>
> > > > > > a écrit :
> > > > > > > > > > > >>
> > > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > > > tr...@konsulko.com>
> > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > > > wrote:
> > > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > > s...@chromium.org> wrote:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 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
> > at
> > > > [1].
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 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.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Adding device trees that are never used sounds
> > like a
> > > > > > hack to me.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> > the
> > > > fly
> > > > > > based on
> > > > > > > > > > > >> > > command line parameters, and the device tree you
> > put
> > > > in
> > > > > > this series
> > > > > > > > > > > >> > > has various hardcoded  values which
> > normally
> > > > do
> > > > > > not show up
> > > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I am not sure I understand the whole point of
> > this.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > I am also confused and do not like the idea of
> > adding
> > > > > > device trees for
> > > > > > 

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

[Simon Glass]

Hi François,

On Thu, 28 Oct 2021 at 02:21, François Ozog  wrote:
>
> Hi Simon,
>
> Le jeu. 28 oct. 2021 à 04:51, Simon Glass  a écrit :
>>
>> Hi Ilias,
>>
>> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>>  wrote:
>> >
>> > Hi Simon,
>> >
>> > A bit late to the party, sorry!
>>
>> (Did you remember the beer? I am replying to this but I don't think it
>> is all that helpful for me to reply to a lot of things on this thread,
>> since I would not be adding much to my cover letter and patches)
>>
>> >
>> > [...]
>> >
>> > > >
>> > > > 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.
>> > 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.
>>
>> I think the solution here may be the binman image packer. It works
>> from a description of the image (i.e. is data-driver) and can collect
>> all the pieces together. The U-Boot properties (and the ones required
>> by TF-A, etc.) can be added at package time.
>>
>> If you think about it, it doesn't matter what properties are in the DT
>> that is put into the firmware image. TF-A, for example, is presumably
>> reading a devicetree from flash, so what does it care if it has some
>> U-Boot properties in it?
>
>
> I am going to change my position in all mail threads I participate.
> I was trying to make patches relevant in the future and conceptually clean. 
> That may not be the most effective position: I should just care about Linaro 
> and its members being able to implement SystemReady concepts.
>
>
> If you mandate U-Boot has nodes in the device 

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

[François Ozog]

Hi Simon,

Le jeu. 28 oct. 2021 à 04:51, Simon Glass  a écrit :

> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>  wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer? I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > 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.
> > 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.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
>
> If you think about it, it doesn't matter what properties are in the DT
> that is put into the firmware image. TF-A, for example, is presumably
> reading a devicetree from flash, so what does it care if it has some
> U-Boot properties in it?


I am going to change my position in all mail threads I participate.
I was trying to make patches relevant in the future and conceptually clean.
That may not be the most effective position: I should just care about
Linaro and its members being able to implement SystemReady concepts.


If you mandate U-Boot has nodes in the device tree passed to the OS, we can
put DT fragment in  the nt_fw_config section of the fip and merge it at
boot time. So there is a solution compatible with SystemReady.

If you 

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

[Simon Glass]

Hi Ilias,

On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
 wrote:
>
> Hi Simon,
>
> A bit late to the party, sorry!

(Did you remember the beer? I am replying to this but I don't think it
is all that helpful for me to reply to a lot of things on this thread,
since I would not be adding much to my cover letter and patches)

>
> [...]
>
> > >
> > > 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.
> 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.

I think the solution here may be the binman image packer. It works
from a description of the image (i.e. is data-driver) and can collect
all the pieces together. The U-Boot properties (and the ones required
by TF-A, etc.) can be added at package time.

If you think about it, it doesn't matter what properties are in the DT
that is put into the firmware image. TF-A, for example, is presumably
reading a devicetree from flash, so what does it care if it has some
U-Boot properties in it?

As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
so I think this can be dealt with.

>
> >
> > 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 

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

[François Ozog]

Hi Tom

Le mer. 27 oct. 2021 à 21:06, Tom Rini  a écrit :

> On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis 
> wrote:
> >
> > > > From: François Ozog 
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> > > >
> > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini 
> wrote:
> > > > > > >
> > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini 
> > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> wrote:
> > > > > > > > > > Hi François,
> > > > > > > > > >
> > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > francois.o...@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > > s...@chromium.org>
> > > > > a écrit :
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > > tr...@konsulko.com>
> > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > > wrote:
> > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > s...@chromium.org> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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
> at
> > > [1].
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Adding device trees that are never used sounds
> like a
> > > > > hack to me.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> the
> > > fly
> > > > > based on
> > > > > > > > > > >> > > command line parameters, and the device tree you
> put
> > > in
> > > > > this series
> > > > > > > > > > >> > > has various hardcoded  values which
> normally
> > > do
> > > > > not show up
> > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I am not sure I understand the whole point of
> this.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am also confused and do not like the idea of
> adding
> > > > > device trees for
> > > > > > > > > > >> > platforms that are capable of and can / do have a
> device
> > > > > tree to give us
> > > > > > > > > > >> > at run time.
> > > > > > > > > > >>
> > > > > > > > > > >> (I'll just reply to this one email, since the same
> points
> > > > > applies to
> > > > > > > > > > >> all replies I think)
> > > > > > > > > > >>
> > > 

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

[Mark Kettenis]

> From: Simon Glass 
> Date: Wed, 27 Oct 2021 09:24:25 -0600
> 
> Hi Mark,
> 
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis  wrote:
> >
> > > From: François Ozog 
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > In my view U-Boot shall be able to leverage device tree format
> > > (source and binary) to store its own data.  When you say "the"
> > > DT, I always think this is "the" DT that is passed to OS and in
> > > "that" DT, there should be no U-Boot entries.
> >
> > Why not?  As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present.  The propertiesand
> > nodes will be simply ignored by the OS.
> >
> > OpenBSD will print:
> >
> >   "binman" not configured
> >
> > for the binman node that some of the U-Boot board targets now have,
> > but it doesn't really make a difference.  If there is a proper binding
> > for that node, I could simply filter it out.  Or we have U-Boot filter
> > it out before the DT gets passed along like Tom suggests.
> 
> Just on that point, I believe the binman falls into the same bucket
> that Tom is talking about here, in that it should be a standard
> binding. Ideally I would like this to become a standard format so that
> anything in firmware can use it to find stuff. I believe it is a good
> and extensible way to describe the structure of firmware across all
> projects.

Oh, I agree that it is a reasonable thing to have a description of the
structure of the firmware in the device tree.

> Does "not configured" mean that it did not find the compatible string?
> We could add one of those, for now, perhaps.

"not configured" just means that no device driver attached to the
node.  Usually that is because we don't have a device driver for the
device corresponding to the node yet.  But in the case of the "binman"
node it doesn't really make sense for a device driver to attach.  In
such a case we tend to filter out the node such that the "not
configured" line isn't printed.  That can be done either by name or by
compatible string.  So an "official" binding would help here and it
should either use a standardized name (that shouldn't be used for
other purposes then) or it should use defined a compatible string.

Anyway, this is not really critical.  I just brought it up to
illustrate that such nodes are mostly harmless.

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

[Tom Rini]

On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> Hi Mark,
> 
> On Wed, 27 Oct 2021 at 17:10, Mark Kettenis  wrote:
> 
> > > From: François Ozog 
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini 
> > wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > > Hi François,
> > > > > > > > >
> > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > francois.o...@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > s...@chromium.org>
> > > > a écrit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > tr...@konsulko.com>
> > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > wrote:
> > > > > > > > > >> > > Hi Simon,
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > s...@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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 at
> > [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the
> > fly
> > > > based on
> > > > > > > > > >> > > command line parameters, and the device tree you put
> > in
> > > > this series
> > > > > > > > > >> > > has various hardcoded  values which normally
> > do
> > > > not show up
> > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confused and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that are capable of and can / do have a device
> > > > tree to give us
> > > > > > > > > >> > at run time.
> > > > > > > > > >>
> > > > > > > > > >> (I'll just reply to this one email, since the same points
> > > > applies to
> > > > > > > > > >> all replies I think)
> > > > > > > > > >>
> > > > > > > > > >> I have been thinking about this and discussing it with
> > people
> > > > for a
> > > > > > > > > >> few months now. I've been signalling a change like this
> > for
> > > > over a
> > > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > > with Linaro
> > > > > > > > > >> people. I sent a patch 

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

[François Ozog]

Hi Tom

Le mer. 27 oct. 2021 à 20:06, Tom Rini  a écrit :

> On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis 
> wrote:
> > >
> > > > From: François Ozog 
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> > > >
> > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini 
> wrote:
> > > > > > >
> > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini 
> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> wrote:
> > > > > > > > > > Hi François,
> > > > > > > > > >
> > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > francois.o...@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> s...@chromium.org>
> > > > > a écrit :
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> tr...@konsulko.com>
> > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > s...@chromium.org> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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
> at [1].
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Adding device trees that are never used sounds
> like a
> > > > > hack to me.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> the fly
> > > > > based on
> > > > > > > > > > >> > > command line parameters, and the device tree you
> put in
> > > > > this series
> > > > > > > > > > >> > > has various hardcoded  values which
> normally do
> > > > > not show up
> > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I am not sure I understand the whole point of
> this.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am also confused and do not like the idea of
> adding
> > > > > device trees for
> > > > > > > > > > >> > platforms that are capable of and can / do have a
> device
> > > > > tree to give us
> > > > > > > > > > >> > at run time.
> > > > > > > > > > >>
> > > > > > > > > > >> (I'll just reply to this one email, since the same
> points
> > > > > applies to
> > > > > > > > > > >> all replies I think)
> > > > > > > > > > >>
> > > > > > > > > > >> I have been thinking about this and discussing it
> with people
> 

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

[Tom Rini]

On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> Hi Mark,
> 
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis  wrote:
> >
> > > From: François Ozog 
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > > Hi François,
> > > > > > > > >
> > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > francois.o...@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass 
> > > > > > > > > > 
> > > > a écrit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > > > >> > > Hi Simon,
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > s...@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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 at 
> > > > > > > > > >> > > > [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the 
> > > > > > > > > >> > > fly
> > > > based on
> > > > > > > > > >> > > command line parameters, and the device tree you put in
> > > > this series
> > > > > > > > > >> > > has various hardcoded  values which normally 
> > > > > > > > > >> > > do
> > > > not show up
> > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confused and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that are capable of and can / do have a device
> > > > tree to give us
> > > > > > > > > >> > at run time.
> > > > > > > > > >>
> > > > > > > > > >> (I'll just reply to this one email, since the same points
> > > > applies to
> > > > > > > > > >> all replies I think)
> > > > > > > > > >>
> > > > > > > > > >> I have been thinking about this and discussing it with 
> > > > > > > > > >> people
> > > > for a
> > > > > > > > > >> few months now. I've 

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

[Tom Rini]

On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote:
> On 10/27/21 16:55, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
> > 
> > [snip]
> > > One passed to U-Boot for fixups and further passed to the OS. This
> > > devicetree may originate from a prior boot stage, from a file loaded by
> > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
> > 
> > I assume systemd-boot is implementing the same logic that extlinux.conf
> > has used for forever, yes?
> 
> It is loading the file and then calls U-Boot's implementation of the EFI
> Device Tree Fixup Protocol for fixups before passing the device-tree to the
> OS.

So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK.

> > > This devicetree will not contain any U-Boot specific information.
> > 
> > To repeat, it must only have official bindings, yes, regardless of what
> > project they come from.
> > 
> 
> Don't expect prior firmware stages to provide any U-Boot specific stuff
> whatever official or non-official U-Boot specific bindings exist.

Failure to implement official bindings may result in failure to boot,
which would be pretty silly.

-- 
Tom


signature.asc
Description: PGP signature

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

[François Ozog]

Hi Mark,

On Wed, 27 Oct 2021 at 17:10, Mark Kettenis  wrote:

> > From: François Ozog 
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > > > >
> > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini 
> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > Hi François,
> > > > > > > >
> > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > francois.o...@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> s...@chromium.org>
> > > a écrit :
> > > > > > > > >>
> > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > >>
> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> tr...@konsulko.com>
> > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > > > >> > > Hi Simon,
> > > > > > > > >> > >
> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > s...@chromium.org> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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 at
> [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > hack to me.
> > > > > > > > >> > >
> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the
> fly
> > > based on
> > > > > > > > >> > > command line parameters, and the device tree you put
> in
> > > this series
> > > > > > > > >> > > has various hardcoded  values which normally
> do
> > > not show up
> > > > > > > > >> > > in hand-written dts files.
> > > > > > > > >> > >
> > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > >> >
> > > > > > > > >> > I am also confused and do not like the idea of adding
> > > device trees for
> > > > > > > > >> > platforms that are capable of and can / do have a device
> > > tree to give us
> > > > > > > > >> > at run time.
> > > > > > > > >>
> > > > > > > > >> (I'll just reply to this one email, since the same points
> > > applies to
> > > > > > > > >> all replies I think)
> > > > > > > > >>
> > > > > > > > >> I have been thinking about this and discussing it with
> people
> > > for a
> > > > > > > > >> few months now. I've been signalling a change like this
> for
> > > over a
> > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > with Linaro
> > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > hope it is
> > > > > > > > >> not a surprise!
> > > > > > > > >>
> > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > U-Boot, to
> > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > OF_BOARD,
> > > > > > > > >> BINMAN_STANDALONE_FDT 

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

[Simon Glass]

Hi Mark,

On Wed, 27 Oct 2021 at 09:11, Mark Kettenis  wrote:
>
> > From: François Ozog 
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > > > >
> > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > Hi François,
> > > > > > > >
> > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > francois.o...@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass 
> > > a écrit :
> > > > > > > > >>
> > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > >>
> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > > >> > > Hi Simon,
> > > > > > > > >> > >
> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > s...@chromium.org> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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 at [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > hack to me.
> > > > > > > > >> > >
> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > > based on
> > > > > > > > >> > > command line parameters, and the device tree you put in
> > > this series
> > > > > > > > >> > > has various hardcoded  values which normally do
> > > not show up
> > > > > > > > >> > > in hand-written dts files.
> > > > > > > > >> > >
> > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > >> >
> > > > > > > > >> > I am also confused and do not like the idea of adding
> > > device trees for
> > > > > > > > >> > platforms that are capable of and can / do have a device
> > > tree to give us
> > > > > > > > >> > at run time.
> > > > > > > > >>
> > > > > > > > >> (I'll just reply to this one email, since the same points
> > > applies to
> > > > > > > > >> all replies I think)
> > > > > > > > >>
> > > > > > > > >> I have been thinking about this and discussing it with people
> > > for a
> > > > > > > > >> few months now. I've been signalling a change like this for
> > > over a
> > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > with Linaro
> > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > hope it is
> > > > > > > > >> not a surprise!
> > > > > > > > >>
> > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > U-Boot, to
> > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > OF_BOARD,
> > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > Between
> > > > > > > > >> Ilias' 

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

[Mark Kettenis]

> From: François Ozog 
> Date: Wed, 27 Oct 2021 15:15:01 +0200
> 
> Hi,
> 
> On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> 
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.o...@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass 
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > s...@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > 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 at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > 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.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded  values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > 

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

[Heinrich Schuchardt]

On 10/27/21 16:55, Tom Rini wrote:

On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:

[snip]

One passed to U-Boot for fixups and further passed to the OS. This
devicetree may originate from a prior boot stage, from a file loaded by
U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.


I assume systemd-boot is implementing the same logic that extlinux.conf
has used for forever, yes?


It is loading the file and then calls U-Boot's implementation of the EFI 
Device Tree Fixup Protocol for fixups before passing the device-tree to 
the OS.





This devicetree will not contain any U-Boot specific information.


To repeat, it must only have official bindings, yes, regardless of what
project they come from.



Don't expect prior firmware stages to provide any U-Boot specific stuff 
whatever official or non-official U-Boot specific bindings exist.


Best regards

Heinrich

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

[Tom Rini]

On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:

[snip]
> One passed to U-Boot for fixups and further passed to the OS. This
> devicetree may originate from a prior boot stage, from a file loaded by
> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.

I assume systemd-boot is implementing the same logic that extlinux.conf
has used for forever, yes?

> This devicetree will not contain any U-Boot specific information.

To repeat, it must only have official bindings, yes, regardless of what
project they come from.

-- 
Tom


signature.asc
Description: PGP signature

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

[Tom Rini]

On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote:
> Hi,
> 
> On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:
> 
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.o...@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass 
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > s...@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > 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 at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > 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.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded  values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > 

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

[Tom Rini]

On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote:
> On Wed, 27 Oct 2021 at 15:38, 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  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.  

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

[Tom Rini]

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  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 

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

[François Ozog]

On Wed, 27 Oct 2021 at 15:38, 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  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

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

[Ilias Apalodimas]

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  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 

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

[Tom Rini]

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  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 

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

[François Ozog]

Hi Tom,

On Wed, 27 Oct 2021 at 14:59, Tom Rini  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.

> 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.

> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files 

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

[Heinrich Schuchardt]

On 10/27/21 15:15, François Ozog wrote:

Hi,

On Wed, 27 Oct 2021 at 14:48, Tom Rini > wrote:


On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
 > Hi all,
 >
 > On Thu, 14 Oct 2021 at 09:28, Tom Rini mailto:tr...@konsulko.com>> wrote:
 > >
 > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
 > > > Hi Tom,
 > > >
 > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini mailto:tr...@konsulko.com>> wrote:
 > > > >
 > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
 > > > > > Hi François,
 > > > > >
 > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog
mailto:francois.o...@linaro.org>> wrote:
 > > > > > >
 > > > > > > Hi Simon
 > > > > > >
 > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass
mailto:s...@chromium.org>> a écrit :
 > > > > > >>
 > > > > > >> Hi Tom, Bin,François,
 > > > > > >>
 > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini
mailto:tr...@konsulko.com>> wrote:
 > > > > > >> >
 > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
wrote:
 > > > > > >> > > Hi Simon,
 > > > > > >> > >
 > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass
mailto:s...@chromium.org>> wrote:
 > > > > > >> > > >
 > > > > > >> > > > 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
at [1].
 > > > > > >> > > >
 > > > > > >> > > > 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.
 > > > > > >> > >
 > > > > > >> > > Adding device trees that are never used sounds
like a hack to me.
 > > > > > >> > >
 > > > > > >> > > For QEMU, device tree is dynamically generated on
the fly based on
 > > > > > >> > > command line parameters, and the device tree you
put in this series
 > > > > > >> > > has various hardcoded  values which
normally do not show up
 > > > > > >> > > in hand-written dts files.
 > > > > > >> > >
 > > > > > >> > > I am not sure I understand the whole point of this.
 > > > > > >> >
 > > > > > >> > I am also confused and do not like the idea of
adding device trees for
 > > > > > >> > platforms that are capable of and can / do have a
device tree to give us
 > > > > > >> > at run time.
 > > > > > >>
 > > > > > >> (I'll just reply to this one email, since the same
points applies to
 > > > > > >> all replies I think)
 > > > > > >>
 > > > > > >> I have been thinking about this and discussing it with
people for a
 > > > > > >> few months now. I've been signalling a change like
this for over a
 > > > > > >> month now, on U-Boot contributor calls and in
discussions with Linaro
 > > > > > >> people. I sent a patch (below) to try to explain
things. I hope it is
 > > > > > >> not a surprise!
 > > > > > >>
 > > > > > >> The issue here is that we need a devicetree in-tree in
U-Boot, to
 > > > > > >> avoid the mess that has been created by
OF_PRIOR_STAGE, OF_BOARD,
 > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
OF_HOSTFILE. Between
 > > > > > >> Ilias' series and this one we can get ourselves on a
stronger footing.
 > > > > > >> 

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

[François Ozog]

Hi,

On Wed, 27 Oct 2021 at 14:48, Tom Rini  wrote:

> On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> > >
> > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > Hi François,
> > > > > >
> > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.o...@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass 
> a écrit :
> > > > > > >>
> > > > > > >> Hi Tom, Bin,François,
> > > > > > >>
> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> wrote:
> > > > > > >> >
> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > >> > > Hi Simon,
> > > > > > >> > >
> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> s...@chromium.org> wrote:
> > > > > > >> > > >
> > > > > > >> > > > 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 at [1].
> > > > > > >> > > >
> > > > > > >> > > > 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.
> > > > > > >> > >
> > > > > > >> > > Adding device trees that are never used sounds like a
> hack to me.
> > > > > > >> > >
> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > > > >> > > command line parameters, and the device tree you put in
> this series
> > > > > > >> > > has various hardcoded  values which normally do
> not show up
> > > > > > >> > > in hand-written dts files.
> > > > > > >> > >
> > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > >> >
> > > > > > >> > I am also confused and do not like the idea of adding
> device trees for
> > > > > > >> > platforms that are capable of and can / do have a device
> tree to give us
> > > > > > >> > at run time.
> > > > > > >>
> > > > > > >> (I'll just reply to this one email, since the same points
> applies to
> > > > > > >> all replies I think)
> > > > > > >>
> > > > > > >> I have been thinking about this and discussing it with people
> for a
> > > > > > >> few months now. I've been signalling a change like this for
> over a
> > > > > > >> month now, on U-Boot contributor calls and in discussions
> with Linaro
> > > > > > >> people. I sent a patch (below) to try to explain things. I
> hope it is
> > > > > > >> not a surprise!
> > > > > > >>
> > > > > > >> The issue here is that we need a devicetree in-tree in
> U-Boot, to
> > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> OF_BOARD,
> > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> Between
> > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> use.
> > > > > > >> For more context:
> > > > > > >>
> > > > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > > > > >>
> > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> adding the
> > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > >> maintainer would prefer there was no special support even for
> booting
> > > > > > >> Linux 

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

[Tom Rini]

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.  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.

> > 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 

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

[Tom Rini]

On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> Hi all,
> 
> On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
> >
> > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > Hi François,
> > > > >
> > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog 
> > > > >  wrote:
> > > > > >
> > > > > > Hi Simon
> > > > > >
> > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a 
> > > > > > écrit :
> > > > > >>
> > > > > >> Hi Tom, Bin,François,
> > > > > >>
> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> > > > > >> >
> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > >> > > Hi Simon,
> > > > > >> > >
> > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass 
> > > > > >> > >  wrote:
> > > > > >> > > >
> > > > > >> > > > 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 at [1].
> > > > > >> > > >
> > > > > >> > > > 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.
> > > > > >> > >
> > > > > >> > > Adding device trees that are never used sounds like a hack to 
> > > > > >> > > me.
> > > > > >> > >
> > > > > >> > > For QEMU, device tree is dynamically generated on the fly 
> > > > > >> > > based on
> > > > > >> > > command line parameters, and the device tree you put in this 
> > > > > >> > > series
> > > > > >> > > has various hardcoded  values which normally do not 
> > > > > >> > > show up
> > > > > >> > > in hand-written dts files.
> > > > > >> > >
> > > > > >> > > I am not sure I understand the whole point of this.
> > > > > >> >
> > > > > >> > I am also confused and do not like the idea of adding device 
> > > > > >> > trees for
> > > > > >> > platforms that are capable of and can / do have a device tree to 
> > > > > >> > give us
> > > > > >> > at run time.
> > > > > >>
> > > > > >> (I'll just reply to this one email, since the same points applies 
> > > > > >> to
> > > > > >> all replies I think)
> > > > > >>
> > > > > >> I have been thinking about this and discussing it with people for a
> > > > > >> few months now. I've been signalling a change like this for over a
> > > > > >> month now, on U-Boot contributor calls and in discussions with 
> > > > > >> Linaro
> > > > > >> people. I sent a patch (below) to try to explain things. I hope it 
> > > > > >> is
> > > > > >> not a surprise!
> > > > > >>
> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > > >> Ilias' series and this one we can get ourselves on a stronger 
> > > > > >> footing.
> > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > > >> For more context:
> > > > > >>
> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > > > >>
> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > >> maintainer would 

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

[Ilias Apalodimas]

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.
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.

> 
> 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.

> We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can 

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

[Simon Glass]

Hi all,

On Thu, 14 Oct 2021 at 09:28, Tom Rini  wrote:
>
> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog  
> > > > wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit 
> > > > > :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly based 
> > > > >> > > on
> > > > >> > > command line parameters, and the device tree you put in this 
> > > > >> > > series
> > > > >> > > has various hardcoded  values which normally do not 
> > > > >> > > show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device trees 
> > > > >> > for
> > > > >> > platforms that are capable of and can / do have a device tree to 
> > > > >> > give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger 
> > > > >> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to 

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

[Simon Glass]

Hi François,

On Thu, 14 Oct 2021 at 12:13, François Ozog  wrote:
>
>
>
> Le mer. 13 oct. 2021 à 20:06, Simon Glass  a écrit :
>>
>> Hi François,
>>
>> On Wed, 13 Oct 2021 at 11:35, François Ozog  wrote:
>> >
>> > Hi Simon
>> >
>> > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :
>> >>
>> >> Hi Tom, Bin,François,
>> >>
>> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
>> >> >
>> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
>> >> > > Hi Simon,
>> >> > >
>> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
>> >> > > >
>> >> > > > 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 at [1].
>> >> > > >
>> >> > > > 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.
>> >> > >
>> >> > > Adding device trees that are never used sounds like a hack to me.
>> >> > >
>> >> > > For QEMU, device tree is dynamically generated on the fly based on
>> >> > > command line parameters, and the device tree you put in this series
>> >> > > has various hardcoded  values which normally do not show up
>> >> > > in hand-written dts files.
>> >> > >
>> >> > > I am not sure I understand the whole point of this.
>> >> >
>> >> > I am also confused and do not like the idea of adding device trees for
>> >> > platforms that are capable of and can / do have a device tree to give us
>> >> > at run time.
>> >>
>> >> (I'll just reply to this one email, since the same points applies to
>> >> all replies I think)
>> >>
>> >> I have been thinking about this and discussing it with people for a
>> >> few months now. I've been signalling a change like this for over a
>> >> month now, on U-Boot contributor calls and in discussions with Linaro
>> >> people. I sent a patch (below) to try to explain things. I hope it is
>> >> not a surprise!
>> >>
>> >> The issue here is that we need a devicetree in-tree in U-Boot, to
>> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
>> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
>> >> Ilias' series and this one we can get ourselves on a stronger footing.
>> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
>> >> For more context:
>> >>
>> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
>> >>
>> >> BTW I did suggest to QEMU ARM that they support a way of adding the
>> >> u-boot.dtsi but there was not much interest there (in fact the
>> >> maintainer would prefer there was no special support even for booting
>> >> Linux directly!)
>> >
>> > i understand their point of view and agree with it.
>> >>
>> >> But in any case it doesn't really help U-Boot. I
>> >> think the path forward might be to run QEMU twice, once to get its
>> >> generated tree and once to give the 'merged' tree with the U-Boot
>> >> properties in it, if people want to use U-Boot features.
>> >>
>> >> I do strongly believe that OF_BOARD must be a run-time option, not a
>> >> build-time one. It creates all sorts of problems and obscurity which
>> >> have taken months to unpick. See the above patch for the rationale.
>> >>
>> >> To add to that rationale, OF_BOARD needs to be an option available to
>> >> any board. At some point in the future it may become a common way
>> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
>> >> to it. It doesn't make any sense to have people decide whether or not
>> >> to set OF_BOARD at build time, thus affecting how the image is put
>> >> together. We'll end up with different U-Boot build targets 

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

[François Ozog]

Le mer. 13 oct. 2021 à 20:06, Simon Glass  a écrit :

> Hi François,
>
> On Wed, 13 Oct 2021 at 11:35, François Ozog 
> wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass 
> wrote:
> >> > > >
> >> > > > 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 at [1].
> >> > > >
> >> > > > 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.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded  values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give
> us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by most/all boards, so that this sort of build
> >> explosion is 

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

[François Ozog]

Le jeu. 14 oct. 2021 à 17:28, Tom Rini  a écrit :

> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.o...@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass 
> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded  values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all 

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

[François Ozog]

Le jeu. 14 oct. 2021 à 18:24, Andre Przywara  a
écrit :

> On Thu, 14 Oct 2021 09:17:52 -0600
> Simon Glass  wrote:
>
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.o...@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass 
> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded  values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all 

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

[Andre Przywara]

On Thu, 14 Oct 2021 09:17:52 -0600
Simon Glass  wrote:

> Hi Tom,
> 
> On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:  
> > > Hi François,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, François Ozog  
> > > wrote:  
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit : 
> > > >  
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:  
> > > >> >
> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:  
> > > >> > > Hi Simon,
> > > >> > >
> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  
> > > >> > > wrote:  
> > > >> > > >
> > > >> > > > 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 at [1].
> > > >> > > >
> > > >> > > > 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.  
> > > >> > >
> > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > >> > > command line parameters, and the device tree you put in this series
> > > >> > > has various hardcoded  values which normally do not show 
> > > >> > > up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole point of this.  
> > > >> >
> > > >> > I am also confused and do not like the idea of adding device trees 
> > > >> > for
> > > >> > platforms that are capable of and can / do have a device tree to 
> > > >> > give us
> > > >> > at run time.  
> > > >>
> > > >> (I'll just reply to this one email, since the same points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it with people for a
> > > >> few months now. I've been signalling a change like this for over a
> > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > >> not a surprise!
> > > >>
> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > >> maintainer would prefer there was no special support even for booting
> > > >> Linux directly!)  
> > > >
> > > > i understand their point of view and agree with it.  
> > > >>
> > > >> But in any case it doesn't really help U-Boot. I
> > > >> think the path forward might be to run QEMU twice, once to get its
> > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > >> properties in it, if people want to use U-Boot features.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > >> build-time one. It creates all sorts of problems and obscurity which
> > > >> have taken months to 

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

[Tom Rini]

On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, François Ozog  
> > > wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> > > >> >
> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > >> > > Hi Simon,
> > > >> > >
> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > 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 at [1].
> > > >> > > >
> > > >> > > > 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.
> > > >> > >
> > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > >> > > command line parameters, and the device tree you put in this series
> > > >> > > has various hardcoded  values which normally do not show 
> > > >> > > up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole point of this.
> > > >> >
> > > >> > I am also confused and do not like the idea of adding device trees 
> > > >> > for
> > > >> > platforms that are capable of and can / do have a device tree to 
> > > >> > give us
> > > >> > at run time.
> > > >>
> > > >> (I'll just reply to this one email, since the same points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it with people for a
> > > >> few months now. I've been signalling a change like this for over a
> > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > >> not a surprise!
> > > >>
> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > >> maintainer would prefer there was no special support even for booting
> > > >> Linux directly!)
> > > >
> > > > i understand their point of view and agree with it.
> > > >>
> > > >> But in any case it doesn't really help U-Boot. I
> > > >> think the path forward might be to run QEMU twice, once to get its
> > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > >> properties in it, if people want to use U-Boot features.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > >> build-time one. It creates all sorts of problems and obscurity which
> > > >> have taken months to unpick. See the above patch 

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

[Simon Glass]

Hi Tom,

On Thu, 14 Oct 2021 at 08:56, Tom Rini  wrote:
>
> On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > Hi François,
> >
> > On Wed, 13 Oct 2021 at 11:35, François Ozog  
> > wrote:
> > >
> > > Hi Simon
> > >
> > > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :
> > >>
> > >> Hi Tom, Bin,François,
> > >>
> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> > >> >
> > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > >> > > Hi Simon,
> > >> > >
> > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  
> > >> > > wrote:
> > >> > > >
> > >> > > > 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 at [1].
> > >> > > >
> > >> > > > 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.
> > >> > >
> > >> > > Adding device trees that are never used sounds like a hack to me.
> > >> > >
> > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > >> > > command line parameters, and the device tree you put in this series
> > >> > > has various hardcoded  values which normally do not show up
> > >> > > in hand-written dts files.
> > >> > >
> > >> > > I am not sure I understand the whole point of this.
> > >> >
> > >> > I am also confused and do not like the idea of adding device trees for
> > >> > platforms that are capable of and can / do have a device tree to give 
> > >> > us
> > >> > at run time.
> > >>
> > >> (I'll just reply to this one email, since the same points applies to
> > >> all replies I think)
> > >>
> > >> I have been thinking about this and discussing it with people for a
> > >> few months now. I've been signalling a change like this for over a
> > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > >> people. I sent a patch (below) to try to explain things. I hope it is
> > >> not a surprise!
> > >>
> > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > >> For more context:
> > >>
> > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> > >>
> > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > >> u-boot.dtsi but there was not much interest there (in fact the
> > >> maintainer would prefer there was no special support even for booting
> > >> Linux directly!)
> > >
> > > i understand their point of view and agree with it.
> > >>
> > >> But in any case it doesn't really help U-Boot. I
> > >> think the path forward might be to run QEMU twice, once to get its
> > >> generated tree and once to give the 'merged' tree with the U-Boot
> > >> properties in it, if people want to use U-Boot features.
> > >>
> > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > >> build-time one. It creates all sorts of problems and obscurity which
> > >> have taken months to unpick. See the above patch for the rationale.
> > >>
> > >> To add to that rationale, OF_BOARD needs to be an option available to
> > >> any board. At some point in the future it may become a common way
> > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > >> to it. It doesn't make any sense to have 

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

[Tom Rini]

On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> Hi François,
> 
> On Wed, 13 Oct 2021 at 11:35, François Ozog  wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
> >> > > >
> >> > > > 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 at [1].
> >> > > >
> >> > > > 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.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded  values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by 

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

[Simon Glass]

Hi François,

On Wed, 13 Oct 2021 at 11:35, François Ozog  wrote:
>
> Hi Simon
>
> Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :
>>
>> Hi Tom, Bin,François,
>>
>> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
>> >
>> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
>> > > Hi Simon,
>> > >
>> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
>> > > >
>> > > > 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 at [1].
>> > > >
>> > > > 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.
>> > >
>> > > Adding device trees that are never used sounds like a hack to me.
>> > >
>> > > For QEMU, device tree is dynamically generated on the fly based on
>> > > command line parameters, and the device tree you put in this series
>> > > has various hardcoded  values which normally do not show up
>> > > in hand-written dts files.
>> > >
>> > > I am not sure I understand the whole point of this.
>> >
>> > I am also confused and do not like the idea of adding device trees for
>> > platforms that are capable of and can / do have a device tree to give us
>> > at run time.
>>
>> (I'll just reply to this one email, since the same points applies to
>> all replies I think)
>>
>> I have been thinking about this and discussing it with people for a
>> few months now. I've been signalling a change like this for over a
>> month now, on U-Boot contributor calls and in discussions with Linaro
>> people. I sent a patch (below) to try to explain things. I hope it is
>> not a surprise!
>>
>> The issue here is that we need a devicetree in-tree in U-Boot, to
>> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
>> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
>> Ilias' series and this one we can get ourselves on a stronger footing.
>> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
>> For more context:
>>
>> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
>>
>> BTW I did suggest to QEMU ARM that they support a way of adding the
>> u-boot.dtsi but there was not much interest there (in fact the
>> maintainer would prefer there was no special support even for booting
>> Linux directly!)
>
> i understand their point of view and agree with it.
>>
>> But in any case it doesn't really help U-Boot. I
>> think the path forward might be to run QEMU twice, once to get its
>> generated tree and once to give the 'merged' tree with the U-Boot
>> properties in it, if people want to use U-Boot features.
>>
>> I do strongly believe that OF_BOARD must be a run-time option, not a
>> build-time one. It creates all sorts of problems and obscurity which
>> have taken months to unpick. See the above patch for the rationale.
>>
>> To add to that rationale, OF_BOARD needs to be an option available to
>> any board. At some point in the future it may become a common way
>> things are done, e.g. TF-A calling U-Boot and providing a devicetree
>> to it. It doesn't make any sense to have people decide whether or not
>> to set OF_BOARD at build time, thus affecting how the image is put
>> together. We'll end up with different U-Boot build targets like
>> capricorn, capricorn_of_board and the like. It should be obvious where
>> that will lead. Instead, OF_BOARD needs to become a commonly used
>> option, perhaps enabled by most/all boards, so that this sort of build
>> explosion is not needed.
>
> If you mean that when boards are by construction providing a DTB to U-Boot 
> then I agree very much. But I don’t understand how the patch set  supports it 
> as it puts dts files for those boards to be built.
>>
>> U-Boot needs to be 

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

[François Ozog]

Hi Simon

Le mer. 13 oct. 2021 à 16:49, Simon Glass  a écrit :

> Hi Tom, Bin,François,
>
> On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
> >
> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
> > > >
> > > > 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 at [1].
> > > >
> > > > 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.
> > >
> > > Adding device trees that are never used sounds like a hack to me.
> > >
> > > For QEMU, device tree is dynamically generated on the fly based on
> > > command line parameters, and the device tree you put in this series
> > > has various hardcoded  values which normally do not show up
> > > in hand-written dts files.
> > >
> > > I am not sure I understand the whole point of this.
> >
> > I am also confused and do not like the idea of adding device trees for
> > platforms that are capable of and can / do have a device tree to give us
> > at run time.
>
> (I'll just reply to this one email, since the same points applies to
> all replies I think)
>
> I have been thinking about this and discussing it with people for a
> few months now. I've been signalling a change like this for over a
> month now, on U-Boot contributor calls and in discussions with Linaro
> people. I sent a patch (below) to try to explain things. I hope it is
> not a surprise!
>
> The issue here is that we need a devicetree in-tree in U-Boot, to
> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> Ilias' series and this one we can get ourselves on a stronger footing.
> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> For more context:
>
>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
>
> BTW I did suggest to QEMU ARM that they support a way of adding the
> u-boot.dtsi but there was not much interest there (in fact the
> maintainer would prefer there was no special support even for booting
> Linux directly!)

i understand their point of view and agree with it.

> But in any case it doesn't really help U-Boot. I
> think the path forward might be to run QEMU twice, once to get its
> generated tree and once to give the 'merged' tree with the U-Boot
> properties in it, if people want to use U-Boot features.
>
> I do strongly believe that OF_BOARD must be a run-time option, not a
> build-time one. It creates all sorts of problems and obscurity which
> have taken months to unpick. See the above patch for the rationale.
>
> To add to that rationale, OF_BOARD needs to be an option available to
> any board. At some point in the future it may become a common way
> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> to it. It doesn't make any sense to have people decide whether or not
> to set OF_BOARD at build time, thus affecting how the image is put
> together. We'll end up with different U-Boot build targets like
> capricorn, capricorn_of_board and the like. It should be obvious where
> that will lead. Instead, OF_BOARD needs to become a commonly used
> option, perhaps enabled by most/all boards, so that this sort of build
> explosion is not needed.

If you mean that when boards are by construction providing a DTB to U-Boot
then I agree very much. But I don’t understand how the patch set  supports
it as it puts dts files for those boards to be built.

> U-Boot needs to be flexible enough to
> function correctly in whatever runtime environment in which it finds
> itself.
>
> Also as binman is pressed into service more and more to build the
> complex firmware images that 

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

[Simon Glass]

Hi Tom, Bin,François,

On Tue, 12 Oct 2021 at 19:34, Tom Rini  wrote:
>
> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
> > >
> > > 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 at [1].
> > >
> > > 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded  values which normally do not show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for
> platforms that are capable of and can / do have a device tree to give us
> at run time.

(I'll just reply to this one email, since the same points applies to
all replies I think)

I have been thinking about this and discussing it with people for a
few months now. I've been signalling a change like this for over a
month now, on U-Boot contributor calls and in discussions with Linaro
people. I sent a patch (below) to try to explain things. I hope it is
not a surprise!

The issue here is that we need a devicetree in-tree in U-Boot, to
avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
Ilias' series and this one we can get ourselves on a stronger footing.
There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
For more context:

http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/

BTW I did suggest to QEMU ARM that they support a way of adding the
u-boot.dtsi but there was not much interest there (in fact the
maintainer would prefer there was no special support even for booting
Linux directly!) But in any case it doesn't really help U-Boot. I
think the path forward might be to run QEMU twice, once to get its
generated tree and once to give the 'merged' tree with the U-Boot
properties in it, if people want to use U-Boot features.

I do strongly believe that OF_BOARD must be a run-time option, not a
build-time one. It creates all sorts of problems and obscurity which
have taken months to unpick. See the above patch for the rationale.

To add to that rationale, OF_BOARD needs to be an option available to
any board. At some point in the future it may become a common way
things are done, e.g. TF-A calling U-Boot and providing a devicetree
to it. It doesn't make any sense to have people decide whether or not
to set OF_BOARD at build time, thus affecting how the image is put
together. We'll end up with different U-Boot build targets like
capricorn, capricorn_of_board and the like. It should be obvious where
that will lead. Instead, OF_BOARD needs to become a commonly used
option, perhaps enabled by most/all boards, so that this sort of build
explosion is not needed. U-Boot needs to be flexible enough to
function correctly in whatever runtime environment in which it finds
itself.

Also as binman is pressed into service more and more to build the
complex firmware images that are becoming fashionable, it needs a
definition (in the devicetree) that describes how to create the image.
We can't support that unless we are building a devicetree, nor can the
running program access the image layout without that information.

François's point about 'don't use this with any kernel' is
germane...but of course I am not suggesting doing that, since OF_BOARD
is, still, enabled. We already use OF_BOARD for various boards that
include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
(as I said 

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

[François Ozog]

Le mer. 13 oct. 2021 à 14:42, Philippe Mathieu-Daudé  a
écrit :

> Hi Simon,
>
> On 10/13/21 03:29, Bin Meng wrote:
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
> >>
> >> 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 at [1].
> >>
> >> 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded  values which normally do not show up
> > in hand-written dts files.
>
> Besides, QEMU generates these dtb at runtime on purpose: it gives
> emulated machines the freedom to evolve by adding new devices,
> mapping/wiring peripherals differently.
>
> By adding static dtb this gives QEMU users false expectations the
> machine hardware is stable, or force QEMU to have this interface
> become a stable API.
>
> From QEMU perspective this seems counter-productive.
>
+1

>
> Digging a bit I see this has already been discussed on qemu-devel@
> mailing list recently:
>
>
> https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=n8rqm4voc...@mail.gmail.com/
>
> > I am not sure I understand the whole point of this.
> >
> >>
> >> It also provides a few qemu clean-ups discovered along the way.
> >>
> >> This series is based on Ilias' two series for OF_HOSTFILE and
> >> OF_PRIOR_STAGE removal.
> >>
> >> It is available at u-boot-dm/ofb-working
> >>
> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> >>
> >
> > Regards,
> > Bin
> >
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

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

[François Ozog]

Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt <
heinrich.schucha...@canonical.com> a écrit :

>
>
> On 10/13/21 03:01, Simon Glass wrote:
> > 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 at [1].
> >
> > 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.
>
> Why should we add dummy files with irrelevant content (see patch 06/16)
> to make the build work? Why don't you fix the Makefile instead?
>
+1

>
> Best regards
>
> Heinrich
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> >
> >
> > Simon Glass (16):
> >arm: qemu: Mention -nographic in the docs
> >arm: qemu: Explain how to extract the generate devicetree
> >riscv: qemu: Explain how to extract the generate devicetree
> >arm: qemu: Add a devicetree file for qemu_arm
> >arm: qemu: Add a devicetree file for qemu_arm64
> >riscv: qemu: Add devicetree files for qemu_riscv32/64
> >arm: rpi: Add a devicetree file for rpi_4
> >arm: vexpress: Add a devicetree file for juno
> >arm: xenguest_arm64: Add a fake devicetree file
> >arm: octeontx: Add a fake devicetree file
> >arm: xilinx_versal_virt: Add a devicetree file
> >arm: bcm7xxx: Add a devicetree file
> >arm: qemu-ppce500: Add a devicetree file
> >arm: highbank: Add a fake devicetree file
> >fdt: Make OF_BOARD a bool option
> >Drop CONFIG_BINMAN_STANDALONE_FDT
> >
> >   Makefile   |3 +-
> >   arch/arm/dts/Makefile  |   20 +-
> >   arch/arm/dts/bcm2711-rpi-4-b.dts   | 1958 
> >   arch/arm/dts/bcm7xxx.dts   |   15 +
> >   arch/arm/dts/highbank.dts  |   14 +
> >   arch/arm/dts/juno-r2.dts   | 1038 +
> >   arch/arm/dts/octeontx.dts  |   14 +
> >   arch/arm/dts/qemu-arm.dts  |  402 +
> >   arch/arm/dts/qemu-arm64.dts|  381 +
> >   arch/arm/dts/xenguest-arm64.dts|   15 +
> >   arch/arm/dts/xilinx-versal-virt.dts|  307 
> >   arch/powerpc/dts/Makefile  |1 +
> >   arch/powerpc/dts/qemu-ppce500.dts  |  264 
> >   arch/riscv/dts/Makefile|2 +-
> >   arch/riscv/dts/qemu-virt.dts   |8 -
> >   arch/riscv/dts/qemu-virt32.dts |  217 +++
> >   arch/riscv/dts/qemu-virt64.dts |  217 +++
> >   configs/bcm7260_defconfig  |1 +
> >   configs/bcm7445_defconfig  |1 +
> >   configs/highbank_defconfig |2 +-
> >   configs/octeontx2_95xx_defconfig   |1 +
> >   configs/octeontx2_96xx_defconfig   |1 +
> >   configs/octeontx_81xx_defconfig|1 +
> >   configs/octeontx_83xx_defconfig|1 +
> >   configs/qemu-ppce500_defconfig |2 +
> >   configs/qemu-riscv32_defconfig |1 +
> >   configs/qemu-riscv32_smode_defconfig   |1 +
> >   configs/qemu-riscv32_spl_defconfig |4 +-
> >   configs/qemu-riscv64_defconfig |1 +
> >   configs/qemu-riscv64_smode_defconfig   |1 +
> >   configs/qemu-riscv64_spl_defconfig |3 +-
> >   configs/qemu_arm64_defconfig   |1 +
> >   configs/qemu_arm_defconfig |1 +
> >   configs/rpi_4_32b_defconfig|1 +
> >   configs/rpi_4_defconfig|1 +
> >   configs/rpi_arm64_defconfig|1 +
> >   configs/vexpress_aemv8a_juno_defconfig |1 +
> >   configs/xenguest_arm64_defconfig   |1 +
> >   

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

[François Ozog]

Le mer. 13 oct. 2021 à 14:41, Andre Przywara  a
écrit :

> On Tue, 12 Oct 2021 19:01:04 -0600
> Simon Glass  wrote:
>
> Hi,
>
> > 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 at [1].
> >
> > 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.
>
> So I am possibly fine with that, but:
>
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
>
> If we just need it to make the build work, we not just have pure stub DTs,
> as you do for highbank, everywhere?
> Adding *some* DT files for those platforms that actually do the right
> thing seems like the wrong direction to me.
> Providing DTs in the source repositories of the actual consumers is more
> of a bad habit that dragged on since Linux started this around 10 years
> ago (for practical reasons). For *some* platforms U-Boot is the firmware
> component that is in the best situation to provide the DTB (because it's
> more than a mere bootloader), but for other it's just not. And this is not
> even looking at really dynamic platforms like QEMU, where providing some
> kind of fixed DT is just not working.
>
> I don't get the argument that people would need to see the DT in the tree
> to develop code. The DT spec and binding documentation (currently living
> in the Linux kernel source tree) provide the specification to code
> against, and the platform specific selection of drivers in Kconfig and
> _defconfig select the drivers for the devices that people are expected to
> see. Why does one need actual DT files in the tree?
>
> I totally agree on adding more documentation, possibly *pointing* to
> example
> DTs or giving commands on how to obtain the actual copy (-dumpdtb,
> /sys/firmware/devicetree), but don't think that adding some .dts files for
> platforms that don't need them is the right way.
>
> Cheers,
> Andre.

+1

>
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> >
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> >
> >
> > Simon Glass (16):
> >   arm: qemu: Mention -nographic in the docs
> >   arm: qemu: Explain how to extract the generate devicetree
> >   riscv: qemu: Explain how to extract the generate devicetree
> >   arm: qemu: Add a devicetree file for qemu_arm
> >   arm: qemu: Add a devicetree file for qemu_arm64
> >   riscv: qemu: Add devicetree files for qemu_riscv32/64
> >   arm: rpi: Add a devicetree file for rpi_4
> >   arm: vexpress: Add a devicetree file for juno
> >   arm: xenguest_arm64: Add a fake devicetree file
> >   arm: octeontx: Add a fake devicetree file
> >   arm: xilinx_versal_virt: Add a devicetree file
> >   arm: bcm7xxx: Add a devicetree file
> >   arm: qemu-ppce500: Add a devicetree file
> >   arm: highbank: Add a fake devicetree file
> >   fdt: Make OF_BOARD a bool option
> >   Drop CONFIG_BINMAN_STANDALONE_FDT
> >
> >  Makefile   |3 +-
> >  arch/arm/dts/Makefile  |   20 +-
> >  arch/arm/dts/bcm2711-rpi-4-b.dts   | 1958 
> >  arch/arm/dts/bcm7xxx.dts   |   15 +
> >  arch/arm/dts/highbank.dts  |   14 +
> >  arch/arm/dts/juno-r2.dts   | 1038 +
> >  arch/arm/dts/octeontx.dts  |   14 +
> >  arch/arm/dts/qemu-arm.dts  |  402 +
> >  arch/arm/dts/qemu-arm64.dts|  381 +
> >  arch/arm/dts/xenguest-arm64.dts|   15 +
> >  arch/arm/dts/xilinx-versal-virt.dts|  307 
> >  arch/powerpc/dts/Makefile  |1 +
> >  arch/powerpc/dts/qemu-ppce500.dts  |  264 
> >  arch/riscv/dts/Makefile|2 +-
> >  arch/riscv/dts/qemu-virt.dts   |8 -
> >  

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

[Philippe Mathieu-Daudé]

Hi Simon,

On 10/13/21 03:29, Bin Meng wrote:
> On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
>>
>> 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 at [1].
>>
>> 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.
> 
> Adding device trees that are never used sounds like a hack to me.
> 
> For QEMU, device tree is dynamically generated on the fly based on
> command line parameters, and the device tree you put in this series
> has various hardcoded  values which normally do not show up
> in hand-written dts files.

Besides, QEMU generates these dtb at runtime on purpose: it gives
emulated machines the freedom to evolve by adding new devices,
mapping/wiring peripherals differently.

By adding static dtb this gives QEMU users false expectations the
machine hardware is stable, or force QEMU to have this interface
become a stable API.

>From QEMU perspective this seems counter-productive.

Digging a bit I see this has already been discussed on qemu-devel@
mailing list recently:

https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=n8rqm4voc...@mail.gmail.com/

> I am not sure I understand the whole point of this.
> 
>>
>> It also provides a few qemu clean-ups discovered along the way.
>>
>> This series is based on Ilias' two series for OF_HOSTFILE and
>> OF_PRIOR_STAGE removal.
>>
>> It is available at u-boot-dm/ofb-working
>>
>> [1] 
>> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
>>
> 
> Regards,
> Bin
> 

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

[Andre Przywara]

On Tue, 12 Oct 2021 19:01:04 -0600
Simon Glass  wrote:

Hi,

> 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 at [1].
> 
> 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.

So I am possibly fine with that, but:

> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.

If we just need it to make the build work, we not just have pure stub DTs,
as you do for highbank, everywhere?
Adding *some* DT files for those platforms that actually do the right
thing seems like the wrong direction to me.
Providing DTs in the source repositories of the actual consumers is more
of a bad habit that dragged on since Linux started this around 10 years
ago (for practical reasons). For *some* platforms U-Boot is the firmware
component that is in the best situation to provide the DTB (because it's
more than a mere bootloader), but for other it's just not. And this is not
even looking at really dynamic platforms like QEMU, where providing some
kind of fixed DT is just not working.

I don't get the argument that people would need to see the DT in the tree
to develop code. The DT spec and binding documentation (currently living
in the Linux kernel source tree) provide the specification to code
against, and the platform specific selection of drivers in Kconfig and
_defconfig select the drivers for the devices that people are expected to
see. Why does one need actual DT files in the tree?

I totally agree on adding more documentation, possibly *pointing* to example
DTs or giving commands on how to obtain the actual copy (-dumpdtb,
/sys/firmware/devicetree), but don't think that adding some .dts files for
platforms that don't need them is the right way.

Cheers,
Andre.

> 
> It also provides a few qemu clean-ups discovered along the way.
> 
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
> 
> It is available at u-boot-dm/ofb-working
> 
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
> 
> 
> Simon Glass (16):
>   arm: qemu: Mention -nographic in the docs
>   arm: qemu: Explain how to extract the generate devicetree
>   riscv: qemu: Explain how to extract the generate devicetree
>   arm: qemu: Add a devicetree file for qemu_arm
>   arm: qemu: Add a devicetree file for qemu_arm64
>   riscv: qemu: Add devicetree files for qemu_riscv32/64
>   arm: rpi: Add a devicetree file for rpi_4
>   arm: vexpress: Add a devicetree file for juno
>   arm: xenguest_arm64: Add a fake devicetree file
>   arm: octeontx: Add a fake devicetree file
>   arm: xilinx_versal_virt: Add a devicetree file
>   arm: bcm7xxx: Add a devicetree file
>   arm: qemu-ppce500: Add a devicetree file
>   arm: highbank: Add a fake devicetree file
>   fdt: Make OF_BOARD a bool option
>   Drop CONFIG_BINMAN_STANDALONE_FDT
> 
>  Makefile   |3 +-
>  arch/arm/dts/Makefile  |   20 +-
>  arch/arm/dts/bcm2711-rpi-4-b.dts   | 1958 
>  arch/arm/dts/bcm7xxx.dts   |   15 +
>  arch/arm/dts/highbank.dts  |   14 +
>  arch/arm/dts/juno-r2.dts   | 1038 +
>  arch/arm/dts/octeontx.dts  |   14 +
>  arch/arm/dts/qemu-arm.dts  |  402 +
>  arch/arm/dts/qemu-arm64.dts|  381 +
>  arch/arm/dts/xenguest-arm64.dts|   15 +
>  arch/arm/dts/xilinx-versal-virt.dts|  307 
>  arch/powerpc/dts/Makefile  |1 +
>  arch/powerpc/dts/qemu-ppce500.dts  |  264 
>  arch/riscv/dts/Makefile|2 +-
>  arch/riscv/dts/qemu-virt.dts   |8 -
>  arch/riscv/dts/qemu-virt32.dts |  217 +++
>  arch/riscv/dts/qemu-virt64.dts |  217 +++
>  configs/bcm7260_defconfig  |1 +
>  configs/bcm7445_defconfig  |1 +
>  configs/highbank_defconfig |2 +-
>  

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

[François Ozog]

Hi Simon


Le mer. 13 oct. 2021 à 03:35, Tom Rini  a écrit :

> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
> > >
> > > 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 at [1].
> > >
> > > 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded  values which normally do not show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for
> platforms that are capable of and can / do have a device tree to give us
> at run time.
>
> --
> Tom


+1

While the cleanup go get three options, including OF_BOARD is nice, the
build solution you propose does not sound the right approach: U-Boot should
be buildable without any DT.

Getting the DT you produced as sample information can be useful and kept
out of build path in documentation with ad-hoc warnings though as I
explained in other mails of the series.

OF_BOARD is a choice to say “I don’t override the legitimate DT with either
OF_SEPARATE or OF_EMBED” (which I see in this case as debug facility for
U-Boot maintainer of the platform).

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

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

[Heinrich Schuchardt]

On 10/13/21 03:01, Simon Glass wrote:

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 at [1].

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.


Why should we add dummy files with irrelevant content (see patch 06/16) 
to make the build work? Why don't you fix the Makefile instead?


Best regards

Heinrich



It also provides a few qemu clean-ups discovered along the way.

This series is based on Ilias' two series for OF_HOSTFILE and
OF_PRIOR_STAGE removal.

It is available at u-boot-dm/ofb-working

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/


Simon Glass (16):
   arm: qemu: Mention -nographic in the docs
   arm: qemu: Explain how to extract the generate devicetree
   riscv: qemu: Explain how to extract the generate devicetree
   arm: qemu: Add a devicetree file for qemu_arm
   arm: qemu: Add a devicetree file for qemu_arm64
   riscv: qemu: Add devicetree files for qemu_riscv32/64
   arm: rpi: Add a devicetree file for rpi_4
   arm: vexpress: Add a devicetree file for juno
   arm: xenguest_arm64: Add a fake devicetree file
   arm: octeontx: Add a fake devicetree file
   arm: xilinx_versal_virt: Add a devicetree file
   arm: bcm7xxx: Add a devicetree file
   arm: qemu-ppce500: Add a devicetree file
   arm: highbank: Add a fake devicetree file
   fdt: Make OF_BOARD a bool option
   Drop CONFIG_BINMAN_STANDALONE_FDT

  Makefile   |3 +-
  arch/arm/dts/Makefile  |   20 +-
  arch/arm/dts/bcm2711-rpi-4-b.dts   | 1958 
  arch/arm/dts/bcm7xxx.dts   |   15 +
  arch/arm/dts/highbank.dts  |   14 +
  arch/arm/dts/juno-r2.dts   | 1038 +
  arch/arm/dts/octeontx.dts  |   14 +
  arch/arm/dts/qemu-arm.dts  |  402 +
  arch/arm/dts/qemu-arm64.dts|  381 +
  arch/arm/dts/xenguest-arm64.dts|   15 +
  arch/arm/dts/xilinx-versal-virt.dts|  307 
  arch/powerpc/dts/Makefile  |1 +
  arch/powerpc/dts/qemu-ppce500.dts  |  264 
  arch/riscv/dts/Makefile|2 +-
  arch/riscv/dts/qemu-virt.dts   |8 -
  arch/riscv/dts/qemu-virt32.dts |  217 +++
  arch/riscv/dts/qemu-virt64.dts |  217 +++
  configs/bcm7260_defconfig  |1 +
  configs/bcm7445_defconfig  |1 +
  configs/highbank_defconfig |2 +-
  configs/octeontx2_95xx_defconfig   |1 +
  configs/octeontx2_96xx_defconfig   |1 +
  configs/octeontx_81xx_defconfig|1 +
  configs/octeontx_83xx_defconfig|1 +
  configs/qemu-ppce500_defconfig |2 +
  configs/qemu-riscv32_defconfig |1 +
  configs/qemu-riscv32_smode_defconfig   |1 +
  configs/qemu-riscv32_spl_defconfig |4 +-
  configs/qemu-riscv64_defconfig |1 +
  configs/qemu-riscv64_smode_defconfig   |1 +
  configs/qemu-riscv64_spl_defconfig |3 +-
  configs/qemu_arm64_defconfig   |1 +
  configs/qemu_arm_defconfig |1 +
  configs/rpi_4_32b_defconfig|1 +
  configs/rpi_4_defconfig|1 +
  configs/rpi_arm64_defconfig|1 +
  configs/vexpress_aemv8a_juno_defconfig |1 +
  configs/xenguest_arm64_defconfig   |1 +
  configs/xilinx_versal_virt_defconfig   |1 +
  doc/board/emulation/qemu-arm.rst   |   19 +-
  doc/board/emulation/qemu-riscv.rst |   12 +
  dts/Kconfig|   27 +-
  tools/binman/binman.rst|   20 -
  43 files changed, 4922 insertions(+), 61 deletions(-)
  create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
  create mode 100644 arch/arm/dts/bcm7xxx.dts
  create mode 100644 arch/arm/dts/highbank.dts
  create mode 100644 arch/arm/dts/juno-r2.dts
  create mode 

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

[Tom Rini]

On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> Hi Simon,
> 
> On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
> >
> > 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 at [1].
> >
> > 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.
> 
> Adding device trees that are never used sounds like a hack to me.
> 
> For QEMU, device tree is dynamically generated on the fly based on
> command line parameters, and the device tree you put in this series
> has various hardcoded  values which normally do not show up
> in hand-written dts files.
> 
> I am not sure I understand the whole point of this.

I am also confused and do not like the idea of adding device trees for
platforms that are capable of and can / do have a device tree to give us
at run time.

-- 
Tom


signature.asc
Description: PGP signature

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

[Bin Meng]

Hi Simon,

On Wed, Oct 13, 2021 at 9:01 AM Simon Glass  wrote:
>
> 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 at [1].
>
> 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.

Adding device trees that are never used sounds like a hack to me.

For QEMU, device tree is dynamically generated on the fly based on
command line parameters, and the device tree you put in this series
has various hardcoded  values which normally do not show up
in hand-written dts files.

I am not sure I understand the whole point of this.

>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/
>

Regards,
Bin