On Thu, Apr 10, 2014 at 10:10:32AM +0100, Russell King - ARM Linux wrote:
On Wed, Apr 09, 2014 at 08:33:56AM -0700, Kevin Hilman wrote:
On Wed, Apr 9, 2014 at 6:33 AM, Fabio Estevam festevam@gmail.com wrote:
On Wed, Apr 9, 2014 at 5:31 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Wed, Apr 09, 2014 at 01:14:51AM -0700, Olof's autobooter wrote:
Failed boards:
cubie2 sunxi_defconfig : FAILED 1:20.72 hummingboard multi_v7_defconfig : FAILED 1:04.66 panda multi_v7_defconfig : FAILED 1:36.13 snowball multi_v7_defconfig : FAILED 1:13.33 wandboard multi_v7_defconfig : FAILED 1:03.73Well, it looks like the Dove fix isn't the full story, and boards are still broken even with the PJ4 fix in place.
mx6 is booting fine with multi_v7_defconfig here (and also in Kevin's boot system).
As Kevin pointed out, the issue Olof is seeing is probably due to dtb and zImage overlap, so he needs to properly adjust the loadaddr/fdt_addr.
Yes. I suspect it's load addr related since I ran into similar failures.
Also note that next/master doesn't have MACH_DOVE enabled (and thus doesn't have CONFIG_CPU_PJ4 enabled) because arm-soc/for-next still has a revert of the MACH_DOVE change while we were waiting for the PJ4 fixes to be merged. Now that you've applied them, we'll drop this revert from arm-soc/for-next.
So now that the remainder of arm-soc has merged into mainline, I'm seeing a combined Versatile Express + OMAP4 kernel failing to boot on OMAP4, while it boots fine on Versatile Express.
So no, this has nothing to do with PJ4 (neither iwmmxt nor pj4-cp0 appear in the build log), and it has nothing to do with load addresses. It looks like some investigation is required and that there is some breakage with what was remaining in arm-soc after all.
It looks like this is caused by something in the depths of OMAPDSS. I see a failure to allocate an order-9 page (2MB), which then provokes the OMAP DSS cleanup paths.
We get to dss_dispc_uninitialize_irq(), which calls devm_free_irq(). Because CONFIG_DEBUG_SHIRQ is enabled, __free_irq ends up calling the handler, and we hang somewhere in the handler.
One for Tomi I think.
My previous boots have succeeded inspite of the allocation failure, so something has changed between 18a1a7a1d862 and a7963eb7f4c4 (Linus' commits) which has caused this to hang.
The last few messages from my debugging are:
omapfb omapfb: failed to allocate framebuffer omapfb omapfb: failed to allocate fbmem omapdss_compat_uninit() APPLY: dss_dispc_uninitialize_irq() omapdss_dispc 58001000.dispc: find_dr: dr=c1363dc0 devm_irq_match: irq 57,57 data c0c0a350,c0c0a350 devm_free_irq: 57 c0c0a350 genirq: __free_irq: calling omap_dispc_irq_handler+0x0/0x11c