* Tony Lindgren <tony@xxxxxxxxxxx> [140123 09:37]: > * Florian Vaussard <florian.vaussard@xxxxxxx> [140123 08:37]: > > On 01/23/2014 01:27 PM, Tero Kristo wrote: > > >>>>> > > >>>>> The problem is that the Overo (processor card on the Tobi extension > > >>>>> board) can have a variety of processor depending on the exact model: > > >>>>> > > >>>>> - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) > > >>>>> - OMAP 3730 > > >>>>> - AM/DM 37xx > > With the legacy booting, the real problem is that board-overo.c is > trying to boot all overos with just one machine ID. Tero's patch works > around that issue for legacy booting, but maybe it's best to do the SoC > detection in the board-*.c files in init_early as needed rather than > patch all the board-*.c files. > > Sounds like we need to do the same for legacy booting for the original > beagle as well? Looks like the beagle boards are OK as for legacy booting we're seeting omap_clk_soc_init = omap3xxx_clk_init. And for DT based booting we have separate omap3-beagle.dts and omap3-beagle-xm.dts that include omap34xx.dtsi and omap36xx.dtsi respectively. So it seems that only the over .dts files need to be fixed. > > 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 :-( > > Yeah there's no quick fix here that's suitable in the long run. The > proper fix is to have minimal SoC specific .dts files for the > supported overo variants that include the common board specific > .dtsi file(s). > > We did a similar thing recently for the compulab variants, see > commit 0f0cfc69547e (ARM: dts: Add support for sbc-3xxx with cm-t3730) > for example. Also take a look at the follo-up patches posted to > the mailing list. > > With device tree based booting we don't want to build data into the > kernel for all the SoC variants for things like clocks, pinctrl and > hwmod. And we already need to define SoC specific things in the .dts > files for pinctrl with clocks and hwmod heading that way too, so > relying on the built-in kernel data won't work in the long run. > > If we really wanted to, we could set some devices to disabled state > in the bootloader or in the kernel and rely on the SoC detection. But > then we're back to building all the data into the kernel. And we > won't be able to boot new SoC variants with just .dts changes in > the long run like device tree is supposed to do. > > Regards, > > Tony > -- > 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 -- 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
