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 >>>>>> 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 >>>>>> 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 >>>>>> Acked-by: Tony Lindgren >>>>>> Signed-off-by: Mike Turquette >>>>>> >>>>>> 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. -Tero