* 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? > 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
