On Mon, Apr 7, 2014 at 7:28 AM, Fabio Estevam festevam@gmail.com wrote:
On Mon, Apr 7, 2014 at 11:15 AM, Olof Johansson olof@lixom.net wrote:
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
You are right, Olof. With Chao's patch applied I was able to boot a mx6q with multi_v7_defconfig.
The PJ4 fix should not affect next-20140407.
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
However, we've had that commit reverted in arm-soc/for-next while waiting for the fix(es) to make it through Russell's patch tracker, so MACH_DOVE (and thus the PJ4 options) are *not* selected by default in the multi_v7_defconfig, so the boot failures here (on -next) are very unlikely to be fixed by the PJ4 fix.
For my booter, I had some imx failures also that were fixed by giving the kernel more room to uncompress since it was overwriting the DTB. Seems are multi_v7 kernels are growing, so are getting big enough to cause problems with the default load addresses we're using.
Olof, FWIW, here's what I'm using for wandboards:
loadaddr: 0x11000000 dtb_addr: 0x12000000 initrd_addr: 0x13000000
Kevin