On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote: > On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote: > > On Tuesday 12 February 2008, David Gibson wrote: > > > Or to expand. It's relatively easy now to just include multiple nodes > > > in the tree and either delete or nop some of them out conditionally > > > using libfdt. But the conditional logic should be in the manipulating > > > agent (u-boot or bootwrapper or whatever), there's no way we're going > > > to require a conditional expression parser to interpret the device > > > tree blob itself. > > > > How about making the logic to nop out nodes a little more generic > > without changes to the binary format? > > E.g. you could have a "linux,conditional-node" property in the device > > tree whose value is compared to a HW configuration specific string. > > In Sean's example, you can have linux,conditional-node="Rev.A" in > > some nodes and linux,conditional-node="Rev.B" in others, then > > knock out all devices that have a non-matching linux,conditional-node > > property, and finally remove the properties themselves before starting > > the kernel. > > Well, that's basically a u-boot issue. If they want to do their input > trees that way, and have helper functions that deal with it...
The actual mechanism that we originially discussed, which Timur later morphed into conditions-on-nodes, was to have a separate hwoptions node, under which would be described various hwoptions (jumpers and such) whose state could be either detected by u-boot or set by environment variable. Each hwoption setting would contain a device tree fragment to be merged into the main device tree. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
