-----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-----
_______________________________________________
linaro-dev mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-dev