Re: next boot: 34 pass, 5 fail (next-20140122)

[Florian Vaussard <florian.vaussard@epfl.ch>]

Hi,

On 01/23/2014 06:33 PM, Nishanth Menon wrote:
> On 01/23/2014 10:35 AM, Florian Vaussard wrote:
>>
> 
> [..]
>>
>> Ok, so with your patch and changing the include from omap34xx to
>> omap36xx, it works. Now I have to come up with a way to manage all the
>> versions without duplicating all the DT files :-(
> 
> you'd also want to be careful about the omap3_pmx_core2 Vs
> omap3_pmx_core2 split for padconf.
> 

Yes, I know that this is another problematic point. I guess that I will
end up splitting all 34xx-specific and 36xx-specific parts into
dedicated files. Unless I can figure out a way to magically compute the
offset inside the pinctrl domain, but I doubt. I will try to contain the
omap3_pmx_core2 pins to omap3-overo, away from the expansion boards.

> options that come to mind are:
> a) split omap3-overo.dtsi into omap3-overo-common.dtsi
> omap3-overo-34xx.dtsi,omap3-overo-36xx.dtsi, corresponding tobi board
> dts file include as needed
> b) only have common stuff in omap3-overo.dtsi, include omap34xx.dtsi
> or omap36xx.dtsi in corresponding tobi board dts.
> 

Yes, both are an option. I don't know if b) can work, as
omap3-overo.dtsi maybe depends on features declared in omap3yxx.dtsi (to
be verified).

The main problem with both options is that Tobi is not the only
expansion board (the only mainlined for now). I sent patches for other
expansion boards a couple of days ago [1], so at the end we may have ~10
boards if you count only Gumstix's boards, not to mention the boards
from other people (like me). So finally, we will double the number of
dts files just to support both variants. I hope that Gumstix will not
produce a third version of the Overo.

Maybe I can use dt overlay for the expansion boards, like what is done
for capes with beaglebone. The expansion board's overlay could be
applied to the correct Overo dtb at runtime, like what is done from the
hardware's point of view.

I am not familiar with overlays, but from my rapid analysis, the main
difference is: cape's overlay is fused by the userspace when the kernel
has booted, whereas Overo's expansion boards must be fused early in the
boot process (or by the bootloader), as they provide some essential
services, like the primary NIC. I need more time to explore the
feasibility of this solution.

Regards,

Florian

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/109589