Timur Tabi wrote:

Jerry,

I noticed that fdt_chosen() is called with force=0. Does that mean that if the DTB has a chosen node in it already, that it won't be overwritten? If so, I think that's wrong, because some DTBs have a bogus chosen section in them that has, in the past, always been overwritten by U-Boot. If the chosen node already exists, then it means that it was present in the DTS when it was compiled, and that means the DTS is probably old and the chosen node has bad data in it.

Hi Timur,

In the "old" code, if the dts had a "chosen" node bootm created _a second_ "chosen" node which is just wrong.

I originally removed the auto-generation of the "chosen" node which forced the user to use the "fdt chosen" command (manually or as a boot script) to create the node if he really wanted it (and it would add missing properties and overwrite existing properties the "chosen" node, rather than creating a bogus node).

Forcing the user to create the "chosen" node (either manually/scripted or through the dts) was deemed undesirable. In the discussion that ensued, at least as I understood it, the compromise was to create the node if it did not exist and not touch it if it did exist. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27553

The reason I chose to /not/ create/overwrite "chosen" properties as part of the bootm command is that would potentially overwrite changes that the user made before running bootm. Scenario: fdt addr <address> fdt chosen # create the default chosen node and properties fdt set /chosen <someprop> <somevalue> bootm # ...would be BAD if <someprop> were rewritten

I'm open to tuning the behavior, but I don't like automagic and I *hate* automagic which it undoes something I just got done doing.

Best regards, gvb