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

[Florian Vaussard <florian.vaussard@epfl.ch>]

On 01/23/2014 01:27 PM, Tero Kristo wrote:
> On 01/23/2014 11:41 AM, Florian Vaussard wrote:
>>
>>
>> On 01/23/2014 10:15 AM, Florian Vaussard wrote:
>>>
>>>
>>> On 01/23/2014 10:00 AM, Tero Kristo wrote:
>>>> 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.
>>>>
>>>
>>> I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing
>>> the include to omap36xx.dtsi do not fix the issue. I still get the
>>> external abort on non-linefetch (full log here [1]).
>>>
>>
>> So the issue is clearly caused by the hwmod warning just before the
>> panic I think:
>>
>> omap_hwmod: usb_tll_hs: enabled state can only be entered from
>> initialized, idle, or disabled state
>>
>> usb_tll_hs is thus not enabled, and we get a panic when trying to read
>> the revision register
>>
>>          ver =  usbtll_read(tll->base, OMAP_USBTLL_REVISION);
>>
>> at drivers/mfd/omap-usb-tll.c:237.
>>
>> I do not know enough about hwmod to efficiently debug why usb_tll_hs is
>> not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing
>> some DT data?
> 
> The problem is the point before this one, uart4_fck lookup fails. This
> causes the hwmod code to bail out early and not init anything after it.
> 
> I guess you are still mapping wrong clock init as it fails with uart4.
> Give the attached patch a shot and see how it behaves.
> 

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 :-(

Regards,

Florian