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

[Tero Kristo <t-kristo@ti.com>]

On 01/23/2014 10:14 AM, Florian Vaussard wrote:
> Hello,
>
> On 01/23/2014 07:23 AM, Tero Kristo wrote:
>> On 01/23/2014 03:35 AM, Kevin Hilman wrote:
>>> On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot <khilman@linaro.org>
>>> wrote:
>>>> Automated DT boot report for various ARM defconfigs.
>>>>
>>>>
>>>> Tree/Branch: next
>>>> Git describe: next-20140122
>>>> Failed boot tests (console logs at the end)
>>>> ===========================================
>>>>           omap3-tobi,3730storm:     FAIL:    omap2plus_defconfig
>>> [...]
>>>>           omap3-tobi,3730storm:     FAIL:    multi_v7_defconfig
>>>
>>> These OMAP3 failures are new regressions.  Full failure boot log
>>> attached.
>>> Bisected down to:
>>>
>>> cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit
>>> commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39
>>> Author: Tero Kristo <t-kristo@ti.com>
>>> Date:   Tue Oct 22 11:53:02 2013 +0300
>>>
>>>       ARM: OMAP2+: io: use new clock init API
>>>
>>>       clk_init is now separated to a common function which gets called
>>> for all
>>>       SoC:s, which initializes the DT clocks and calls the SoC specific
>>> clock init.
>>>
>>>       Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>       Acked-by: Tony Lindgren <tony@atomide.com>
>>>       Signed-off-by: Mike Turquette <mturquette@linaro.org>
>>>
>>> Kevin
>>>
>>
>> Hi,
>>
>> I think this is because the tobi board is including wrong omap3-soc.dtsi
>> file (omap34xx.dtsi) through omap3-overo.dtsi.
>>
>> The board should include omap36xx.dtsi at least based on the boot log:
>>
>> [    0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
>>
>
> 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
>
> omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first
> generation.
>
>
> omap34xx.dtsi
>       |
>       -> omap3-overo.dtsi (processor card)
>                  |
>                  -> omap3-tobi.dtsi (expansion board)
>
>
> What is the fundamental incompatibility here? If we have to specifically
> include omap36xx for newer Overo, it will become hard to maintain as it
> will double the number of Overo / expansion boards possibilities.

Well, you get different board declaration inside 
mach-omap2/board-generic.c for omap34xx vs omap36xx.

The clock data issues can be fixed by adding cpu_is_omap34xx() vs. 
cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is 
probably for Tony/Kevin to comment whether we can/should do that.

-Tero

>
> Regards,
>
> Florian
>