-----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
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 regionIn 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--) {
-----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 regionIn 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
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 regionI 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
-----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 regionI 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
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
-----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
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
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
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
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).
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
-----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
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
-
Daniel Lezcano -
Linus Walleij -
Mark Brown -
Nicolas Pitre