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.