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

[Tony Lindgren <tony@atomide.com>]

* Tony Lindgren <tony@atomide.com> [140123 09:37]:
> * Florian Vaussard <florian.vaussard@epfl.ch> [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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html