[U-Boot] /chosen node not overwritten by bootm

[U-Boot] /chosen node not overwritten by bootm

[Stefan Roese]

Hi Jerry,

Again I (and Wolfgang) stumbled about the problem, that the /chosen node is 
not overwritten by the bootm command when it already exists. This is really 
annoying, since we either:

a) Have to remove the chosen node from the dts files (which is not so easy
   if we try to stay in sync with the kernel.org version)

or

b) Have to manually use the U-Boot "fdt" commands to overwrite the chosen node

I can't remember why this current behavior is implemented this way. Jerry, 
can't we just overwrite this node even if it already exists? What would we 
loose by doing this?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] /chosen node not overwritten by bootm

[Jerry Van Baren]

Stefan Roese wrote:
> Hi Jerry,
> 
> Again I (and Wolfgang) stumbled about the problem, that the /chosen node is 
> not overwritten by the bootm command when it already exists. This is really 
> annoying, since we either:
> 
> a) Have to remove the chosen node from the dts files (which is not so easy
>    if we try to stay in sync with the kernel.org version)
> 
> or
> 
> b) Have to manually use the U-Boot "fdt" commands to overwrite the chosen node
> 
> I can't remember why this current behavior is implemented this way. Jerry, 
> can't we just overwrite this node even if it already exists? What would we 
> loose by doing this?
> 
> Thanks.
> 
> Best regards,
> Stefan

Hi Stefan,

The behavior was to mimic the behavior of the non-LIBFDT original 
implementation (and because we thought it was a good idea at the time). 
  We originally assumed that the .dts file writer had more/better 
knowledge of the system than we did (which was true at the time).  This 
was aggravated by the conundrum that the original FDT support didn't do 
a good job of generating the /chosen properties (some were, some 
weren't), so the .dts writers /had to/ pre-init some /chosen values. 
The /aliases node also helped - configuration choices that use to be 
implicit in the .dts /chosen node are now in /aliases (major improvement!).

I thought we turned on the "force" flag so that the /chosen properties 
would be overwritten, apparently I'm mistaken.

I'm fine with overwriting the /chosen node and properties.  Generate a 
patch and I'll be happy to ack it.

(Note to self: maybe it is time to retire the "force" flag - it always 
made me uncomfortable and is confusing.  Is there anything left that we 
*don't* want to force?)

Best regards,
gvb

[U-Boot] /chosen node not overwritten by bootm

[Jerry Van Baren]

Jerry Van Baren wrote:
> Stefan Roese wrote:
>> Hi Jerry,
>>
>> Again I (and Wolfgang) stumbled about the problem, that the /chosen node is 
>> not overwritten by the bootm command when it already exists. This is really 
>> annoying, since we either:
>>
>> a) Have to remove the chosen node from the dts files (which is not so easy
>>    if we try to stay in sync with the kernel.org version)
>>
>> or
>>
>> b) Have to manually use the U-Boot "fdt" commands to overwrite the chosen node
>>
>> I can't remember why this current behavior is implemented this way. Jerry, 
>> can't we just overwrite this node even if it already exists? What would we 
>> loose by doing this?
>>
>> Thanks.
>>
>> Best regards,
>> Stefan
> 
> Hi Stefan,
> 
> The behavior was to mimic the behavior of the non-LIBFDT original 
> implementation (and because we thought it was a good idea at the time). 
>   We originally assumed that the .dts file writer had more/better 
> knowledge of the system than we did (which was true at the time).  This 
> was aggravated by the conundrum that the original FDT support didn't do 
> a good job of generating the /chosen properties (some were, some 
> weren't), so the .dts writers /had to/ pre-init some /chosen values. 
> The /aliases node also helped - configuration choices that use to be 
> implicit in the .dts /chosen node are now in /aliases (major improvement!).
> 
> I thought we turned on the "force" flag so that the /chosen properties 
> would be overwritten, apparently I'm mistaken.
> 
> I'm fine with overwriting the /chosen node and properties.  Generate a 
> patch and I'll be happy to ack it.
> 
> (Note to self: maybe it is time to retire the "force" flag - it always 
> made me uncomfortable and is confusing.  Is there anything left that we 
> *don't* want to force?)
> 
> Best regards,
> gvb

Hi Stefan, Wolfgang, Kumar,

I was messing with Kumar's bootm split-up changeset and it reminded me 
of a major reason that I did not do a "force" on creating the /chosen 
node: it was so that a FDT blob user could use "fdt chosen" to create 
the /chosen node, post-modify it (which is what Kumar needs to do as I 
understand it), and then run bootm.  In this situation, bootm *won't* 
touch /chosen and thus won't undo the extra modifications that the user 
(boot script) did.

Question for Kumar: Am I understanding your problem correctly?  Would 
keeping the /chosen node generation unchanged (no "force") work for you 
short term?

Long term I believe we want to eliminate the "force" parameter entirely 
(disclaimer: I need to look at the impact) and want to break bootm up 
into subcommand a'la Kumar's changeset.

Note to Stefan: I don't know how your boot script is set up, but if you 
prefix it with "fdt rm /chosen", I think it will do what you want it to 
do - remove legacy .dts generated /chosen nodes so it doesn't prevent 
bootm/libfdt from generating the /chosen node.  If the "/chosen" node 
doesn't exist, it will print an error (I believe) but otherwise be OK.

Best regards,
gvb