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