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

[Tony Lindgren <tony@atomide.com>]

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

> 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