On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote: > On Tue, May 13, 2014 at 2:53 PM, Tom Rini <trini@xxxxxx> wrote: > > On 05/12/2014 04:57 PM, Robert Nelson wrote: > >>>> Either case if fine with me. As who knows when the dtc "overlay" will > >>>> every truly make it mainline, as the capemgr was the only real kernel > >>>> user of the i2c/at24 eeprom information. > >>> > >>> Sounds like we should keep it disabled though so u-boot can be used > >>> to toggle it while waiting for the capemgr. That's because the board > >>> has a header for pins, so it's not exactly limited to just the capes. > >>> > >>> Anybody working on enabling/disabling cape dtb configurations in u-boot? > >> > >> Well, > >> > >> Would Tom even approve of that in mainline u-boot? He didn't want my > >> "invert" the gpio to enable the usb hub on the older beagle xm A/B.. > >> > >> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html > >> > >> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html > > Using fdt set from the bootloader to use the same FDT for similar > boards (like the example with Beagle xM variants) is kind of trying to > replicate what we used to do from boards files where it was possible > to manage a set of boards using the same platform code. > > But Device Trees are meant to describe hardware and thus should be > static, if two board are almost identical but slightly different, then > are two different hardware where each need its proper FDT that > describes it. > > > > > I would think that using the 'fdt' command in U-Boot to add all > > properties of every cape found on a running system would drive someone > > to madness quite quickly. Moving all of Pantelis' work for dynamic > > device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, > > etc) sounds like a step in the wrong direction. > > > > Agreed. I think that until the device tree overlay and the cape > manager find their way into mainline we should treat capes as if they > were expansion boards attached to a Computer-on-Module. That is, a > static based board which its own DTS including the BB{B,W} as an dtsi > and not something that can be added on runtime. It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
