-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2011 01:11 AM, Nicolas Pitre wrote: > On Fri, 2 Dec 2011, Daniel Lezcano wrote: > >> On 12/01/2011 08:03 PM, Nicolas Pitre wrote: >>> Please have a look at this email: >>> >>> http://article.gmane.org/gmane.linux.ports.arm.kernel/141386 >>> >>> There are two patches in there which should help you get some debugging >>> info out. >> >> >> Thanks Nicolas, >> >> I have applied the patches and I get: >> >> --------------------- >> >> <6>Booting Linux on physical CPU 0 >> <6>Initializing cgroup subsys cpuset >> <6>Initializing cgroup subsys cpu >> <5>Linux version 3.2.0-rc2+ (dlezcano@monster) (gcc version 4.3.2 >> (Debian 4.3.2-1.1) ) #7 SMP PREEMPT Thu Dec 1 2 >> 3:58:34 CET 2011 >> CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387f >> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache >> Machine: Calao Systems Snowball platform >> <4>Ignoring unrecognised tag 0x41000403 >> Memory policy: ECC disabled, Data cache writealloc >> >> --------------------- >> >> I am not able to understand these informations, I hope they can help to >> understand the problem. >> >> Is there something else I can do to help ? > > Yes. Either you have access to a fancy debugger and then you could > trace what happens from the moment devicemaps_init() is entered. > > Or, using the good old way, just insert a couple of > > printk("%s:%s line %d\n", __FILE__, __func__, __LINE__); > > in a couple places (still with the 2 earlier patches applied). Good > locations for those traces would be: > > - Upon entering devicemaps_init() to confirm it makes that far. > > - Just before and right after the call to mdesc->map_io(), still in > devicemaps_init(). > > - If you don't see the trace after mdesc->map_io(), then the problem is > most likely in u8500_map_io(), in which case you should add more > traces in there to narrow the problem area down to the problematic > call. The kernel hangs at: u8500_map_io -> ux500_map_io -> ux500_read_asicid(addr=9001dbf4), base=9001d000 -> readl(__io_address(9001dbf4)=f901dbf4); But when I try with the next patch in the git where it supposed to boot, the hang appears at the same place :/ Any ideas ? Thanks -- Daniel - -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO2QtvAAoJEAKBbMCpUGYA0QEH/1Krr4SMAeVE50+LfXpHrZny yVWfC/ITLgghODFuP84mJV+C6yYl8RSW7Kyxz7mv5jV+oXaLrxv1sJVS/w0bxgAG IXO/P+RmHy6hR0sUPBFjfwM4xCsuwxax/k7KiLu3Yr6h/g0tJQLU6vnZE0ZQutpk MkvSBdJUbQuXLX76AiM4llumrRY5pqzUh7S5vJVbkq2SaTXZxM6kfX1DMXw/3XPd awVn5Loao9AaCnjV6oKJqfF7GlTd9FMa6iZEuRA31EQlfDnsKWcITxSgjG7rmoKD Ums47o9U3MnPtMmw+T8jaNsP7PxdcTIEJatTUbN8C/sQmllb0dX709J43y8lWBk= =r495 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
