Re: linux-next not booting on snowball

[Daniel Lezcano <daniel.lezcano@linaro.org>]

-----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-----