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