Hi Javier, On May 13, 2014, at 10:51 AM, Javier Martinez Canillas wrote: > Hello Pantelis, > > On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou > <pantelis.antoniou@xxxxxxxxx> wrote: >> Hi Javier, >> >> On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote: >> >>> On Tue, May 13, 2014 at 4:22 PM, Matt Porter <matt.porter@xxxxxxxxxx> wrote: >>>> 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. >>>> >>> >> >> Since this appears to be all coming back to DT overlays, let me try to >> address some points. >> > > It seems that you misunderstood my comments. I do think that DT > overlays and the cape manager are a great solution for any hardware > that could be expanded on runtime and I really hope that they can > eventually land into mainline. > > In fact if you look on my previous mail you will see that I said: > "until device tree overlay and the cape manager find their way into > mainline..." > >>> Right, I forgot that the capes were stackable so is indeed not >>> practical to model every single combination as DTS in mainline. Even >>> if stacking was not possible there are just too many capes out there >>> to have a DTS for every single cape. >>> >> >> Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine. >> >> Trying to come up with a base DTS for all the capes you've stacked up >> is an exponential problem. >> >>> My point was that someone who wants to use a BBB + a set of capes can >>> today write a DTS for its own stacked setup. >>> >> >> No, the guy that designs a cape (or learns how to) can not write a DTS for >> the base board and the cape in question. Doing that he essentially cuts >> himself off from the community. >> >> Let me explain, the point is for people to easily design capes, open-source their >> design as well as their software, and share them to the community. >> >> This requires that things are easily shareable. >> >> Requiring a relative newbie in kernel development not only generate his own >> base DT, but also to merge all of the other capes DT into his own is a >> nightmare. >> >> BTW, on another tangent, it's not just the BB people that care about dynamic >> hardware configuration. There are a number of FPGA people that seem interested >> as well. >> >> The notion of hardware as something static that never changes is obsolete IMHO. >> >>> Unfortunately I don't have a solution but what I'm pretty sure is that >>> mangling the DTS from the bootloader is not the right one :-) >>> >> >> No, it is not. And this is what we're trying to solve here. >> > > What I said that I'm against is modifying a FDT using U-Boot scripts > commands that is something that mentioned in this thread. That is not > a robust way to do it and also is not something that a newbie could do > it neither. > > Also, doing these FDT changes in the bootloader has several > disadvantages, besides having to implement on each bootloaders like > Tom said, you need to upgrade your bootloader which is something that > just can't be done on many boards and also is still a static > configuration since you need to reboot in order to use a different > FDT. So the hardware can't really be expanded on runtime unlike with > DT overlays where the overlays are loaded from regular files. > > But I guess you agree with me on all those points and you just > misunderstood my comments. So DT overlays is definitely the way to go > (or something similar) but my point is that until we have that > solution merged, you can use a static DT in mainline for your stacked > cape or use a vendor kernel that already has DT overlays support. > > I hope I explained myself better this time ;-) > Heh, no worries :) I guess I'm a little jumpy since this discussion feels like a glitch in the matrix for me :) > Best regards, > Javier Regards -- Pantelis > -- > 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 -- 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
