linux-next not booting on snowball

linux-next not booting on snowball

[Daniel Lezcano]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

I am using the linux-next head git tree on a snowball V5.

The kernel hangs at "Uncompressing kernel... done".

After bisecting, the patch where the kernel does no longer boot is:

commit 549158d2ab01e8370d2773044fe09738a26f7086
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Thu Aug 25 00:35:59 2011 -0400

    ARM: move iotable mappings within the vmalloc region
   
    In order to remove the build time variation between different SOCs
with
    regards to VMALLOC_END, the iotable mappings are now allocated inside
    the vmalloc region.  This allows for VMALLOC_END to be identical
across
    all machines.
   
    The value for VMALLOC_END is now set to 0xff000000 which is right
where
    the consistent DMA area starts.
   
    To accommodate all static mappings on machines with possible
highmem usage,
    the default vmalloc area size is changed to 240 MB so that
VMALLOC_START
    is no higher than 0xf0000000 by default.
   
    Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Kevin Hilman <khilman@ti.com>
    Tested-by: Jamie Iles <jamie@jamieiles.com>

Is it a known issue ?

kernel config file : http://pastebin.com/E6HngT58

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/

iQEcBAEBAgAGBQJO15RUAAoJEAKBbMCpUGYA+JkIALr9uQl2EgpCuvjo9udAs6LI
dqM1w0BvMpr2WxcMO0pUvqsCKMKBcuWz6sC/BZjCJmpcxT5H8Am6YJTFq4l4y+tO
09Ggt2fK3AUWH6CBlja8HD0MEQkkjv45tiFWS0s6qFdd4MhhII+P9M04kSwaQ24u
PWwCiPofwx2RfYGM7an7VBpTAgqOuIaL5CUJdjDL5wgHsZW/qE5hQVN+V/V47TPq
1M1A9xaBs+3BhU0yTe8JMstaXoGqTgehkE5puFXZ+6f+qhLRJZTRXwu2lHbXCdyf
rcByM65gB3cSfb555DKnXgK7qB4T2n0t/nilkkT1PaO7sM0I9E4O2wdQk5KvtbE=
=RaPn
-----END PGP SIGNATURE-----

Re: linux-next not booting on snowball

[Mark Brown]

On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:

> commit 549158d2ab01e8370d2773044fe09738a26f7086
> Author: Nicolas Pitre <nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date:   Thu Aug 25 00:35:59 2011 -0400

>     ARM: move iotable mappings within the vmalloc region
>    
>     In order to remove the build time variation between different SOCs
> with
>     regards to VMALLOC_END, the iotable mappings are now allocated inside
>     the vmalloc region.  This allows for VMALLOC_END to be identical
> across
>     all machines.

I recently reported an issue with this patch on s3c64xx which I'm
avoiding with the below change, I believe Nicolas folded this in to his
code but it's not propagated into -next yet.

>From d53e2ce3fb18e097678b324932591044eb80c0f1 Mon Sep 17 00:00:00 2001
From: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Date: Thu, 24 Nov 2011 12:46:04 +0000
Subject: [PATCH] ARM: Handle empty maps in iotable_init()

Some CPUs (such as the S3C6410) have been relying on being able to call
iotable_init() with no io_descs in order to simplify passing through
machine-specific io_descs. The changes in "ARM: move iotable mappings
within the vmalloc region" broke this by adding an early_alloc_aligned()
for an array of vm_structs. Fix this by returning early if no descriptors
have been passed.

I'm not sure if this is the most tasteful fix but it preserves existing
behaviour and allows boot to proceed on my system.

Signed-off-by: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
---
 arch/arm/mm/mmu.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 06e2aef..94c5a0c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -763,6 +763,9 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
 	struct map_desc *md;
 	struct vm_struct *vm;
 
+	if (!nr)
+		return;
+
 	vm = early_alloc_aligned(sizeof(*vm) * nr, __alignof__(*vm));
 
 	for (md = io_desc; nr; md++, nr--) {
-- 
1.7.7.3

Re: linux-next not booting on snowball

[Daniel Lezcano]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/01/2011 03:58 PM, Mark Brown wrote:
> On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:
> 
>> commit 549158d2ab01e8370d2773044fe09738a26f7086
>> Author: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Date:   Thu Aug 25 00:35:59 2011 -0400
> 
>>     ARM: move iotable mappings within the vmalloc region
>>    
>>     In order to remove the build time variation between different SOCs
>> with
>>     regards to VMALLOC_END, the iotable mappings are now allocated inside
>>     the vmalloc region.  This allows for VMALLOC_END to be identical
>> across
>>     all machines.
> 
> I recently reported an issue with this patch on s3c64xx which I'm
> avoiding with the below change, I believe Nicolas folded this in to his
> code but it's not propagated into -next yet.
> 
> From d53e2ce3fb18e097678b324932591044eb80c0f1 Mon Sep 17 00:00:00 2001
> From: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Date: Thu, 24 Nov 2011 12:46:04 +0000
> Subject: [PATCH] ARM: Handle empty maps in iotable_init()
> 
> Some CPUs (such as the S3C6410) have been relying on being able to call
> iotable_init() with no io_descs in order to simplify passing through
> machine-specific io_descs. The changes in "ARM: move iotable mappings
> within the vmalloc region" broke this by adding an early_alloc_aligned()
> for an array of vm_structs. Fix this by returning early if no descriptors
> have been passed.
> 
> I'm not sure if this is the most tasteful fix but it preserves existing
> behaviour and allows boot to proceed on my system.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  arch/arm/mm/mmu.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 06e2aef..94c5a0c 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -763,6 +763,9 @@ void __init iotable_init(struct map_desc *io_desc, int nr)
>  	struct map_desc *md;
>  	struct vm_struct *vm;
>  
> +	if (!nr)
> +		return;
> +
>  	vm = early_alloc_aligned(sizeof(*vm) * nr, __alignof__(*vm));
>  
>  	for (md = io_desc; nr; md++, nr--) {

Thanks for the patch Mark. I applied it and tried to boot but the kernel
is still stuck on the same place :(


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

iQEcBAEBAgAGBQJO156fAAoJEAKBbMCpUGYAZK4H/iCGIqc7pYPllJbO4b4JU6FB
iTIXCeNrLZIxoqgugTQTru/6ISX/Rc3jjXIXrmu7NRjN5V+C0IzpJzRj5x4X/ysJ
xOU+65pKZ2z9D+BnkXADKYZCM6Zlqnf4qtMFLGHC1Ki1QK6HwMmReYUDEJc/7V3z
b1jXlql88Lgex9iFo73VKHn+ww8E/8OWyeutyTUIw9kvrlVaXQy6mF87rOPtS3gP
HCENMMwtEKUlHPrVBDA/MRQDF0iWKQl0aDKlmJBL3HivoAVlmhr1H6m260dkWo1w
dQUfTG7XbBWN3xg2JQ9Bp2KpTl4VvCyEJl9k0ymlcim00+l+dQySpaeC+LCKkG0=
=x1Qh
-----END PGP SIGNATURE-----

Re: linux-next not booting on snowball

[Nicolas Pitre]

On Thu, 1 Dec 2011, Daniel Lezcano wrote:

> On 12/01/2011 03:58 PM, Mark Brown wrote:
> > On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:
> > 
> >> commit 549158d2ab01e8370d2773044fe09738a26f7086
> >> Author: Nicolas Pitre <nicolas.pitre@linaro.org>
> >> Date:   Thu Aug 25 00:35:59 2011 -0400
> > 
> >>     ARM: move iotable mappings within the vmalloc region
> >>    
> > 
> > I recently reported an issue with this patch on s3c64xx which I'm
> > avoiding with the below change, I believe Nicolas folded this in to his
> > code but it's not propagated into -next yet.
> > 
[...]
> 
> Thanks for the patch Mark. I applied it and tried to boot but the kernel
> is still stuck on the same place :(

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.


Nicolas

Re: linux-next not booting on snowball

[Daniel Lezcano]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/01/2011 08:03 PM, Nicolas Pitre wrote:
> On Thu, 1 Dec 2011, Daniel Lezcano wrote:
> 
>> On 12/01/2011 03:58 PM, Mark Brown wrote:
>>> On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote:
>>>
>>>> commit 549158d2ab01e8370d2773044fe09738a26f7086
>>>> Author: Nicolas Pitre <nicolas.pitre@linaro.org>
>>>> Date:   Thu Aug 25 00:35:59 2011 -0400
>>>
>>>>     ARM: move iotable mappings within the vmalloc region
>>>>    
>>>
>>> I recently reported an issue with this patch on s3c64xx which I'm
>>> avoiding with the below change, I believe Nicolas folded this in to his
>>> code but it's not propagated into -next yet.
>>>
> [...]
>>
>> Thanks for the patch Mark. I applied it and tried to boot but the kernel
>> is still stuck on the same place :(
> 
> 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 ?

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/

iQEcBAEBAgAGBQJO2Ah/AAoJEAKBbMCpUGYAef0H/2eV0xJKDtt1sQDOEDqKx3HS
dOK4p//Q7niWVWXl2JXC3x39qBRHg4SDf/jc5nFmUBjbOZQDsiwGujQ9B0bI3yMR
Ozm5Uirv8L1jMdfhzDJQAG5OqFzOoNCX2RE9bYrrKssUb6z1QCPYi0HgGo8Wf4KL
N2T+naSZb1Pe/tIj9A7FK7HC/hjoMwBpdKXfM2IG6QT2sTo3BmTTrkuY8OD6avJ9
V1sWV2pX4oxp4RNOZVqkr6A8Lpcjy/x3GYe3vLVFuXkBTbFhhDRnaXSezCKNrx0X
bMlNXBt8lrqB37ifW61ISww9ec9b6jViXYs1ksByIdeIJPQ0dJPgGbRPrJORp40=
=d9/Y
-----END PGP SIGNATURE-----

Re: linux-next not booting on snowball

[Nicolas Pitre]

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

Re: linux-next not booting on snowball

[Daniel Lezcano]

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

Re: linux-next not booting on snowball

[Nicolas Pitre]

On Fri, 2 Dec 2011, Daniel Lezcano wrote:

> ##########################################################################
> ## ez-pine-gpg v0.4h ## http://Business-PHP.com/opensource/ez-pine-gpg/
> ## Tue Dec  6 22:27:12 EST 2011 ## xanadu.home
> ##########################################################################
> gpg: Signature made Fri 02 Dec 2011 12:31:27 PM EST using RSA key ID A9506600
> gpg: Can't check signature: public key not found
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> %%%%%%%%%%%% Something went wrong --- See above for more info %%%%%%%%%%%%
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/02/2011 01:11 AM, Nicolas Pitre wrote:
> > 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);

OK, forget my debug patches then.  They won't help you in that case 
because the ux500_read_asicid code is cheating.  It is expecting 
mappings from the iotable_init() to be valid right away.  The 
local_flush_tlb_all() + flush_cache_all() calls that follows are a clear 
indicator of a layering violation here.  My debugging patch expressly 
doesn't make those mappings effective untill they're all set up in order 
to preserve the debug UART alive.  So the readl() is crashing the kernel 
since there is no actual mapping for it.

If my install_temp_mm() code is disabled (make it #if 0 instead of 
#ifdef CONFIG_DEBUG_LL), execution should go past that point as the 
needed mapping would be installed and ux500_map_io() would complete its 
job.

In fact, the first thing that u8500_map_io() does is to re-map the debug 
UART so you should be able to continue tracing the code past that point 
(or past the call to ux500_map_io() given its included cache/TLB 
flushes).

So try this:

 - Disable the install_temp_mm() code.

 - Remove all printk traces you added so far.

 - Keep the printascii() hack in printk.c active.

 - Test that kernel and see what you get.

 - If still nothing then resume adding your printk traces but only from 
   the moment ux500_map_io() returned in u8500_map_io() and beyond.


Nicolas

Re: linux-next not booting on snowball

[Daniel Lezcano]

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

Re: linux-next not booting on snowball

[Nicolas Pitre]

On Mon, 12 Dec 2011, Daniel Lezcano wrote:

> Does anyone have some clues or ideas I can investigate ?
> I am really not familiar with this part.

See the next suggestion I gave you in my previous email.

You could also work with Linus Walleij who maintains this architecture, 
and who has access to the hardware while I don't.  I already summarized 
the problem to him privately.


Nicolas

Re: linux-next not booting on snowball

[Linus Walleij]

On Wed, Dec 7, 2011 at 5:09 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:

>> The kernel hangs at:
>>
>> u8500_map_io
>>  -> ux500_map_io
>>    -> ux500_read_asicid(addr=9001dbf4), base=9001d000
>>      ->  readl(__io_address(9001dbf4)=f901dbf4);

This code isn't strictly necessary so I moved it out of the way.

Then it hangs on the second iotable_init() call instead.

I'm digging into this to see what I can find...

Yours,
Linus Walleij

Re: linux-next not booting on snowball

[Linus Walleij]

On Tue, Dec 13, 2011 at 1:35 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Dec 7, 2011 at 5:09 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
>>> The kernel hangs at:
>>>
>>> u8500_map_io
>>>  -> ux500_map_io
>>>    -> ux500_read_asicid(addr=9001dbf4), base=9001d000
>>>      ->  readl(__io_address(9001dbf4)=f901dbf4);
>
> This code isn't strictly necessary so I moved it out of the way.
>
> Then it hangs on the second iotable_init() call instead.

I found the cause: overlapping iotable entries, sent a separate
patch, check it out...

The above remaps and reads from some random ROM page to get
the ASIC ID is actually not screwing things up. Right now.

Linus Walleij

Re: linux-next not booting on snowball

[Mark Brown]

On Wed, Dec 14, 2011 at 09:24:33AM +0100, Linus Walleij wrote:

> The above remaps and reads from some random ROM page to get
> the ASIC ID is actually not screwing things up. Right now.

The ASIC ID reads are also done by Samsung platforms which boot fine -
it's not strictly good but it happens to work (and has done for some
considerable time).

Re: linux-next not booting on snowball

[Linus Walleij]

On Wed, Dec 14, 2011 at 9:27 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Dec 14, 2011 at 09:24:33AM +0100, Linus Walleij wrote:
>
>> The above remaps and reads from some random ROM page to get
>> the ASIC ID is actually not screwing things up. Right now.
>
> The ASIC ID reads are also done by Samsung platforms which boot fine -
> it's not strictly good but it happens to work (and has done for some
> considerable time).

Yes some chicken and egg problem here to some extent :-/

What would be elegant is some readl_early_physical(u32 addr);
that is guaranteed to set up a temporary mapping, read out that
32-bit word wherever it lives and tear it the map down in a
controlled manner afterwards. We could tag it __init so it
is not abused at runtime.

This could atleast collect these hacks in one place.

Don't know how easy it'd be to achieve that...

Linus Walleij