On Tue, 10 Aug 2010 13:39:57 -0600 Grant Likely <grant.lik...@secretlab.ca> wrote:
> :-) > > I still stand on my point that hard coding device tree manipulations > is asking for trouble. IMNSHO, firmware should really be restricted > to very well defined things in the device tree. I've been thinking > about this a lot, and I'm going to write a "Recommended Practice" > document for dealing with the .dtb at the firmware level. At the > moment, I think firmware should be restricted to only touching the > /chosen node, the /memory node, and updating well defined things like > mac address, but only when the Ethernet node is dereferenced from an > /aliases name instead of full path. When I try to think of the fundamental difference between the above modifications and others, the main thing that I see is maturity/stability. There's nothing special about these except that we've already gone through the pain, and believe (but can't be certain) we've got it right now. We had problems with the /chosen node (must already exist, can't already exist, etc). We did other things before for MAC addresses (hard-coded paths, "mac-address" versus "local-mac-address", etc). What happens if we need multiple memory nodes? What happens if u-boot's use of aliases contradicts some other use? Are even additional types of clock updates off-limits? What about looking up by compatible and distinguishing by address? I think a question we need to answer is, what *is* the device tree? Is it just a convenient way for Linux to organize its knowledge about the hardware -- in which case, would we have been better off by having firmware not touch it at all, and instead do something like cuImage with bd_t replaced by something more robust and extensible (but not as complicated as a full device tree)? Or is the device tree a bundle of information handed to the OS by whatever came before it (be it firmware, a replaceable chunk of code sitting on top of firmware, a hypervisor, static partitioning provided by the system designer, or early Linux code to transform a known type of bad device tree into a good one)? This is what it was in Open Firmware, and is my understanding of what it was meant to be in ePAPR. I think the latter is far more useful. It involves a greater compatibility challenge, but there are escape hatches short of replacing firmware. It scares me less than trying to maintain a static device tree for every way the p4080 reference board could be configured (and deal with support when people use the wrong one). :-) > I *might* be able to be convinced that firmware should be allowed to > modify other properties, but only if it isn't hard coded into the > firmware (ie, by using a boot script or other method that can be > changed without upgrading firmware). As we've discovered in the past, > it is very easy to get into a situation where firmware must be > upgraded to deal with a change in the device tree data. (ie. soc node > name cannot be changed from "soc5200" to "soc" on the lite5200 because > older versions of U-Boot do a pathname lookup) This risk can be > mitigated if there are some well defined rules about what firmware is > and is not allowed to modify in the tree. There are other ways to mitigate the risk, such as having a recovery mode that boots a different firmware image. Even if you are stuck with firmware that wants to do broken device tree updates, there are options: - Use a dts that works with the old firmware, and have a wrapper that fixes up whatever you wanted to change in the final tree after the firmware's done with it. - Have two trees. Give u-boot a dtb it likes, and have glue code suck out important bits to stick into the real dtb. Kind of like cuImage, but with a noncompliant dtb instead of bd_t. - Tell u-boot to not do any updates (I think this is possible if you use the subcommand version of bootm and do each stage manually -- or you could give uboot some dummy dtb that it likes and put the real thing in a dtbImage) and hard code everything in the dts. - Just have the OS retain compatibility with the old binding, if it's not completely unusable. Making the device tree manipulation code replaceable would be nice. In cases where we want to convey some knowledge from the fixed part of the firmware, it would not be too different from unconditionally doing the two-tree thing, except that the firmware tree would be simpler and not associated with the user-supplied dts (i.e. a "better bd_t"), and the glue code wouldn't be tied to a particular OS. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot