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

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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