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