On Thu, Jan 30, 2014 at 08:39:00PM -0800, Tim Harvey wrote: > On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote: > > Hi Tim, > > > > On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote: > >> My approach has been to define a per-baseboard device-tree in Linux > >> for a 'fully loaded' board, then remove nodes which the EEPROM claims > >> are not present in the bootloader before it passes the DTB to the > >> kernel. I do this by defining aliases in the device-tree for the > >> peripherals that are 'optional' so that the bootloader itself does not > >> need to know the details about how the device is connected. > > > > This is more of a process question: Is there any information captured > > in your EEPROM that can't be represented in the dtb? iow, at the point > > when you write the EEPROM, why not write the dtb to it as configured? > > > > You could have pre-configured dtsi fragments for each config option, and > > then dynamically create the board dts from the order. > > > > I only ask because it would solve the problem below. However, there's a > > lot more to changing a manufacturing process than meets the eye. :) > > > > our eeprom config section is only 40 bytes. It contains a SKU string, > mac addrs, and some bitwise fields for the various optional components > that we can subload. Ok. > >> Is it more appropriate for the bootloader to 'remove' nodes for > >> devices that are not physically present or should I be setting their > >> status property to 'disabled' instead? I'm not clear if either option > >> really has any pros or cons. > > > > That depends on how you have it structured. Is it a valid dtb? > > Meaning, do you have four nodes all at the same register address? > > Perhaps you could provide an example dts? > > yes its a valid dtb - it is just the superset of everything the > baseboard (ie schematic design) can support. > > A good example is a custom SKU of a baseboard with ethernet subloaded. > If the EEPROM says there is no ethernet mac or phy, I would want to > remove or disable the ethernet node from the devicetree. > > Another example would be a node for 'gpio-pps' (GPIO based > pulse-per-second) support. A baseboard design that has a GPS with its > PPS signal tied to a GPIO would define this in the device-tree, but if > the EEPROM says the GPS isn't loaded, I would want to remove or > disable the gps-pps node. I think JasonG's approach is the way to go (inserting nops). But it's a matter of preference as long as the output is a valid dtb. on a side note: Do you still have to tie your dtb to a version of the kernel? thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
