* PB1176 broken in -rc1
2011-08-10 15:24 PB1176 broken in -rc1 Will Deacon
@ 2011-08-10 15:39 ` Jamie Iles
2011-08-10 15:53 ` Will Deacon
2011-08-11 14:05 ` Linus Walleij
2011-08-16 9:21 ` Linus Walleij
2 siblings, 1 reply; 18+ messages in thread
From: Jamie Iles @ 2011-08-10 15:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will,
On Wed, Aug 10, 2011 at 04:24:00PM +0100, Will Deacon wrote:
> Hi Linus,
>
> My PB1176 platform appears to lock up as soon as it hits userspace when
> running a 3.1-rc1 kernel. If I revert the commit:
>
> f022e4e4 ("ARM: 6986/1: mach-realview: add TCM support for PB1176")
>
> Then things start working again.
>
> My dmesg contains:
>
> [ 0.000000] CPU: found DTCM0 4k @ 00000000, not enabled
> [ 0.000000] CPU: moved DTCM0 4k to fffe8000, enabled
> [ 0.000000] CPU: found DTCM1 4k @ 00000000, not enabled
> [ 0.000000] CPU: moved DTCM1 4k to fffe9000, enabled
> [ 0.000000] CPU: found ITCM0 4k @ 00000000, not enabled
> [ 0.000000] CPU: moved ITCM0 4k to fffe0000, enabled
> [ 0.000000] CPU: found ITCM1 4k @ 00000000, not enabled
> [ 0.000000] CPU: moved ITCM1 4k to fffe1000, enabled
> [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
> [ 0.000000] Kernel command line: root=/dev/nfs ip=dhcp console=ttyAMA0 nfsroot=10.1.69.60:/export/debian,tcp rw
> [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.000000] Memory: 128MB = 128MB total
> [ 0.000000] Memory: 123692k/123692k available, 7380k reserved, 0K highmem
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> [ 0.000000] DTCM : 0xfffe8000 - 0xfffea000 ( 8 kB)
> [ 0.000000] ITCM : 0xfffe0000 - 0xfffe2000 ( 8 kB)
> [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> [ 0.000000] DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
> [ 0.000000] vmalloc : 0xc8800000 - 0xf8000000 ( 760 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
> [ 0.000000] .text : 0xc0008000 - 0xc05670d4 (5501 kB)
> [ 0.000000] .init : 0xc0568000 - 0xc059e000 ( 216 kB)
> [ 0.000000] .data : 0xc059e000 - 0xc05c8ac8 ( 171 kB)
> [ 0.000000] .bss : 0xc05c9024 - 0xc0610578 ( 286 kB)
>
> But then later hangs at:
>
> [ 6.581778] VFS: Mounted root (nfs filesystem) on device 0:12.
>
>
> Any thoughts on how to debug this? The NULL addresses in the dmesg look
> strange to me, but I'm not familiar with the TCMs.
This may be to do with poisoning of the init mem. The patch below
(which is in next as ARM: 7010/1: mm: fix invalid loop for
poison_init_mem) might resolve the issue.
Jamie
8<------
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 2fee782..91bca35 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -441,7 +441,7 @@ static inline int free_area(unsigned long pfn, unsigned long end, char *s)
static inline void poison_init_mem(void *s, size_t count)
{
u32 *p = (u32 *)s;
- while ((count = count - 4))
+ for (; count != 0; count -= 4)
*p++ = 0xe7fddef0;
}
^ permalink raw reply related [flat|nested] 18+ messages in thread* PB1176 broken in -rc1
2011-08-10 15:39 ` Jamie Iles
@ 2011-08-10 15:53 ` Will Deacon
2011-08-11 13:02 ` Linus Walleij
0 siblings, 1 reply; 18+ messages in thread
From: Will Deacon @ 2011-08-10 15:53 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 10, 2011 at 04:39:47PM +0100, Jamie Iles wrote:
> Hi Will,
Hi Jamie,
> On Wed, Aug 10, 2011 at 04:24:00PM +0100, Will Deacon wrote:
> > My PB1176 platform appears to lock up as soon as it hits userspace when
> > running a 3.1-rc1 kernel. If I revert the commit:
> >
> > f022e4e4 ("ARM: 6986/1: mach-realview: add TCM support for PB1176")
> >
> > Then things start working again.
> This may be to do with poisoning of the init mem. The patch below
> (which is in next as ARM: 7010/1: mm: fix invalid loop for
> poison_init_mem) might resolve the issue.
>
> Jamie
>
> 8<------
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 2fee782..91bca35 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -441,7 +441,7 @@ static inline int free_area(unsigned long pfn, unsigned long end, char *s)
> static inline void poison_init_mem(void *s, size_t count)
> {
> u32 *p = (u32 *)s;
> - while ((count = count - 4))
> + for (; count != 0; count -= 4)
> *p++ = 0xe7fddef0;
> }
Wahey, with this I can get a working system again. Thanks for saving me from
reaching for the JTAG debugger!
Will
^ permalink raw reply [flat|nested] 18+ messages in thread* PB1176 broken in -rc1
2011-08-10 15:53 ` Will Deacon
@ 2011-08-11 13:02 ` Linus Walleij
0 siblings, 0 replies; 18+ messages in thread
From: Linus Walleij @ 2011-08-11 13:02 UTC (permalink / raw)
To: linux-arm-kernel
2011/8/10 Will Deacon <will.deacon@arm.com>:
> [Jamie]
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index 2fee782..91bca35 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -441,7 +441,7 @@ static inline int free_area(unsigned long pfn, unsigned long end, char *s)
>> ?static inline void poison_init_mem(void *s, size_t count)
>> ?{
>> ? ? ? u32 *p = (u32 *)s;
>> - ? ? while ((count = count - 4))
>> + ? ? for (; count != 0; count -= 4)
>> ? ? ? ? ? ? ? *p++ = 0xe7fddef0;
>> ?}
>
> Wahey, with this I can get a working system again. Thanks for saving me from
> reaching for the JTAG debugger!
Thanks for fixing Jamie, I was sure I had screwed up on TCM somehow but
it actually seems I haven't.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-10 15:24 PB1176 broken in -rc1 Will Deacon
2011-08-10 15:39 ` Jamie Iles
@ 2011-08-11 14:05 ` Linus Walleij
2011-08-11 14:24 ` Will Deacon
2011-08-16 9:21 ` Linus Walleij
2 siblings, 1 reply; 18+ messages in thread
From: Linus Walleij @ 2011-08-11 14:05 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 10, 2011 at 5:24 PM, Will Deacon <will.deacon@arm.com> wrote:
> [ ? ?0.000000] CPU: found DTCM0 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved DTCM0 4k to fffe8000, enabled
> [ ? ?0.000000] CPU: found DTCM1 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved DTCM1 4k to fffe9000, enabled
> [ ? ?0.000000] CPU: found ITCM0 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved ITCM0 4k to fffe0000, enabled
> [ ? ?0.000000] CPU: found ITCM1 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved ITCM1 4k to fffe1000, enabled
Just hijacking the thread: at one time I think I saw some ARM
high-level schematic of a mpcore where the ARM cores actually had
TCM in them.
I actually spent some time adding multicore TCM support until
I realized that the PB11MPcore actually didn't have TCM.
So I just dropped that stuff.
But to be sure, is there a platform like that, multicore, with
per-processor TCM?
Thanks,
Linus Walleij
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-11 14:05 ` Linus Walleij
@ 2011-08-11 14:24 ` Will Deacon
0 siblings, 0 replies; 18+ messages in thread
From: Will Deacon @ 2011-08-11 14:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
On Thu, Aug 11, 2011 at 03:05:01PM +0100, Linus Walleij wrote:
> On Wed, Aug 10, 2011 at 5:24 PM, Will Deacon <will.deacon@arm.com> wrote:
>
> > [ ? ?0.000000] CPU: found DTCM0 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved DTCM0 4k to fffe8000, enabled
> > [ ? ?0.000000] CPU: found DTCM1 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved DTCM1 4k to fffe9000, enabled
> > [ ? ?0.000000] CPU: found ITCM0 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved ITCM0 4k to fffe0000, enabled
> > [ ? ?0.000000] CPU: found ITCM1 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved ITCM1 4k to fffe1000, enabled
>
> Just hijacking the thread: at one time I think I saw some ARM
> high-level schematic of a mpcore where the ARM cores actually had
> TCM in them.
Hmm, that doesn't sound right. The 11MPCore doesn't have TCMs.
> I actually spent some time adding multicore TCM support until
> I realized that the PB11MPcore actually didn't have TCM.
> So I just dropped that stuff.
>
> But to be sure, is there a platform like that, multicore, with
> per-processor TCM?
It's a feature of the CPU rather than the platform and the 11MPCore doesn't
have TCMs.
Hope that clears things up,
Will
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-10 15:24 PB1176 broken in -rc1 Will Deacon
2011-08-10 15:39 ` Jamie Iles
2011-08-11 14:05 ` Linus Walleij
@ 2011-08-16 9:21 ` Linus Walleij
2011-08-16 9:26 ` Will Deacon
2011-08-16 9:28 ` Jamie Iles
2 siblings, 2 replies; 18+ messages in thread
From: Linus Walleij @ 2011-08-16 9:21 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 10, 2011 at 5:24 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Linus,
>
> My PB1176 platform appears to lock up as soon as it hits userspace when
> running a 3.1-rc1 kernel.
My kernel does not even boot on either -rc1 or -rc2 on the
PB1176, with or wthout Jamies poisoning fixup.
Did you change anything else on top of -rc1 when you tested this?
Will, Jamie, any hints?
If I cherry-pick my TCM patches adding PB1176 support to a clean
v3.0 branch, everything works fine, so I suspect I am not guilty for
this AFAICT, it's something else.
Also the -rc2 code works fine on U300 which has a TCM,
ARM926-EJS.
P.S. By the way regarding this:
> [ ? ?0.000000] CPU: found DTCM0 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved DTCM0 4k to fffe8000, enabled
> [ ? ?0.000000] CPU: found DTCM1 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved DTCM1 4k to fffe9000, enabled
> [ ? ?0.000000] CPU: found ITCM0 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved ITCM0 4k to fffe0000, enabled
> [ ? ?0.000000] CPU: found ITCM1 4k @ 00000000, not enabled
> [ ? ?0.000000] CPU: moved ITCM1 4k to fffe1000, enabled
[Will]
> The NULL addresses in the dmesg look
> strange to me, but I'm not familiar with the TCMs.
This looks perfectly normal. The TCMs are default disabled and mapped
to address 0x00000000, I activate them and move them to our desired
location.
Thanks,
Linus Walleij
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 9:21 ` Linus Walleij
@ 2011-08-16 9:26 ` Will Deacon
2011-08-16 9:35 ` Linus Walleij
2011-08-16 9:28 ` Jamie Iles
1 sibling, 1 reply; 18+ messages in thread
From: Will Deacon @ 2011-08-16 9:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
On Tue, Aug 16, 2011 at 10:21:50AM +0100, Linus Walleij wrote:
> My kernel does not even boot on either -rc1 or -rc2 on the
> PB1176, with or wthout Jamies poisoning fixup.
>
> Did you change anything else on top of -rc1 when you tested this?
Nope, I was using vanilla -rc1.
> Will, Jamie, any hints?
Can you make your .config available somewhere please?
> If I cherry-pick my TCM patches adding PB1176 support to a clean
> v3.0 branch, everything works fine, so I suspect I am not guilty for
> this AFAICT, it's something else.
>
> Also the -rc2 code works fine on U300 which has a TCM,
> ARM926-EJS.
It sounds like an unrelated issue, so let's try to track it down.
> P.S. By the way regarding this:
>
> > [ ? ?0.000000] CPU: found DTCM0 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved DTCM0 4k to fffe8000, enabled
> > [ ? ?0.000000] CPU: found DTCM1 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved DTCM1 4k to fffe9000, enabled
> > [ ? ?0.000000] CPU: found ITCM0 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved ITCM0 4k to fffe0000, enabled
> > [ ? ?0.000000] CPU: found ITCM1 4k @ 00000000, not enabled
> > [ ? ?0.000000] CPU: moved ITCM1 4k to fffe1000, enabled
>
> [Will]
> > The NULL addresses in the dmesg look
> > strange to me, but I'm not familiar with the TCMs.
>
> This looks perfectly normal. The TCMs are default disabled and mapped
> to address 0x00000000, I activate them and move them to our desired
> location.
Ah, ok. Please excuse my lack of TCM knowledge! How do you use the interface
with the TCMs once they've been mapped at the high address? Are they visible
to userspace?
Will
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 9:26 ` Will Deacon
@ 2011-08-16 9:35 ` Linus Walleij
2011-08-16 9:59 ` Will Deacon
0 siblings, 1 reply; 18+ messages in thread
From: Linus Walleij @ 2011-08-16 9:35 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 11:26 AM, Will Deacon <will.deacon@arm.com> wrote:
>> Will, Jamie, any hints?
>
> Can you make your .config available somewhere please?
http://www.df.lth.se/~triad/realview_config
Basically that's the realview_defconfig with these
changes done on top:
scripts/config --file $(realview_dir)/.config \
--enable BLK_DEV_INITRD \
--set-str INITRAMFS_SOURCE rootfs-u338.cpio \
--enable INITRAMFS_COMPRESSION_NONE \
--enable MISC_DEVICES \
--enable ARM_CHARLCD \
--enable DEBUG_LL \
--enable EARLY_PRINTK \
--enable ARM_TEST \
--enable ARM_TCM_TEST \
--set-str CMDLINE "root=/dev/ram0 console=ttyAMA0 earlyprintk mem=128M"
yes "" | make $(make_options) oldconfig
> It sounds like an unrelated issue, so let's try to track it down.
Thanx!
> How do you use the interface
> with the TCMs once they've been mapped at the high address?
Here is my test code patch I'm cooking RFC:
------------8<-----------------------------8<-----------------------------
^ permalink raw reply [flat|nested] 18+ messages in thread* PB1176 broken in -rc1
2011-08-16 9:35 ` Linus Walleij
@ 2011-08-16 9:59 ` Will Deacon
2011-08-16 10:09 ` Russell King - ARM Linux
2011-08-16 12:44 ` Linus Walleij
0 siblings, 2 replies; 18+ messages in thread
From: Will Deacon @ 2011-08-16 9:59 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 10:35:08AM +0100, Linus Walleij wrote:
> Basically that's the realview_defconfig with these
> changes done on top:
>
> scripts/config --file $(realview_dir)/.config \
> --enable BLK_DEV_INITRD \
> --set-str INITRAMFS_SOURCE rootfs-u338.cpio \
> --enable INITRAMFS_COMPRESSION_NONE \
> --enable MISC_DEVICES \
> --enable ARM_CHARLCD \
> --enable DEBUG_LL \
> --enable EARLY_PRINTK \
> --enable ARM_TEST \
> --enable ARM_TCM_TEST \
> --set-str CMDLINE "root=/dev/ram0 console=ttyAMA0 earlyprintk mem=128M"
> yes "" | make $(make_options) oldconfig
The problem is with earlyprintk because your picking up multiple definitions
of DEBUG_LL_UART_OFFSET as a result of basing your config on the defconfig.
Take a look at arch/arm/mach-realview/include/mach/debug-macro.S. I don't
think there's an easy way to fix this because it's used so early, even DT
can't save us.
> > How do you use the interface
> > with the TCMs once they've been mapped at the high address?
>
> Here is my test code patch I'm cooking RFC:
>
> ------------8<-----------------------------8<-----------------------------
> From ece57aeca9a03107432c6090733f89f483872163 Mon Sep 17 00:00:00 2001
> From: Linus Walleij <linus.walleij@linaro.org>
> Date: Thu, 30 Jun 2011 14:33:48 +0200
> Subject: [PATCH] ARM TCM sample code
>
> This is a simple sample snippet of ARM TCM code use, we create
> arm/test to host the code.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[...]
> -static void __init test_tcm(void)
> -{
> - u32 *tcmem;
> - int i;
> -
> - hello_tcm();
> - printk("Hello TCM executed from ITCM RAM\n");
> -
> - printk("TCM variable from testrun: %u @ %p\n", tcmvar, &tcmvar);
> - tcmvar = 0xDEADBEEFU;
> - printk("TCM variable: 0x%x @ %p\n", tcmvar, &tcmvar);
> -
> - printk("TCM assigned variable: 0x%x @ %p\n", tcmassigned, &tcmassigned);
> -
> - printk("TCM constant: 0x%x @ %p\n", tcmconst, &tcmconst);
> -
> - /* Allocate some TCM memory from the pool */
> - tcmem = tcm_alloc(20);
> - if (tcmem) {
> - printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
> - tcmem[0] = 0xDEADBEEFU;
> - tcmem[1] = 0x2BADBABEU;
> - tcmem[2] = 0xCAFEBABEU;
> - tcmem[3] = 0xDEADBEEFU;
> - tcmem[4] = 0x2BADBABEU;
Hmm, do you need a barrier here to (a) stop the compiler constant folding
the tcm array and (b) force a read back from the TCM? Also, where does the
TCM sit in relation to the L1 cache (yes, I should RTFM...).
> - for (i = 0; i < 5; i++)
> - printk("TCM tcmem[%d] = %08x\n", i, tcmem[i]);
> - tcm_free(tcmem, 20);
> - }
> -}
[...]
> + if (tcmem) {
> + pr_info("CPU: TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
> + tcmem[0] = CANARY1;
> + tcmem[1] = CANARY2;
> + tcmem[2] = CANARY3;
> + tcmem[3] = CANARY1;
> + tcmem[4] = CANARY2;
And again here?
> + for (i = 0; i < 5; i++)
> + pr_info("CPU: TCM tcmem[%d] = %08x\n", i, tcmem[i]);
> + BUG_ON(tcmem[0] != CANARY1);
> + BUG_ON(tcmem[1] != CANARY2);
> + BUG_ON(tcmem[2] != CANARY3);
> + BUG_ON(tcmem[3] != CANARY1);
> + BUG_ON(tcmem[4] != CANARY2);
> + tcm_free(tcmem, 20);
> + }
> + return 0;
> +}
Will
^ permalink raw reply [flat|nested] 18+ messages in thread* PB1176 broken in -rc1
2011-08-16 9:59 ` Will Deacon
@ 2011-08-16 10:09 ` Russell King - ARM Linux
2011-08-16 10:17 ` Will Deacon
2011-08-16 12:44 ` Linus Walleij
1 sibling, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-08-16 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 10:59:36AM +0100, Will Deacon wrote:
> The problem is with earlyprintk because your picking up multiple definitions
> of DEBUG_LL_UART_OFFSET as a result of basing your config on the defconfig.
>
> Take a look at arch/arm/mach-realview/include/mach/debug-macro.S. I don't
> think there's an easy way to fix this because it's used so early, even DT
> can't save us.
As I keep saying to people, only use the LL debug during _early_ platform
bring-up. That's what it's there for.
Tying earlyprintk into the LL debug stuff has made the LL debug easier to
use, and therefore easier for people to fall into this trap. That's not
the problem of the LL debug stuff, but the problem of its greater exposure.
So, as the LL debug stuff has this rule, so does earlyprintk. Only use it
for early platform bring up and *once* you have a kernel booting through
to the proper console, disable it *immediately*.
Anything else will lead you into these pitfalls.
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 10:09 ` Russell King - ARM Linux
@ 2011-08-16 10:17 ` Will Deacon
2011-08-16 11:34 ` Russell King - ARM Linux
0 siblings, 1 reply; 18+ messages in thread
From: Will Deacon @ 2011-08-16 10:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
On Tue, Aug 16, 2011 at 11:09:06AM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 16, 2011 at 10:59:36AM +0100, Will Deacon wrote:
> > The problem is with earlyprintk because your picking up multiple definitions
> > of DEBUG_LL_UART_OFFSET as a result of basing your config on the defconfig.
> >
> > Take a look at arch/arm/mach-realview/include/mach/debug-macro.S. I don't
> > think there's an easy way to fix this because it's used so early, even DT
> > can't save us.
>
> As I keep saying to people, only use the LL debug during _early_ platform
> bring-up. That's what it's there for.
>
> Tying earlyprintk into the LL debug stuff has made the LL debug easier to
> use, and therefore easier for people to fall into this trap. That's not
> the problem of the LL debug stuff, but the problem of its greater exposure.
>
> So, as the LL debug stuff has this rule, so does earlyprintk. Only use it
> for early platform bring up and *once* you have a kernel booting through
> to the proper console, disable it *immediately*.
>
> Anything else will lead you into these pitfalls.
Yup, I agree about the usage of earlyprintk. It would be good if the user
could select the platform on which LL debug will work at config time and
then not have to worry about multiple conflicting definitions of
DEBUG_LL_UART_OFFSET. That way, you know on which platform earlyprintk
will work and don't try to use it on any others.
Will
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 10:17 ` Will Deacon
@ 2011-08-16 11:34 ` Russell King - ARM Linux
2011-08-16 21:38 ` Will Deacon
0 siblings, 1 reply; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-08-16 11:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 11:17:11AM +0100, Will Deacon wrote:
> Hi Russell,
>
> On Tue, Aug 16, 2011 at 11:09:06AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Aug 16, 2011 at 10:59:36AM +0100, Will Deacon wrote:
> > > The problem is with earlyprintk because your picking up multiple definitions
> > > of DEBUG_LL_UART_OFFSET as a result of basing your config on the defconfig.
> > >
> > > Take a look at arch/arm/mach-realview/include/mach/debug-macro.S. I don't
> > > think there's an easy way to fix this because it's used so early, even DT
> > > can't save us.
> >
> > As I keep saying to people, only use the LL debug during _early_ platform
> > bring-up. That's what it's there for.
> >
> > Tying earlyprintk into the LL debug stuff has made the LL debug easier to
> > use, and therefore easier for people to fall into this trap. That's not
> > the problem of the LL debug stuff, but the problem of its greater exposure.
> >
> > So, as the LL debug stuff has this rule, so does earlyprintk. Only use it
> > for early platform bring up and *once* you have a kernel booting through
> > to the proper console, disable it *immediately*.
> >
> > Anything else will lead you into these pitfalls.
>
> Yup, I agree about the usage of earlyprintk. It would be good if the user
> could select the platform on which LL debug will work at config time and
> then not have to worry about multiple conflicting definitions of
> DEBUG_LL_UART_OFFSET. That way, you know on which platform earlyprintk
> will work and don't try to use it on any others.
Feel free to send a patch to do that.
One down side of it is that we already have lots of options, so I suspect
it'd get buried and forgotten. As this is a common problem, it probably
makes sense to put a choice in arch/arm/Kconfig.debug and have individual
LL debug variants depend on that. We already have:
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
depends on DEBUG_LL && FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct their
output to the serial port in the DC21285 (Footbridge). Saying N
will cause the debug messages to appear on the first 16550
serial port.
and:
config DEBUG_CLPS711X_UART2
bool "Kernel low-level debugging messages via UART2"
depends on DEBUG_LL && ARCH_CLPS711X
help
Say Y here if you want the debug print routines to direct their
output to the second serial port on these devices. Saying N will
cause the debug messages to appear on the first serial port.
in there. So I think the first step is (untested):
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 81cbe40..068337f 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -100,9 +100,13 @@ config OC_ETM
buffer driver that will allow you to collect traces of the
kernel code.
+choice
+ prompt "Kernel low-level debugging port"
+ depends on DEBUG_LL
+
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
- depends on DEBUG_LL && FOOTBRIDGE
+ depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct their
output to the serial port in the DC21285 (Footbridge). Saying N
@@ -111,12 +115,14 @@ config DEBUG_DC21285_PORT
config DEBUG_CLPS711X_UART2
bool "Kernel low-level debugging messages via UART2"
- depends on DEBUG_LL && ARCH_CLPS711X
+ depends on ARCH_CLPS711X
help
Say Y here if you want the debug print routines to direct their
output to the second serial port on these devices. Saying N will
cause the debug messages to appear on the first serial port.
+endchoice
+
config DEBUG_S3C_UART
depends on PLAT_SAMSUNG
int "S3C UART to use for low-level debug"
^ permalink raw reply related [flat|nested] 18+ messages in thread* PB1176 broken in -rc1
2011-08-16 11:34 ` Russell King - ARM Linux
@ 2011-08-16 21:38 ` Will Deacon
0 siblings, 0 replies; 18+ messages in thread
From: Will Deacon @ 2011-08-16 21:38 UTC (permalink / raw)
To: linux-arm-kernel
Russell,
On Tue, Aug 16, 2011 at 12:34:46PM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 16, 2011 at 11:17:11AM +0100, Will Deacon wrote:
> > Yup, I agree about the usage of earlyprintk. It would be good if the user
> > could select the platform on which LL debug will work at config time and
> > then not have to worry about multiple conflicting definitions of
> > DEBUG_LL_UART_OFFSET. That way, you know on which platform earlyprintk
> > will work and don't try to use it on any others.
>
> Feel free to send a patch to do that.
I've pulled something simple together, based on what you proposed earlier
on. I'll post it to the list shortly...
Will
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 9:59 ` Will Deacon
2011-08-16 10:09 ` Russell King - ARM Linux
@ 2011-08-16 12:44 ` Linus Walleij
2011-08-16 12:52 ` Russell King - ARM Linux
1 sibling, 1 reply; 18+ messages in thread
From: Linus Walleij @ 2011-08-16 12:44 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 11:59 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Aug 16, 2011 at 10:35:08AM +0100, Linus Walleij wrote:
>>
>> scripts/config --file $(realview_dir)/.config \
>> ? ? ? ? --enable BLK_DEV_INITRD \
>> ? ? ? ? --set-str INITRAMFS_SOURCE rootfs-u338.cpio \
>> ? ? ? ? --enable INITRAMFS_COMPRESSION_NONE \
>> ? ? ? ? --enable MISC_DEVICES \
>> ? ? ? ? --enable ARM_CHARLCD \
>> ? ? ? ? --enable DEBUG_LL \
>> ? ? ? ? --enable EARLY_PRINTK \
>> ? ? ? ? --enable ARM_TEST \
>> ? ? ? ? --enable ARM_TCM_TEST \
>> ? ? ? ? --set-str CMDLINE "root=/dev/ram0 console=ttyAMA0 earlyprintk mem=128M"
>> ? ? ? ? yes "" | make $(make_options) oldconfig
>
> The problem is with earlyprintk because your picking up multiple definitions
> of DEBUG_LL_UART_OFFSET as a result of basing your config on the defconfig.
Well doesn't cure it for me I'm afraid, I've added DEBUG_LL and
EARLY_PRINTK here just because it wasn't booting, in the hopes
of catching some early debug messages.
But I do realize I should config out the other platforms and build a
kernel only for the PB1176 when I wanna use that...
Some twiddling reveals that it's that initramfs that breaks it
and only if you use TCM at the same time (!)
The most probably cause being that the size of the combined
kernel+initramfs passed the magic limit where it simply breaks,
I wish we could handle that in some good way :-/
Oh well, no disastrous problem anyway, I'll have to start using
an NFS rootfs like everyone else.
>> - ? ? /* Allocate some TCM memory from the pool */
>> - ? ? tcmem = tcm_alloc(20);
>> - ? ? if (tcmem) {
>> - ? ? ? ? ? ? printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
>> - ? ? ? ? ? ? tcmem[0] = 0xDEADBEEFU;
>> - ? ? ? ? ? ? tcmem[1] = 0x2BADBABEU;
>> - ? ? ? ? ? ? tcmem[2] = 0xCAFEBABEU;
>> - ? ? ? ? ? ? tcmem[3] = 0xDEADBEEFU;
>> - ? ? ? ? ? ? tcmem[4] = 0x2BADBABEU;
>
> Hmm, do you need a barrier here to (a) stop the compiler constant folding
> the tcm array and (b) force a read back from the TCM? Also, where does the
> TCM sit in relation to the L1 cache (yes, I should RTFM...).
Nope, the TCM is uncached, no problems. The Address and data
bus just go directly to the in-CPU memory.
>> + ? ? if (tcmem) {
>> + ? ? ? ? ? ? pr_info("CPU: TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
>> + ? ? ? ? ? ? tcmem[0] = CANARY1;
>> + ? ? ? ? ? ? tcmem[1] = CANARY2;
>> + ? ? ? ? ? ? tcmem[2] = CANARY3;
>> + ? ? ? ? ? ? tcmem[3] = CANARY1;
>> + ? ? ? ? ? ? tcmem[4] = CANARY2;
>
> And again here?
The above deletion from Documentation/. appears as an insertion here...
Thanks,
Linus Walleij
^ permalink raw reply [flat|nested] 18+ messages in thread* PB1176 broken in -rc1
2011-08-16 12:44 ` Linus Walleij
@ 2011-08-16 12:52 ` Russell King - ARM Linux
0 siblings, 0 replies; 18+ messages in thread
From: Russell King - ARM Linux @ 2011-08-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 02:44:21PM +0200, Linus Walleij wrote:
> The most probably cause being that the size of the combined
> kernel+initramfs passed the magic limit where it simply breaks,
> I wish we could handle that in some good way :-/
That should be fixed, because we now place the initramfs image
between the code sections and the data sections.
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 9:21 ` Linus Walleij
2011-08-16 9:26 ` Will Deacon
@ 2011-08-16 9:28 ` Jamie Iles
2011-08-16 9:50 ` Jamie Iles
1 sibling, 1 reply; 18+ messages in thread
From: Jamie Iles @ 2011-08-16 9:28 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 11:21:50AM +0200, Linus Walleij wrote:
> On Wed, Aug 10, 2011 at 5:24 PM, Will Deacon <will.deacon@arm.com> wrote:
>
> > Hi Linus,
> >
> > My PB1176 platform appears to lock up as soon as it hits userspace when
> > running a 3.1-rc1 kernel.
>
> My kernel does not even boot on either -rc1 or -rc2 on the
> PB1176, with or wthout Jamies poisoning fixup.
>
> Did you change anything else on top of -rc1 when you tested this?
>
> Will, Jamie, any hints?
>
> If I cherry-pick my TCM patches adding PB1176 support to a clean
> v3.0 branch, everything works fine, so I suspect I am not guilty for
> this AFAICT, it's something else.
Well I've been basing off of Grant's device tree branches as my platform
(1176) isn't in mainline yet and has DT dependencies. Is anything being
put in your TCMs or are they staying empty?
Jamie
^ permalink raw reply [flat|nested] 18+ messages in thread
* PB1176 broken in -rc1
2011-08-16 9:28 ` Jamie Iles
@ 2011-08-16 9:50 ` Jamie Iles
0 siblings, 0 replies; 18+ messages in thread
From: Jamie Iles @ 2011-08-16 9:50 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 16, 2011 at 10:28:30AM +0100, Jamie Iles wrote:
> On Tue, Aug 16, 2011 at 11:21:50AM +0200, Linus Walleij wrote:
> > On Wed, Aug 10, 2011 at 5:24 PM, Will Deacon <will.deacon@arm.com> wrote:
> >
> > > Hi Linus,
> > >
> > > My PB1176 platform appears to lock up as soon as it hits userspace when
> > > running a 3.1-rc1 kernel.
> >
> > My kernel does not even boot on either -rc1 or -rc2 on the
> > PB1176, with or wthout Jamies poisoning fixup.
> >
> > Did you change anything else on top of -rc1 when you tested this?
> >
> > Will, Jamie, any hints?
> >
> > If I cherry-pick my TCM patches adding PB1176 support to a clean
> > v3.0 branch, everything works fine, so I suspect I am not guilty for
> > this AFAICT, it's something else.
>
> Well I've been basing off of Grant's device tree branches as my platform
> (1176) isn't in mainline yet and has DT dependencies. Is anything being
> put in your TCMs or are they staying empty?
I've just tried merging LinusT's master into my branch today and that
boots fine on my 1176 board with TCM's enabled and your TCM test runs
fine.
Jamie
^ permalink raw reply [flat|nested] 18+ messages in thread