* [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() @ 2012-09-01 13:38 gwenhael.goavec 2012-09-01 13:41 ` Gilles Chanteperdrix 0 siblings, 1 reply; 11+ messages in thread From: gwenhael.goavec @ 2012-09-01 13:38 UTC (permalink / raw) To: xenomai Hi, I have 2 boards, the first is based on imx1 and the second on imx27. With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. For the imx1 with 3.2.21 the result is the same. I have enabled early_printk. On every boards the boot stop with a kernel panic. The message start with : "Unable to handle kernel paging request at virtual address 10003010" on imx27. This is due to the call of __ipipe_tsc_get() in __ipipe_tsc_update() To verify my toolchain I have tested 2.6.38.8 with at91 successfully. If someone has a idea? Thank you very much. Gwenhael Goavec-Merou ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 13:38 [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() gwenhael.goavec @ 2012-09-01 13:41 ` Gilles Chanteperdrix 2012-09-01 13:50 ` gwenhael.goavec 0 siblings, 1 reply; 11+ messages in thread From: Gilles Chanteperdrix @ 2012-09-01 13:41 UTC (permalink / raw) To: gwenhael.goavec; +Cc: xenomai On 09/01/2012 03:38 PM, gwenhael.goavec wrote: > Hi, > > I have 2 boards, the first is based on imx1 and the second on imx27. > With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. > For the imx1 with 3.2.21 the result is the same. > > I have enabled early_printk. On every boards the boot stop with a kernel panic. > The message start with : "Unable to handle kernel paging request at virtual > address 10003010" on imx27. > > This is due to the call of __ipipe_tsc_get() in __ipipe_tsc_update() > > To verify my toolchain I have tested 2.6.38.8 with at91 successfully. > > If someone has a idea? Not enough information, to understand what happens we need the kernel oops (at least the register values). -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 13:41 ` Gilles Chanteperdrix @ 2012-09-01 13:50 ` gwenhael.goavec 2012-09-01 13:54 ` Gilles Chanteperdrix 0 siblings, 1 reply; 11+ messages in thread From: gwenhael.goavec @ 2012-09-01 13:50 UTC (permalink / raw) To: xenomai On Sat, 01 Sep 2012 15:41:55 +0200 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: > On 09/01/2012 03:38 PM, gwenhael.goavec wrote: > > > Hi, > > > > I have 2 boards, the first is based on imx1 and the second on imx27. > > With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. > > For the imx1 with 3.2.21 the result is the same. > > > > I have enabled early_printk. On every boards the boot stop with a kernel panic. > > The message start with : "Unable to handle kernel paging request at virtual > > address 10003010" on imx27. > > > > This is due to the call of __ipipe_tsc_get() in __ipipe_tsc_update() > > > > To verify my toolchain I have tested 2.6.38.8 with at91 successfully. > > > > If someone has a idea? > > > Not enough information, to understand what happens we need the kernel > oops (at least the register values). > > -- > Gilles. Sorry, Unable to handle kernel paging request at virtual address 10003010 pgd = c0004000 [10003010] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.38.8-ipipe #34) PC is at 0xffff0f48 LR is at __ipipe_tsc_update+0xfc/0x1c0 pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 sp : c049fe80 ip : c04af0b0 fp : c04af040 r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: a0004000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc049e270) Stack: (0xc049fe80 to 0xc04a0000) fe80: c04a5a78 00000000 00000000 c0039710 c00396fc c0075188 00000000 c04a878c fea0: c049e000 0000001a c04a5a78 c007750c 0000001a c04b545c 00000000 00000002 fec0: c04d5300 c002b044 0000001d c04af0e8 0000001a c007bdf0 c049e000 c0043dd8 fee0: 00000001 c049e000 c04a60ec 0000000c 00000001 c04a60ec 00000034 c049ffb4 ff00: 00000000 c007c4dc c04d5300 c0044248 c049e000 00000000 00000000 c0044250 ff20: c3801470 00000000 00000001 00000000 c3801460 c3801470 c3803200 00000000 ff40: c04d5300 c00b2a20 c055a020 c38014c0 c38014c0 c00b1c04 c38025a0 00000000 ff60: c04b1290 c04af0e8 00000000 ffffffff 00000000 c0022578 00000001 c0442f50 ff80: 41069264 a0021148 00000000 c0399d78 41069264 c049ffb4 c04c98c0 c04c98c0 ffa0: c0022578 c056a360 a002117c c0015ff4 c0442f50 c04d5300 00000002 00000000 ffc0: c04c98c0 c04c98c0 c0022578 c0008c34 c0008464 00000000 00000000 c0022578 ffe0: 00000000 00053175 c04a0010 c0022574 c04a35cc a0008034 00000000 00000000 [<c0032cd4>] (__ipipe_tsc_update+0xfc/0x1c0) from [<c0039710>] (mxc_timer_interrupt+0x14/0x34) [<c0039710>] (mxc_timer_interrupt+0x14/0x34) from [<c0075188>] (handle_IRQ_event+0x40/0x130) [<c0075188>] (handle_IRQ_event+0x40/0x130) from [<c007750c>] (handle_level_irq+0x94/0x140) [<c007750c>] (handle_level_irq+0x94/0x140) from [<c002b044>] (asm_do_IRQ+0x44/0x9c) [<c002b044>] (asm_do_IRQ+0x44/0x9c) from [<c007bdf0>] (__ipipe_sync_stage+0x1a0/0x1bc) Exception stack(0xc049fed8 to 0xc049ff20) fec0: c049e000 c0043dd8 fee0: 00000001 c049e000 c04a60ec 0000000c 00000001 c04a60ec 00000034 c049ffb4 ff00: 00000000 c007c4dc c04d5300 c0044248 c049e000 00000000 00000000 c0044250 [<c007bdf0>] (__ipipe_sync_stage+0x1a0/0x1bc) from [<c007c4dc>] (__ipipe_unstall_root+0x48/0x54) [<c007c4dc>] (__ipipe_unstall_root+0x48/0x54) from [<c0044248>] (vprintk+0x2d0/0x480) [<c0044248>] (vprintk+0x2d0/0x480) from [<c0399d78>] (printk+0xf4/0x1a0) [<c0399d78>] (printk+0xf4/0x1a0) from [<c0015ff4>] (console_init+0xc/0x60) [<c0015ff4>] (console_init+0xc/0x60) from [<c0008c34>] (start_kernel+0x4a4/0x638) [<c0008c34>] (start_kernel+0x4a4/0x638) from [<a0008034>] (0xa0008034) Code: 00000000 10003010 e51f000c e14f22dc (e5900000) ---[ end trace 1b75b31a2719ed1c ]--- Kernel panic - not syncing: Fatal exception in interrupt [<c0031e2c>] (unwind_backtrace+0x0/0xf0) from [<c0399b64>] (panic+0x60/0x180) [<c0399b64>] (panic+0x60/0x180) from [<c0030050>] (die+0x1c4/0x1f8) [<c0030050>] (die+0x1c4/0x1f8) from [<c0033b84>] (__do_kernel_fault+0x64/0x84) [<c0033b84>] (__do_kernel_fault+0x64/0x84) from [<c0033da4>] (do_page_fault+0x200/0x390) [<c0033da4>] (do_page_fault+0x200/0x390) from [<c002b2b8>] (do_DataAbort+0x30/0x134) [<c002b2b8>] (do_DataAbort+0x30/0x134) from [<c002bc6c>] (__dabt_svc+0x4c/0x60) Exception stack(0xc049fe38 to 0xc049fe80) fe20: 10003010 c04d5300 fe40: 00000000 00000000 ffff0f20 ffff0f40 c04c99f8 0000001a c04d5300 c04d5300 fe60: c04af0b0 c04af040 c04af0b0 c049fe80 c0032cd4 ffff0f48 600000d3 ffffffff [<c002bc6c>] (__dabt_svc+0x4c/0x60) from [<ffff0f48>] (0xffff0f48) Gwenhael ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 13:50 ` gwenhael.goavec @ 2012-09-01 13:54 ` Gilles Chanteperdrix 2012-09-01 14:29 ` Michael Trimarchi 2012-09-01 14:32 ` gwenhael.goavec 0 siblings, 2 replies; 11+ messages in thread From: Gilles Chanteperdrix @ 2012-09-01 13:54 UTC (permalink / raw) To: gwenhael.goavec; +Cc: xenomai On 09/01/2012 03:50 PM, gwenhael.goavec wrote: > On Sat, 01 Sep 2012 15:41:55 +0200 > Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: > >> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >> >>> Hi, >>> >>> I have 2 boards, the first is based on imx1 and the second on imx27. >>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>> For the imx1 with 3.2.21 the result is the same. >>> >>> I have enabled early_printk. On every boards the boot stop with a kernel panic. >>> The message start with : "Unable to handle kernel paging request at virtual >>> address 10003010" on imx27. >>> >>> This is due to the call of __ipipe_tsc_get() in __ipipe_tsc_update() >>> >>> To verify my toolchain I have tested 2.6.38.8 with at91 successfully. >>> >>> If someone has a idea? >> >> >> Not enough information, to understand what happens we need the kernel >> oops (at least the register values). >> >> -- >> Gilles. > > Sorry, > > Unable to handle kernel paging request at virtual address 10003010 > pgd = c0004000 > [10003010] *pgd=00000000 > Internal error: Oops: 5 [#1] PREEMPT > last sysfs file: > Modules linked in: > CPU: 0 Not tainted (2.6.38.8-ipipe #34) > PC is at 0xffff0f48 > LR is at __ipipe_tsc_update+0xfc/0x1c0 > pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 > sp : c049fe80 ip : c04af0b0 fp : c04af040 > r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 > r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 > r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 Ok. In the mean time I remembered someone signalled this bug and I fixed it in the patch for 3.4. r0 is supposed to be the address of the hardware timer, 10003010 is a physical address instead of being a virtual address. Please try the following patch: diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c index 255e759..7a3d6b9 100644 --- a/arch/arm/plat-mxc/time.c +++ b/arch/arm/plat-mxc/time.c @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, if (timer_is_v1()) { tsc_info.u.counter_paddr = phys + MX1_2_TCN; - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); } else { tsc_info.u.counter_paddr = phys + V2_TCN; tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); -- Gilles. ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 13:54 ` Gilles Chanteperdrix @ 2012-09-01 14:29 ` Michael Trimarchi 2012-09-01 14:32 ` Gilles Chanteperdrix 2012-09-01 14:32 ` gwenhael.goavec 1 sibling, 1 reply; 11+ messages in thread From: Michael Trimarchi @ 2012-09-01 14:29 UTC (permalink / raw) To: Gilles Chanteperdrix, gwenhael.goavec; +Cc: xenomai Hi Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >On 09/01/2012 03:50 PM, gwenhael.goavec wrote: > >> On Sat, 01 Sep 2012 15:41:55 +0200 >> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: >> >>> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >>> >>>> Hi, >>>> >>>> I have 2 boards, the first is based on imx1 and the second on >imx27. >>>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>>> For the imx1 with 3.2.21 the result is the same. >>>> >>>> I have enabled early_printk. On every boards the boot stop with a >kernel panic. >>>> The message start with : "Unable to handle kernel paging request at >virtual >>>> address 10003010" on imx27. >>>> >>>> This is due to the call of __ipipe_tsc_get() in >__ipipe_tsc_update() >>>> >>>> To verify my toolchain I have tested 2.6.38.8 with at91 >successfully. >>>> >>>> If someone has a idea? >>> >>> >>> Not enough information, to understand what happens we need the >kernel >>> oops (at least the register values). >>> >>> -- >>> >Gilles. >> >> Sorry, >> >> Unable to handle kernel paging request at virtual address 10003010 >> pgd = c0004000 >> [10003010] *pgd=00000000 >> Internal error: Oops: 5 [#1] PREEMPT >> last sysfs file: >> Modules linked in: >> CPU: 0 Not tainted (2.6.38.8-ipipe #34) >> PC is at 0xffff0f48 >> LR is at __ipipe_tsc_update+0xfc/0x1c0 >> pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 >> sp : c049fe80 ip : c04af0b0 fp : c04af040 >> r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 >> r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 >> r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 > > >Ok. In the mean time I remembered someone signalled this bug and I >fixed it in the patch for 3.4. r0 is supposed to be the address of the >hardware timer, 10003010 is a physical address instead of being a >virtual address. Please try the following patch: > >diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c >index 255e759..7a3d6b9 100644 >--- a/arch/arm/plat-mxc/time.c >+++ b/arch/arm/plat-mxc/time.c >@@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, > > if (timer_is_v1()) { > tsc_info.u.counter_paddr = phys + MX1_2_TCN; >- tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); >+ tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); > } else { > tsc_info.u.counter_paddr = phys + V2_TCN; > tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); > > It was my patch Michael >-- > Gilles. > >_______________________________________________ >Xenomai mailing list >Xenomai@xenomai.org >http://www.xenomai.org/mailman/listinfo/xenomai -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 14:29 ` Michael Trimarchi @ 2012-09-01 14:32 ` Gilles Chanteperdrix 2012-09-01 14:33 ` Michael Trimarchi 0 siblings, 1 reply; 11+ messages in thread From: Gilles Chanteperdrix @ 2012-09-01 14:32 UTC (permalink / raw) To: Michael Trimarchi; +Cc: xenomai On 09/01/2012 04:29 PM, Michael Trimarchi wrote: > Hi > > Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: > >> On 09/01/2012 03:50 PM, gwenhael.goavec wrote: >> >>> On Sat, 01 Sep 2012 15:41:55 +0200 >>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: >>> >>>> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >>>> >>>>> Hi, >>>>> >>>>> I have 2 boards, the first is based on imx1 and the second on >> imx27. >>>>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>>>> For the imx1 with 3.2.21 the result is the same. >>>>> >>>>> I have enabled early_printk. On every boards the boot stop with a >> kernel panic. >>>>> The message start with : "Unable to handle kernel paging request at >> virtual >>>>> address 10003010" on imx27. >>>>> >>>>> This is due to the call of __ipipe_tsc_get() in >> __ipipe_tsc_update() >>>>> >>>>> To verify my toolchain I have tested 2.6.38.8 with at91 >> successfully. >>>>> >>>>> If someone has a idea? >>>> >>>> >>>> Not enough information, to understand what happens we need the >> kernel >>>> oops (at least the register values). >>>> >>>> -- >>>> >> Gilles. >>> >>> Sorry, >>> >>> Unable to handle kernel paging request at virtual address 10003010 >>> pgd = c0004000 >>> [10003010] *pgd=00000000 >>> Internal error: Oops: 5 [#1] PREEMPT >>> last sysfs file: >>> Modules linked in: >>> CPU: 0 Not tainted (2.6.38.8-ipipe #34) >>> PC is at 0xffff0f48 >>> LR is at __ipipe_tsc_update+0xfc/0x1c0 >>> pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 >>> sp : c049fe80 ip : c04af0b0 fp : c04af040 >>> r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 >>> r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 >>> r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 >> >> >> Ok. In the mean time I remembered someone signalled this bug and I >> fixed it in the patch for 3.4. r0 is supposed to be the address of the >> hardware timer, 10003010 is a physical address instead of being a >> virtual address. Please try the following patch: >> >> diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c >> index 255e759..7a3d6b9 100644 >> --- a/arch/arm/plat-mxc/time.c >> +++ b/arch/arm/plat-mxc/time.c >> @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, >> >> if (timer_is_v1()) { >> tsc_info.u.counter_paddr = phys + MX1_2_TCN; >> - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); >> + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); >> } else { >> tsc_info.u.counter_paddr = phys + V2_TCN; >> tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); >> >> > > It was my patch No, you promised to send a patch for 3.2 and I never received it, so I fixed it myself. -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 14:32 ` Gilles Chanteperdrix @ 2012-09-01 14:33 ` Michael Trimarchi 2012-09-01 14:42 ` Gilles Chanteperdrix 2012-09-01 15:15 ` Gilles Chanteperdrix 0 siblings, 2 replies; 11+ messages in thread From: Michael Trimarchi @ 2012-09-01 14:33 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Hi Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >On 09/01/2012 04:29 PM, Michael Trimarchi wrote: > >> Hi >> >> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >> >>> On 09/01/2012 03:50 PM, gwenhael.goavec wrote: >>> >>>> On Sat, 01 Sep 2012 15:41:55 +0200 >>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: >>>> >>>>> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have 2 boards, the first is based on imx1 and the second on >>> imx27. >>>>>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>>>>> For the imx1 with 3.2.21 the result is the same. >>>>>> >>>>>> I have enabled early_printk. On every boards the boot stop with a >>> kernel panic. >>>>>> The message start with : "Unable to handle kernel paging request >at >>> virtual >>>>>> address 10003010" on imx27. >>>>>> >>>>>> This is due to the call of __ipipe_tsc_get() in >>> __ipipe_tsc_update() >>>>>> >>>>>> To verify my toolchain I have tested 2.6.38.8 with at91 >>> successfully. >>>>>> >>>>>> If someone has a idea? >>>>> >>>>> >>>>> Not enough information, to understand what happens we need the >>> kernel >>>>> oops (at least the register values). >>>>> >>>>> -- >>>>> >>> Gilles. >>>> >>>> Sorry, >>>> >>>> Unable to handle kernel paging request at virtual address 10003010 >>>> pgd = c0004000 >>>> [10003010] *pgd=00000000 >>>> Internal error: Oops: 5 [#1] PREEMPT >>>> last sysfs file: >>>> Modules linked in: >>>> CPU: 0 Not tainted (2.6.38.8-ipipe #34) >>>> PC is at 0xffff0f48 >>>> LR is at __ipipe_tsc_update+0xfc/0x1c0 >>>> pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 >>>> sp : c049fe80 ip : c04af0b0 fp : c04af040 >>>> r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 >>>> r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 >>>> r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 >>> >>> >>> Ok. In the mean time I remembered someone signalled this bug and I >>> fixed it in the patch for 3.4. r0 is supposed to be the address of >the >>> hardware timer, 10003010 is a physical address instead of being a >>> virtual address. Please try the following patch: >>> >>> diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c >>> index 255e759..7a3d6b9 100644 >>> --- a/arch/arm/plat-mxc/time.c >>> +++ b/arch/arm/plat-mxc/time.c >>> @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, >>> >>> if (timer_is_v1()) { >>> tsc_info.u.counter_paddr = phys + MX1_2_TCN; >>> - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); >>> + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); >>> } else { >>> tsc_info.u.counter_paddr = phys + V2_TCN; >>> tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); >>> >>> >> >> It was my patch > > >No, you promised to send a patch for 3.2 and I never received it, so I >fixed it myself. > Sorry , I was thinking that you only need some test on it, Execuse me for it Michael >-- > Gilles. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 14:33 ` Michael Trimarchi @ 2012-09-01 14:42 ` Gilles Chanteperdrix 2012-09-01 15:15 ` Gilles Chanteperdrix 1 sibling, 0 replies; 11+ messages in thread From: Gilles Chanteperdrix @ 2012-09-01 14:42 UTC (permalink / raw) To: Michael Trimarchi; +Cc: xenomai On 09/01/2012 04:33 PM, Michael Trimarchi wrote: > Hi > > Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: > >> On 09/01/2012 04:29 PM, Michael Trimarchi wrote: >> >>> Hi >>> >>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >>> >>>> On 09/01/2012 03:50 PM, gwenhael.goavec wrote: >>>> >>>>> On Sat, 01 Sep 2012 15:41:55 +0200 >>>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: >>>>> >>>>>> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have 2 boards, the first is based on imx1 and the second on >>>> imx27. >>>>>>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>>>>>> For the imx1 with 3.2.21 the result is the same. >>>>>>> >>>>>>> I have enabled early_printk. On every boards the boot stop with a >>>> kernel panic. >>>>>>> The message start with : "Unable to handle kernel paging request >> at >>>> virtual >>>>>>> address 10003010" on imx27. >>>>>>> >>>>>>> This is due to the call of __ipipe_tsc_get() in >>>> __ipipe_tsc_update() >>>>>>> >>>>>>> To verify my toolchain I have tested 2.6.38.8 with at91 >>>> successfully. >>>>>>> >>>>>>> If someone has a idea? >>>>>> >>>>>> >>>>>> Not enough information, to understand what happens we need the >>>> kernel >>>>>> oops (at least the register values). >>>>>> >>>>>> -- >>>>>> >>>> Gilles. >>>>> >>>>> Sorry, >>>>> >>>>> Unable to handle kernel paging request at virtual address 10003010 >>>>> pgd = c0004000 >>>>> [10003010] *pgd=00000000 >>>>> Internal error: Oops: 5 [#1] PREEMPT >>>>> last sysfs file: >>>>> Modules linked in: >>>>> CPU: 0 Not tainted (2.6.38.8-ipipe #34) >>>>> PC is at 0xffff0f48 >>>>> LR is at __ipipe_tsc_update+0xfc/0x1c0 >>>>> pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 >>>>> sp : c049fe80 ip : c04af0b0 fp : c04af040 >>>>> r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 >>>>> r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 >>>>> r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 >>>> >>>> >>>> Ok. In the mean time I remembered someone signalled this bug and I >>>> fixed it in the patch for 3.4. r0 is supposed to be the address of >> the >>>> hardware timer, 10003010 is a physical address instead of being a >>>> virtual address. Please try the following patch: >>>> >>>> diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c >>>> index 255e759..7a3d6b9 100644 >>>> --- a/arch/arm/plat-mxc/time.c >>>> +++ b/arch/arm/plat-mxc/time.c >>>> @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, >>>> >>>> if (timer_is_v1()) { >>>> tsc_info.u.counter_paddr = phys + MX1_2_TCN; >>>> - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); >>>> + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); >>>> } else { >>>> tsc_info.u.counter_paddr = phys + V2_TCN; >>>> tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); >>>> >>>> >>> >>> It was my patch >> >> >> No, you promised to send a patch for 3.2 and I never received it, so I >> fixed it myself. >> > > Sorry , I was thinking that you only need some test on it, > > Execuse me for it No problem, I am just explaining why the fix did not make it into 3.2. I forgot about the issue, and remembered it when doing the port to 3.4. -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 14:33 ` Michael Trimarchi 2012-09-01 14:42 ` Gilles Chanteperdrix @ 2012-09-01 15:15 ` Gilles Chanteperdrix 2012-09-01 16:37 ` Michael Trimarchi 1 sibling, 1 reply; 11+ messages in thread From: Gilles Chanteperdrix @ 2012-09-01 15:15 UTC (permalink / raw) To: Michael Trimarchi; +Cc: xenomai On 09/01/2012 04:33 PM, Michael Trimarchi wrote: > Hi > > Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: > >> On 09/01/2012 04:29 PM, Michael Trimarchi wrote: >> >>> Hi >>> >>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >>> >>>> On 09/01/2012 03:50 PM, gwenhael.goavec wrote: >>>> >>>>> On Sat, 01 Sep 2012 15:41:55 +0200 >>>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: >>>>> >>>>>> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have 2 boards, the first is based on imx1 and the second on >>>> imx27. >>>>>>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>>>>>> For the imx1 with 3.2.21 the result is the same. >>>>>>> >>>>>>> I have enabled early_printk. On every boards the boot stop with a >>>> kernel panic. >>>>>>> The message start with : "Unable to handle kernel paging request >> at >>>> virtual >>>>>>> address 10003010" on imx27. >>>>>>> >>>>>>> This is due to the call of __ipipe_tsc_get() in >>>> __ipipe_tsc_update() >>>>>>> >>>>>>> To verify my toolchain I have tested 2.6.38.8 with at91 >>>> successfully. >>>>>>> >>>>>>> If someone has a idea? >>>>>> >>>>>> >>>>>> Not enough information, to understand what happens we need the >>>> kernel >>>>>> oops (at least the register values). >>>>>> >>>>>> -- >>>>>> >>>> Gilles. >>>>> >>>>> Sorry, >>>>> >>>>> Unable to handle kernel paging request at virtual address 10003010 >>>>> pgd = c0004000 >>>>> [10003010] *pgd=00000000 >>>>> Internal error: Oops: 5 [#1] PREEMPT >>>>> last sysfs file: >>>>> Modules linked in: >>>>> CPU: 0 Not tainted (2.6.38.8-ipipe #34) >>>>> PC is at 0xffff0f48 >>>>> LR is at __ipipe_tsc_update+0xfc/0x1c0 >>>>> pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 >>>>> sp : c049fe80 ip : c04af0b0 fp : c04af040 >>>>> r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 >>>>> r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 >>>>> r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 >>>> >>>> >>>> Ok. In the mean time I remembered someone signalled this bug and I >>>> fixed it in the patch for 3.4. r0 is supposed to be the address of >> the >>>> hardware timer, 10003010 is a physical address instead of being a >>>> virtual address. Please try the following patch: >>>> >>>> diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c >>>> index 255e759..7a3d6b9 100644 >>>> --- a/arch/arm/plat-mxc/time.c >>>> +++ b/arch/arm/plat-mxc/time.c >>>> @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, >>>> >>>> if (timer_is_v1()) { >>>> tsc_info.u.counter_paddr = phys + MX1_2_TCN; >>>> - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); >>>> + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); >>>> } else { >>>> tsc_info.u.counter_paddr = phys + V2_TCN; >>>> tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); >>>> >>>> >>> >>> It was my patch >> >> >> No, you promised to send a patch for 3.2 and I never received it, so I >> fixed it myself. >> > > Sorry , I was thinking that you only need some test on it, > > Execuse me for it > > Michael The point is: I can not test the patch for imx27 or imx25 because I do not have access to such hardware, so I simply compile-test. Could you check whether the 3.2 branch still has the issues you fixed, and send patches please? I swear they will be merged this time. Last time your patch had issues, I told you that and we never got further. -- Gilles. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 15:15 ` Gilles Chanteperdrix @ 2012-09-01 16:37 ` Michael Trimarchi 0 siblings, 0 replies; 11+ messages in thread From: Michael Trimarchi @ 2012-09-01 16:37 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Hi Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >On 09/01/2012 04:33 PM, Michael Trimarchi wrote: > >> Hi >> >> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >> >>> On 09/01/2012 04:29 PM, Michael Trimarchi wrote: >>> >>>> Hi >>>> >>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> ha scritto: >>>> >>>>> On 09/01/2012 03:50 PM, gwenhael.goavec wrote: >>>>> >>>>>> On Sat, 01 Sep 2012 15:41:55 +0200 >>>>>> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: >>>>>> >>>>>>> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have 2 boards, the first is based on imx1 and the second on >>>>> imx27. >>>>>>>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. >>>>>>>> For the imx1 with 3.2.21 the result is the same. >>>>>>>> >>>>>>>> I have enabled early_printk. On every boards the boot stop with >a >>>>> kernel panic. >>>>>>>> The message start with : "Unable to handle kernel paging >request >>> at >>>>> virtual >>>>>>>> address 10003010" on imx27. >>>>>>>> >>>>>>>> This is due to the call of __ipipe_tsc_get() in >>>>> __ipipe_tsc_update() >>>>>>>> >>>>>>>> To verify my toolchain I have tested 2.6.38.8 with at91 >>>>> successfully. >>>>>>>> >>>>>>>> If someone has a idea? >>>>>>> >>>>>>> >>>>>>> Not enough information, to understand what happens we need the >>>>> kernel >>>>>>> oops (at least the register values). >>>>>>> >>>>>>> -- >>>>>>> >>>>> Gilles. >>>>>> >>>>>> Sorry, >>>>>> >>>>>> Unable to handle kernel paging request at virtual address >10003010 >>>>>> pgd = c0004000 >>>>>> [10003010] *pgd=00000000 >>>>>> Internal error: Oops: 5 [#1] PREEMPT >>>>>> last sysfs file: >>>>>> Modules linked in: >>>>>> CPU: 0 Not tainted (2.6.38.8-ipipe #34) >>>>>> PC is at 0xffff0f48 >>>>>> LR is at __ipipe_tsc_update+0xfc/0x1c0 >>>>>> pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 >>>>>> sp : c049fe80 ip : c04af0b0 fp : c04af040 >>>>>> r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 >>>>>> r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 >>>>>> r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 >>>>> >>>>> >>>>> Ok. In the mean time I remembered someone signalled this bug and I > >>>>> fixed it in the patch for 3.4. r0 is supposed to be the address of >>> the >>>>> hardware timer, 10003010 is a physical address instead of being a >>>>> virtual address. Please try the following patch: >>>>> >>>>> diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c >>>>> index 255e759..7a3d6b9 100644 >>>>> --- a/arch/arm/plat-mxc/time.c >>>>> +++ b/arch/arm/plat-mxc/time.c >>>>> @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, >>>>> >>>>> if (timer_is_v1()) { >>>>> tsc_info.u.counter_paddr = phys + MX1_2_TCN; >>>>> - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); >>>>> + tsc_info.counter_vaddr = (unsigned long)(timer_base + >MX1_2_TCN); >>>>> } else { >>>>> tsc_info.u.counter_paddr = phys + V2_TCN; >>>>> tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); >>>>> >>>>> >>>> >>>> It was my patch >>> >>> >>> No, you promised to send a patch for 3.2 and I never received it, so >I >>> fixed it myself. >>> >> >> Sorry , I was thinking that you only need some test on it, >> >> Execuse me for it >> >> Michael > > >The point is: I can not test the patch for imx27 or imx25 because I do >not have access to such hardware, so I simply compile-test. Could you >check whether the 3.2 branch still has the issues you fixed, and send >patches please? I swear they will be merged this time. > >Last time your patch had issues, I told you that and we never got >further. Ok understand. Let me finish it Michael > >-- > Gilles. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() 2012-09-01 13:54 ` Gilles Chanteperdrix 2012-09-01 14:29 ` Michael Trimarchi @ 2012-09-01 14:32 ` gwenhael.goavec 1 sibling, 0 replies; 11+ messages in thread From: gwenhael.goavec @ 2012-09-01 14:32 UTC (permalink / raw) Cc: xenomai On Sat, 01 Sep 2012 15:54:10 +0200 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: > On 09/01/2012 03:50 PM, gwenhael.goavec wrote: > > > On Sat, 01 Sep 2012 15:41:55 +0200 > > Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: > > > >> On 09/01/2012 03:38 PM, gwenhael.goavec wrote: > >> > >>> Hi, > >>> > >>> I have 2 boards, the first is based on imx1 and the second on imx27. > >>> With this 2 boards, I'm unable to boot a 2.6.38.8 kernel. > >>> For the imx1 with 3.2.21 the result is the same. > >>> > >>> I have enabled early_printk. On every boards the boot stop with a kernel panic. > >>> The message start with : "Unable to handle kernel paging request at virtual > >>> address 10003010" on imx27. > >>> > >>> This is due to the call of __ipipe_tsc_get() in __ipipe_tsc_update() > >>> > >>> To verify my toolchain I have tested 2.6.38.8 with at91 successfully. > >>> > >>> If someone has a idea? > >> > >> > >> Not enough information, to understand what happens we need the kernel > >> oops (at least the register values). > >> > >> -- > >> Gilles. > > > > Sorry, > > > > Unable to handle kernel paging request at virtual address 10003010 > > pgd = c0004000 > > [10003010] *pgd=00000000 > > Internal error: Oops: 5 [#1] PREEMPT > > last sysfs file: > > Modules linked in: > > CPU: 0 Not tainted (2.6.38.8-ipipe #34) > > PC is at 0xffff0f48 > > LR is at __ipipe_tsc_update+0xfc/0x1c0 > > pc : [<ffff0f48>] lr : [<c0032cd4>] psr: 600000d3 > > sp : c049fe80 ip : c04af0b0 fp : c04af040 > > r10: c04af0b0 r9 : c04d5300 r8 : c04d5300 > > r7 : 0000001a r6 : c04c99f8 r5 : ffff0f40 r4 : ffff0f20 > > r3 : 00000000 r2 : 00000000 r1 : c04d5300 r0 : 10003010 > > > Ok. In the mean time I remembered someone signalled this bug and I > fixed it in the patch for 3.4. r0 is supposed to be the address of the > hardware timer, 10003010 is a physical address instead of being a > virtual address. Please try the following patch: > > diff --git a/arch/arm/plat-mxc/time.c b/arch/arm/plat-mxc/time.c > index 255e759..7a3d6b9 100644 > --- a/arch/arm/plat-mxc/time.c > +++ b/arch/arm/plat-mxc/time.c > @@ -352,7 +352,7 @@ mxc_timer_init(struct clk *timer_clk, > > if (timer_is_v1()) { > tsc_info.u.counter_paddr = phys + MX1_2_TCN; > - tsc_info.counter_vaddr =(unsigned long)(phys + MX1_2_TCN); > + tsc_info.counter_vaddr = (unsigned long)(timer_base + MX1_2_TCN); > } else { > tsc_info.u.counter_paddr = phys + V2_TCN; > tsc_info.counter_vaddr = (unsigned long)(timer_base + V2_TCN); > > > -- > Gilles. Perfect! I'm able to boot my imx27. Thank you. Gwenhael ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-09-01 16:37 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-01 13:38 [Xenomai] imx1 and imx27 boot problem with __ipipe_tsc_get() gwenhael.goavec 2012-09-01 13:41 ` Gilles Chanteperdrix 2012-09-01 13:50 ` gwenhael.goavec 2012-09-01 13:54 ` Gilles Chanteperdrix 2012-09-01 14:29 ` Michael Trimarchi 2012-09-01 14:32 ` Gilles Chanteperdrix 2012-09-01 14:33 ` Michael Trimarchi 2012-09-01 14:42 ` Gilles Chanteperdrix 2012-09-01 15:15 ` Gilles Chanteperdrix 2012-09-01 16:37 ` Michael Trimarchi 2012-09-01 14:32 ` gwenhael.goavec
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.