-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2011 06:31 PM, Daniel Lezcano wrote: > 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 ? Does anyone have some clues or ideas I can investigate ? I am really not familiar with this part. - -- <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/ iQEcBAEBAgAGBQJO5iDGAAoJEAKBbMCpUGYAEPkIAJbmVV3Hmy/i7Yxn8OaKZbWA hP9iGyM4IvN8VxuXCAKhUu43ykNQKJCpkdPB6M5GTSwZ+So6lZ1hAR3Hx8cxXz7c R2BPVkrhsnMMH05cABJ7D8KHdLAdcs6X6IDl/8AfU15hvcgAia9hohPdh+xF4xTA kPxVeqavU3qD0bea3tNwg/XD4yLTMzUtX6eAtoBzBxYReoTK8hRFyVLgSqhf+yH5 OiL4nvoIxmDzn9nagHEwILHQBqleXuurubeWRPPmJ8qXOTA7nwtQ+Ut8gJU35OTu c0aEwkzFqW2XXFN5/Saqs78fCyoBbzL4MzJJftpWZLm8UwDosE2jxXqZWaOFTWA= =6bfu -----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
