Subject: Re: linux-next not booting on snowball

From: Daniel Lezcano <[email-masked]>
Date: Fri, 02 Dec 2011 18:31:27 +0100

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