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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
