Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Thursday 08 August 2013 11:07 AM, Rajendra Nayak wrote: > On Wednesday 07 August 2013 11:39 PM, Paul Walmsley wrote: >> Hi Rajendra, >> >> On Tue, 23 Jul 2013, Rajendra Nayak wrote: >> >>> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I >>> see >>> the below errors. (I am using the mainline bootloaders which do not lock any >>> additional DPLLs like USB) >> >> Could you please send patches to fix these problems, or ensure that >> someone else from TI fixes them? Let's see if we can deal with the >> remaining bootloader dependencies here. > > Sure Paul, I'll take a look at this. +Mike, Paul, I just posted a fix for this [1] though I am not sure if doing the PLL locks in a certain sequence is the right thing to do, or perhaps there is a need to relook at the need for a clk_set_rate() on all downstream clocks as part of CCF. regards, Rajendra [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93627.html > >> >> thanks >> >> >> - Paul >> >>> >>> [0.00] clock: dpll_usb_ck failed transition to 'locked' >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv0+0x8/0x10) from [] >>> (clk_divider_set_rate+0x10/0x114) >>> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >>> [] (clk_change_rate+0x38/0xb8) >>> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >>> (clk_change_rate+0xa0/0xb8) >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv0+0x8/0x10) from [] >>> (clk_divider_set_rate+0x10/0x114) >>> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >>> [] (clk_change_rate+0x38/0xb8) >>> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >>> (clk_change_rate+0xa0/0xb8) >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv0+0x8/0x10) from [] >>> (clk_divider_set_rate+0x10/0x114) >>> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >>> [] (clk_change_rate+0x38/0xb8) >>> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >>> (clk_change_rate+0xa0/0xb8) >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv0+0x8/0x10) from [] >>> (clk_divider_set_rate+0x10/0x114) >>> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >>> [] (clk_change_rate+0x38/0xb8) >>> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >>> (clk_change_rate+0xa0/0xb8) >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv0+0x8/0x10) from [] >>> (clk_divider_set_rate+0x10/0x114) >>> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >>> [] (clk_change_rate+0x38/0xb8) >>> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >>> (clk_change_rate+0xa0/0xb8) >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv0+0x8/0x10) from [] >>> (clk_divider_set_rate+0x10/0x114) >>> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >>> [] (clk_change_rate+0x38/0xb8) >>> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >>> (clk_change_rate+0xa0/0xb8) >>> [0.00] clock: trace_clk_div_ck: could not find divisor for target >>> rate 0 for parent pmd_trace_clk_mux_ck >>> [0.00] Division by zero in kernel. >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >>> 3.10.0-03445-gfb2af00-dirty #7 >>> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >>> (show_stack+0x10/0x14) >>> [0.00] [] (show_stack+0x10/0x14) from [] >>> (Ldiv0+0x8/0x10) >>> [0.00] [] (Ldiv
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Wednesday 07 August 2013 11:39 PM, Paul Walmsley wrote: > Hi Rajendra, > > On Tue, 23 Jul 2013, Rajendra Nayak wrote: > >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see >> the below errors. (I am using the mainline bootloaders which do not lock any >> additional DPLLs like USB) > > Could you please send patches to fix these problems, or ensure that > someone else from TI fixes them? Let's see if we can deal with the > remaining bootloader dependencies here. Sure Paul, I'll take a look at this. > > thanks > > > - Paul > >> >> [0.00] clock: dpll_usb_ck failed transition to 'locked' >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] clock: trace_clk_div_ck: could not find divisor for target >> rate 0 for parent pmd_trace_clk_mux_ck >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [] >> (Ldiv0+0x8/0x10) >> [0.00] [] (Ldiv0+0x8/0x10) from [] >> (clk_divider_set_rate+0x10/0x114) >> [0.00] [] (clk_divider_set_rate+0x10/0x114) from >> [] (clk_change_rate+0x38/0xb8) >> [0.00] [] (clk_change_rate+0x38/0xb8) from [] >> (clk_change_rate+0xa0/0xb8) >> [0.00] Division by zero in kernel. >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.10.0-03445-gfb2af00-dirty #7 >> [0.00] [] (unwind_backtrace+0x0/0xf4) from [] >> (show_stack+0x10/0x14) >> [0.00] [] (show_stack+0x10/0x14) from [
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Hi Rajendra, On Tue, 23 Jul 2013, Rajendra Nayak wrote: > So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see > the below errors. (I am using the mainline bootloaders which do not lock any > additional DPLLs like USB) Could you please send patches to fix these problems, or ensure that someone else from TI fixes them? Let's see if we can deal with the remaining bootloader dependencies here. thanks - Paul > > [0.00] clock: dpll_usb_ck failed transition to 'locked' > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] clock: trace_clk_div_ck: could not find divisor for target > rate 0 for parent pmd_trace_clk_mux_ck > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_rate+0x38/0xb8) from [] > (clk_change_rate+0xa0/0xb8) > [0.00] Division by zero in kernel. > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.10.0-03445-gfb2af00-dirty #7 > [0.00] [] (unwind_backtrace+0x0/0xf4) from [] > (show_stack+0x10/0x14) > [0.00] [] (show_stack+0x10/0x14) from [] > (Ldiv0+0x8/0x10) > [0.00] [] (Ldiv0+0x8/0x10) from [] > (clk_divider_set_rate+0x10/0x114) > [0.00] [] (clk_divider_set_rate+0x10/0x114) from > [] (clk_change_rate+0x38/0xb8) > [0.00] [] (clk_change_
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Tue, 23 Jul 2013, Jonathan Austin wrote: > I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) in the > hope that we might be able to reproduce this on those boards, but I'm afraid > the integrator works... > > I took your config, modified it as little as possible to switch to Integrator > and turn on earlyprintk, and then tried to boot. That *did* require switching > away from ARCH_MULTIPLATFORM, so it isn't as similar as I'd like, though... > > So I think we can at least say that this is not 1136 specific... Sorry not to > be more helpful... Just saw this message - thanks for the test. What 1136 variant does the Integrator-CP have in it? Would assume an r1 or later? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Hi Will, On Sat, 27 Jul 2013, Will Deacon wrote: > That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've > had issues with the bootloader on this machine in the past, since it enters > the kernel in ABT mode or something). Maybe you're thinking of the (2420-based) Nokia N800? The 2430SDP here uses u-boot: http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/2430sdp/ > Can you try this quick hack please? It clobbers the I-cache as soon as we > enter the kernel, so it should tell us whether my theory is correct. Tried it and still hangs. Spent some time debugging - turns out it's due to the extended CP15 register read in cache_ops_need_broadcast().. the extended regs aren't present on ARM1136 r0* and trigger an undefined instruction abort :-( Sorry about that, should have taken the time to send along an earlyprintk trace. Patches in a few moments - - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Sat, Jul 27, 2013 at 05:10:56AM +0100, Paul Walmsley wrote: > > Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux > colleagues perhaps, and started testing, and eventually wound up with this > one: > > commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc > Author: Will Deacon Oh, great... > Date: Wed Jun 12 12:25:56 2013 +0100 > > ARM: 7757/1: mm: don't flush icache in switch_mm with hardware > broadcasting > > When scheduling an mm on a CPU where it hasn't previously been used, we > flush the icache on that CPU so that any code loaded previously on > a different core can be safely executed. > > For cores with hardware broadcasting of cache maintenance operations, > this is clearly unnecessary, since the inner-shareable invalidation in > __sync_icache_dcache will affect all CPUs. > > This patch conditionalises the icache flush in switch_mm based on > cache_ops_need_broadcast(). > > Acked-by: Catalin Marinas > Reported-by: Albin Tonnerre > Signed-off-by: Will Deacon > Signed-off-by: Russell King > > ... > > v3.11-rc2 boots with it reverted. What also works is v3.11-rc2 with the > below patch applied. That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've had issues with the bootloader on this machine in the past, since it enters the kernel in ABT mode or something). > Would be pleased to boot-test anything you'd care to send my way, as long > as you can tolerate response latency jitter. Can you try this quick hack please? It clobbers the I-cache as soon as we enter the kernel, so it should tell us whether my theory is correct. Cheers, Will --->8 diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 9cf6063..d74c64c 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,6 +83,9 @@ ENTRY(stext) THUMB(.thumb ) @ switch to Thumb now. THUMB(1: ) + mov r9, #0 + mcr p15, 0, r9, c7, c5, 0 + #ifdef CONFIG_ARM_VIRT_EXT bl __hyp_stub_install #endif -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux colleagues perhaps, and started testing, and eventually wound up with this one: commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc Author: Will Deacon Date: Wed Jun 12 12:25:56 2013 +0100 ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting When scheduling an mm on a CPU where it hasn't previously been used, we flush the icache on that CPU so that any code loaded previously on a different core can be safely executed. For cores with hardware broadcasting of cache maintenance operations, this is clearly unnecessary, since the inner-shareable invalidation in __sync_icache_dcache will affect all CPUs. This patch conditionalises the icache flush in switch_mm based on cache_ops_need_broadcast(). Acked-by: Catalin Marinas Reported-by: Albin Tonnerre Signed-off-by: Will Deacon Signed-off-by: Russell King ... v3.11-rc2 boots with it reverted. What also works is v3.11-rc2 with the below patch applied. Would be pleased to boot-test anything you'd care to send my way, as long as you can tolerate response latency jitter. - Paul diff --git a/arch/arm/include/asm/mmu_context.h b/arch/arm/include/asm/mmu_context.h index b5792b7..8dfb295 100644 --- a/arch/arm/include/asm/mmu_context.h +++ b/arch/arm/include/asm/mmu_context.h @@ -112,7 +112,7 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next, * so check for possible thread migration and invalidate the I-cache * if we're new to this CPU. */ - if (cache_ops_need_broadcast() && + if (1 && !cpumask_empty(mm_cpumask(next)) && !cpumask_test_cpu(cpu, mm_cpumask(next))) __flush_icache_all(); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Having worked out how to get around the MMC ordering issue without having to go and re-tweak it should it change again in the future, I've added the SDP back into the build. On Thu, Jul 25, 2013 at 09:50:13AM +0300, Tomi Valkeinen wrote: > On 25/07/13 09:40, Tomi Valkeinen wrote: > > On 24/07/13 17:52, Russell King - ARM Linux wrote: > > > >> I also continue to be disappointed by the lack of things working on the > >> 4430 - it's been a number of years now and _still_ the on-board LCDs do > >> not work. People have tried to blame that on hardware faults and the > >> like, but they're just being idiotic when they say stuff like that. It > >> can't be hardware faults when the kernel supplied with the board is able > >> to make them work to the extent that userspace can play back video on all > >> three output devices simultaneously, without hiccup or any imperfection. > >> I don't know whether it's just that the backlight support isn't working > >> or what - because any information on the 4430 seems to be a tightly > >> controlled secret that only a few select people are permitted to know > >> about. As far as I'm concerned, much of the hardware is a black box to > >> me. > > > > The 4430SDP's backlight hasn't been working in the mainline due to > > missing support from the TWL driver. But we finally did get that in for > > 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the > > backlights. However, the BL doesn't work yet with DT boot, so again with > > 3.11, with no board files, the BL is out... Sigh. > > Ah, sorry, I take that back. Backlight seems to be working fine with 3.11. ... if you know how to configure stuff so it works. It seems that the reason it hasn't been working, and the displays have been remaining blank is because I had no idea that CONFIG_PWM and CONFIG_PWM_TWL were required. I've now added those to the config seed, so hopefully they should start working now. Only taken... what... two years to find that out! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On 25/07/13 09:40, Tomi Valkeinen wrote: > On 24/07/13 17:52, Russell King - ARM Linux wrote: > >> I also continue to be disappointed by the lack of things working on the >> 4430 - it's been a number of years now and _still_ the on-board LCDs do >> not work. People have tried to blame that on hardware faults and the >> like, but they're just being idiotic when they say stuff like that. It >> can't be hardware faults when the kernel supplied with the board is able >> to make them work to the extent that userspace can play back video on all >> three output devices simultaneously, without hiccup or any imperfection. >> I don't know whether it's just that the backlight support isn't working >> or what - because any information on the 4430 seems to be a tightly >> controlled secret that only a few select people are permitted to know >> about. As far as I'm concerned, much of the hardware is a black box to >> me. > > The 4430SDP's backlight hasn't been working in the mainline due to > missing support from the TWL driver. But we finally did get that in for > 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the > backlights. However, the BL doesn't work yet with DT boot, so again with > 3.11, with no board files, the BL is out... Sigh. Ah, sorry, I take that back. Backlight seems to be working fine with 3.11. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On 24/07/13 17:52, Russell King - ARM Linux wrote: > I also continue to be disappointed by the lack of things working on the > 4430 - it's been a number of years now and _still_ the on-board LCDs do > not work. People have tried to blame that on hardware faults and the > like, but they're just being idiotic when they say stuff like that. It > can't be hardware faults when the kernel supplied with the board is able > to make them work to the extent that userspace can play back video on all > three output devices simultaneously, without hiccup or any imperfection. > I don't know whether it's just that the backlight support isn't working > or what - because any information on the 4430 seems to be a tightly > controlled secret that only a few select people are permitted to know > about. As far as I'm concerned, much of the hardware is a black box to > me. The 4430SDP's backlight hasn't been working in the mainline due to missing support from the TWL driver. But we finally did get that in for 3.10 (or maybe 3.9), and booting 3.10 non-DT kernel brings up the backlights. However, the BL doesn't work yet with DT boot, so again with 3.11, with no board files, the BL is out... Sigh. The panel driver itself have been working as long as it has been in the mainline kernel (for me). I think there was a mixup at some point with pinmuxing due to TRM having wrong information, but for some reason my board works fine with both right and wrong muxing. If I recall right, your board did not. But that's also solved some kernel versions ago. But even with the above fixed, you could observe that your panel doesn't work. The reason is that the panels in the 4430SDP board were chosen a bit oddly: they are so called manual update panels, meant to be explicitly updated by the software only when required. The phones that have such panels (which, I guess, is what 4430SDP is designed to resemble) have software doing that, but obviously the standard linux software does not. There's a hack to enable a non-optimal automatic update for testing purposes: echo 1 > /sys/class/graphics/fb0/update_mode This makes omapfb update the display 20 times per second. Or via a module parameter: omapfb.auto_update=y We could implement a better auto-update system for manual-update panels, but I have opted not to: - It's not easy to implement efficiently and reliably (in fact, we did have auto-update support at some point in the kernel, but it was removed as it was rather troublesome to keep working). - Manual-update panels are meant to be updated manually, only when needed. That's the whole point of the manual-update feature. Doing auto-update with a manual-update panel is inefficient. So such a feature would only be useful for testing purposes. - Manual-update panels are quite rare, and the trend to use them seems to be coming even rarer. > And yes, my 4430 has the projector module on it. Never ever seen that > work, and no idea how to make it work because there's no information > available on the hardware. I don't have that one. PicoDLP shares resources (DSS pins, at least, if I recall right, and some power line) with the second LCD, and we don't have support to manage sharing those resources. So the PicoDLP is left disabled in the board file. I don't have any clear idea how to implement management of those resources, and no one has ever asked about PicoDLP from me, so it's never been a very high priority. So 4430SDP is a bit difficult on the display side: non-standard panels and a pico projector that is mutually exclusive with the LCD2. > And no, I don't want another Beagle board or Panda board or whatever, I > have those (I think I have one of each), and they've never been powered up > because they have no ethernet on them, and I have no USB to ethernet still, > partly because I don't really do USB here *at* *all*, so I don't know what > works well and what doesn't with Linux. Even if I did provide them with a > USB ethernet, I doubt they'd be able to boot a kernel via the network. Beagle xM and Panda have ethernet. I boot Panda via the network (load kernel and use nfsroot). But they don't have panels, so you need an external display for those. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after Linus' rmk merge)
On Wednesday 24 July 2013 01:23 PM, Russell King - ARM Linux wrote: > On Wed, Jul 24, 2013 at 11:40:33AM -0400, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote: >>> I also continue to be disappointed by the lack of things working on the >>> 4430 - it's been a number of years now and _still_ the on-board LCDs do >>> not work. People have tried to blame that on hardware faults and the >>> like, but they're just being idiotic when they say stuff like that. It >>> can't be hardware faults when the kernel supplied with the board is able >>> to make them work to the extent that userspace can play back video on all >>> three output devices simultaneously, without hiccup or any imperfection. >>> I don't know whether it's just that the backlight support isn't working >>> or what - because any information on the 4430 seems to be a tightly >>> controlled secret that only a few select people are permitted to know >>> about. As far as I'm concerned, much of the hardware is a black box to >>> me. >>> >> On the display related issues, Tomi and Archit have been sorting out >> issue but am not sure about the current state. If the pre-built binaries >> video playback works means your hardware seems to be fine. > > Just let me be absolutely crystal clear about this: the on-board LCDs > have _never_ worked with a mainline kernel, but they did work with the > kernel which originally came with the board with the original 4430 SoC. > I can right now put the original 4430 SoC back on the board and boot > using the kernel which is still on the SD card and they will work. > > Even with the original 4430 SoC and mainline kernels, they have never > worked. > > I tried it back and forth several times, but even with this, the > explanation was always "your hardware must be faulty". And then the wrong > voltage levels was found which was preventing the LCD modules from even > being recognised... but still, no sign of life on the LCD panels. > > It may be that there's some error in the kernel configuration I'm building. > I don't know, because I have _no_ idea what hardware is involved in > bringing the LCDs online. Like I said above, the 4430SDP board is just > a black box. I am totally reliant on others telling me what the right > config options are supposed to be and fixing problems when things don't > work. > > With the lack of information on this board, all I can do when things don't > work is whinge and moan at people. I am powerless to debug the problems > myself, even if they're a simple misconfiguration. > > Is there information available on the 4430SDP? Is there any reason I > can't have access to it? > I haven't come across the information which is available on the web. Let me check if there are schematics which i can send across to you. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after Linus' rmk merge)
On Wed, Jul 24, 2013 at 11:40:33AM -0400, Santosh Shilimkar wrote: > On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote: > > I also continue to be disappointed by the lack of things working on the > > 4430 - it's been a number of years now and _still_ the on-board LCDs do > > not work. People have tried to blame that on hardware faults and the > > like, but they're just being idiotic when they say stuff like that. It > > can't be hardware faults when the kernel supplied with the board is able > > to make them work to the extent that userspace can play back video on all > > three output devices simultaneously, without hiccup or any imperfection. > > I don't know whether it's just that the backlight support isn't working > > or what - because any information on the 4430 seems to be a tightly > > controlled secret that only a few select people are permitted to know > > about. As far as I'm concerned, much of the hardware is a black box to > > me. > > > On the display related issues, Tomi and Archit have been sorting out > issue but am not sure about the current state. If the pre-built binaries > video playback works means your hardware seems to be fine. Just let me be absolutely crystal clear about this: the on-board LCDs have _never_ worked with a mainline kernel, but they did work with the kernel which originally came with the board with the original 4430 SoC. I can right now put the original 4430 SoC back on the board and boot using the kernel which is still on the SD card and they will work. Even with the original 4430 SoC and mainline kernels, they have never worked. I tried it back and forth several times, but even with this, the explanation was always "your hardware must be faulty". And then the wrong voltage levels was found which was preventing the LCD modules from even being recognised... but still, no sign of life on the LCD panels. It may be that there's some error in the kernel configuration I'm building. I don't know, because I have _no_ idea what hardware is involved in bringing the LCDs online. Like I said above, the 4430SDP board is just a black box. I am totally reliant on others telling me what the right config options are supposed to be and fixing problems when things don't work. With the lack of information on this board, all I can do when things don't work is whinge and moan at people. I am powerless to debug the problems myself, even if they're a simple misconfiguration. Is there information available on the 4430SDP? Is there any reason I can't have access to it? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4430 SDP boot issues.. (Was Re: OMAP2430 SDP boot broken after Linus' rmk merge)
On Wednesday 24 July 2013 10:52 AM, Russell King - ARM Linux wrote: > On Wed, Jul 24, 2013 at 10:17:01AM -0400, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote: >>> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote: On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: [..] > I don't have a 4430SDP, so you might consider touching base with rmk for > that one. So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB) >>> >>> Any update on this? If it's an issue introduced by architectural changes, >>> I'd really like to bisect it down but I don't have a board. >>> >> >From the other thread, RMK did manage to get the board booting finally >> (uImage related issues, low level debug problem) but with DT only supported >> build, the audio and DSS was not at same state as before(non-DT build). >> And then Tony pointed the issues to Peter and Tomy to address it further. >> >> Russell, >> Is above right or I am missing something ? > > Will is referring to the 2430 issues I think; the original topic of this > thread. > We crossed the emails. Am just renaming the thread since below summary is still important for OMAP4430SDP. > I've not enabled the 4430 again in the build system because I see no point > to it - it can't find its rootfs because the device numbering for the MMC/SD > cards has reversed itself. Not only does that need the kernel command line > changed, but it also needs fixing in the fstab on the SD card rootfs, and > quite frankly I really can't be bothered at the moment with this kind of > pointless boot breaking churn. > The MMC slot change has also troubled us in past in downstream kernel. Am looping Balaji to see if he can fix it to restore the original ordering. > I also continue to be disappointed by the lack of things working on the > 4430 - it's been a number of years now and _still_ the on-board LCDs do > not work. People have tried to blame that on hardware faults and the > like, but they're just being idiotic when they say stuff like that. It > can't be hardware faults when the kernel supplied with the board is able > to make them work to the extent that userspace can play back video on all > three output devices simultaneously, without hiccup or any imperfection. > I don't know whether it's just that the backlight support isn't working > or what - because any information on the 4430 seems to be a tightly > controlled secret that only a few select people are permitted to know > about. As far as I'm concerned, much of the hardware is a black box to > me. > On the display related issues, Tomi and Archit have been sorting out issue but am not sure about the current state. If the pre-built binaries video playback works means your hardware seems to be fine. > And yes, my 4430 has the projector module on it. Never ever seen that > work, and no idea how to make it work because there's no information > available on the hardware. > I think you mean the Pico DLP module. There was a downstream driver but am not sure about the state. Archit, Tomi should be able to comment. > It's a bit like the useless 3430LDP - though there's information available > there's no way to work out which of the many different designs of 3430LDP > the one I have ties up with, and I'm pretty sure that all the published > revisions of the circuits for the 3430LDP do not match the version I have > here - which means when things go wrong, there's no way for me to look > at stuff. > > And no, I don't want another Beagle board or Panda board or whatever, I > have those (I think I have one of each), and they've never been powered up > because they have no ethernet on them, and I have no USB to ethernet still, > partly because I don't really do USB here *at* *all*, so I don't know what > works well and what doesn't with Linux. Even if I did provide them with a > USB ethernet, I doubt they'd be able to boot a kernel via the network. > We discussed the LDP issue in past. That board is almost dead since almost no one from TI is using/having it anymore. > My experience of USB is hellishly poor - I have an icybox eSATA enclosure > which also provides USB. The USB interface on that regularly drops out > with errors, timeouts, and even isn't recognised on many occasions. I > see slow serial comms with USB serial devices on platforms like the > 4430SDP and Dove Cubox - the speed is very much like a 4800baud modem, even > though the serial runs at 115200 baud. No, don't even _think_ about blaming > the host, because this happens whether it be a Thinkpad, or the USB hosts > in a Thecus N2100. > > I can believe why this all happens, when you see USB interrupts taking > upwards of 3ms to complete: > > Longest time: 3247506ns > Longest irq: 24 > Longest handler: usb_hcd_irq+0x0/0x68 > > is it hardly surprisi
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Wed, Jul 24, 2013 at 10:17:01AM -0400, Santosh Shilimkar wrote: > On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote: > > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote: > >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: > >>> Hi Rajendra, > >>> > >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote: > >>> > On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: > > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > > > >> Bear in mind that I'm almost at the point of not boot-testing anything > >> I sent to Linus because of the uselessness of the SDP4430 board now > >> that it's DT only - the only platform which boot-tests anything I send > >> is the 3430LDP board now. If people care about that, maybe they can > >> assist with sorting out the issues I've raised on these lists about > >> the SDP4430 - and why the SDP4430 build remains disabled in my build > >> and boot system. > > > > I understand completely... > > > >> Looking at the boot log, it just stops after uboot hands over control. > >> With the lack of output from the decompressor, it's not possible to > >> tell whether it's a decompressor problem or a kernel problem. > >> > >> I think you need to turn on the LL_DEBUG option, select the appropriate > >> output option, and also get the decompressor to use the kernel's debug > >> io functions to output it's stuff (I think the option is > >> DEBUG_UNCOMPRESS). > > > > OK, will dig deeper here at the next opportunity. > > Paul, I can take a look at the 4430sdp issue. Are you also seeing this > also on > 2430sdp as the subject says, or was that a typo? > >>> > >>> Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my > >>> testbed. > >>> > >>> I don't have a 4430SDP, so you might consider touching base with rmk for > >>> that one. > >> > >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I > >> see > >> the below errors. (I am using the mainline bootloaders which do not lock > >> any > >> additional DPLLs like USB) > > > > Any update on this? If it's an issue introduced by architectural changes, > > I'd really like to bisect it down but I don't have a board. > > > >From the other thread, RMK did manage to get the board booting finally > (uImage related issues, low level debug problem) but with DT only supported > build, the audio and DSS was not at same state as before(non-DT build). > And then Tony pointed the issues to Peter and Tomy to address it further. > > Russell, > Is above right or I am missing something ? Will is referring to the 2430 issues I think; the original topic of this thread. I've not enabled the 4430 again in the build system because I see no point to it - it can't find its rootfs because the device numbering for the MMC/SD cards has reversed itself. Not only does that need the kernel command line changed, but it also needs fixing in the fstab on the SD card rootfs, and quite frankly I really can't be bothered at the moment with this kind of pointless boot breaking churn. I also continue to be disappointed by the lack of things working on the 4430 - it's been a number of years now and _still_ the on-board LCDs do not work. People have tried to blame that on hardware faults and the like, but they're just being idiotic when they say stuff like that. It can't be hardware faults when the kernel supplied with the board is able to make them work to the extent that userspace can play back video on all three output devices simultaneously, without hiccup or any imperfection. I don't know whether it's just that the backlight support isn't working or what - because any information on the 4430 seems to be a tightly controlled secret that only a few select people are permitted to know about. As far as I'm concerned, much of the hardware is a black box to me. And yes, my 4430 has the projector module on it. Never ever seen that work, and no idea how to make it work because there's no information available on the hardware. It's a bit like the useless 3430LDP - though there's information available there's no way to work out which of the many different designs of 3430LDP the one I have ties up with, and I'm pretty sure that all the published revisions of the circuits for the 3430LDP do not match the version I have here - which means when things go wrong, there's no way for me to look at stuff. And no, I don't want another Beagle board or Panda board or whatever, I have those (I think I have one of each), and they've never been powered up because they have no ethernet on them, and I have no USB to ethernet still, partly because I don't really do USB here *at* *all*, so I don't know what works well and what doesn't with Linux. Even if I did provide them with a USB ethernet, I doubt they'd be able to boot a kernel via the network. My experience of USB is hellishly poor - I have an icybox eSATA enclos
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Wednesday 24 July 2013 10:20 AM, Will Deacon wrote: > On Wed, Jul 24, 2013 at 03:17:01PM +0100, Santosh Shilimkar wrote: >> On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote: >>> On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote: On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: > Hi Rajendra, > > On Tue, 23 Jul 2013, Rajendra Nayak wrote: > >> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: >>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: >>> Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system. >>> >>> I understand completely... >>> Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem. I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). >>> >>> OK, will dig deeper here at the next opportunity. >> >> Paul, I can take a look at the 4430sdp issue. Are you also seeing this >> also on >> 2430sdp as the subject says, or was that a typo? > > Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my > testbed. > > I don't have a 4430SDP, so you might consider touching base with rmk for > that one. So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB) >>> >>> Any update on this? If it's an issue introduced by architectural changes, >>> I'd really like to bisect it down but I don't have a board. >>> >> From the other thread, RMK did manage to get the board booting finally >> (uImage related issues, low level debug problem) but with DT only supported >> build, the audio and DSS was not at same state as before(non-DT build). >> And then Tony pointed the issues to Peter and Tomy to address it further. >> >> Russell, >> Is above right or I am missing something ? > > I thought that was the 4430 from before the merge window. Ths issue here is > the 2430 running mainline, as reported by Paul > Actually thread got hijacked a bit when Rajendra replied the OMAP4430 results. I then replied on top of that. Sorry about that Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Wed, Jul 24, 2013 at 03:17:01PM +0100, Santosh Shilimkar wrote: > On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote: > > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote: > >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: > >>> Hi Rajendra, > >>> > >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote: > >>> > On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: > > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > > > >> Bear in mind that I'm almost at the point of not boot-testing anything > >> I sent to Linus because of the uselessness of the SDP4430 board now > >> that it's DT only - the only platform which boot-tests anything I send > >> is the 3430LDP board now. If people care about that, maybe they can > >> assist with sorting out the issues I've raised on these lists about > >> the SDP4430 - and why the SDP4430 build remains disabled in my build > >> and boot system. > > > > I understand completely... > > > >> Looking at the boot log, it just stops after uboot hands over control. > >> With the lack of output from the decompressor, it's not possible to > >> tell whether it's a decompressor problem or a kernel problem. > >> > >> I think you need to turn on the LL_DEBUG option, select the appropriate > >> output option, and also get the decompressor to use the kernel's debug > >> io functions to output it's stuff (I think the option is > >> DEBUG_UNCOMPRESS). > > > > OK, will dig deeper here at the next opportunity. > > Paul, I can take a look at the 4430sdp issue. Are you also seeing this > also on > 2430sdp as the subject says, or was that a typo? > >>> > >>> Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my > >>> testbed. > >>> > >>> I don't have a 4430SDP, so you might consider touching base with rmk for > >>> that one. > >> > >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I > >> see > >> the below errors. (I am using the mainline bootloaders which do not lock > >> any > >> additional DPLLs like USB) > > > > Any update on this? If it's an issue introduced by architectural changes, > > I'd really like to bisect it down but I don't have a board. > > > From the other thread, RMK did manage to get the board booting finally > (uImage related issues, low level debug problem) but with DT only supported > build, the audio and DSS was not at same state as before(non-DT build). > And then Tony pointed the issues to Peter and Tomy to address it further. > > Russell, > Is above right or I am missing something ? I thought that was the 4430 from before the merge window. Ths issue here is the 2430 running mainline, as reported by Paul Will -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Wednesday 24 July 2013 09:56 AM, Will Deacon wrote: > On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote: >> On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: >>> Hi Rajendra, >>> >>> On Tue, 23 Jul 2013, Rajendra Nayak wrote: >>> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > >> Bear in mind that I'm almost at the point of not boot-testing anything >> I sent to Linus because of the uselessness of the SDP4430 board now >> that it's DT only - the only platform which boot-tests anything I send >> is the 3430LDP board now. If people care about that, maybe they can >> assist with sorting out the issues I've raised on these lists about >> the SDP4430 - and why the SDP4430 build remains disabled in my build >> and boot system. > > I understand completely... > >> Looking at the boot log, it just stops after uboot hands over control. >> With the lack of output from the decompressor, it's not possible to >> tell whether it's a decompressor problem or a kernel problem. >> >> I think you need to turn on the LL_DEBUG option, select the appropriate >> output option, and also get the decompressor to use the kernel's debug >> io functions to output it's stuff (I think the option is >> DEBUG_UNCOMPRESS). > > OK, will dig deeper here at the next opportunity. Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo? >>> >>> Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my >>> testbed. >>> >>> I don't have a 4430SDP, so you might consider touching base with rmk for >>> that one. >> >> So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see >> the below errors. (I am using the mainline bootloaders which do not lock any >> additional DPLLs like USB) > > Any update on this? If it's an issue introduced by architectural changes, > I'd really like to bisect it down but I don't have a board. > >From the other thread, RMK did manage to get the board booting finally (uImage related issues, low level debug problem) but with DT only supported build, the audio and DSS was not at same state as before(non-DT build). And then Tony pointed the issues to Peter and Tomy to address it further. Russell, Is above right or I am missing something ? Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Tue, Jul 23, 2013 at 10:05:17AM +0100, Rajendra Nayak wrote: > On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: > > Hi Rajendra, > > > > On Tue, 23 Jul 2013, Rajendra Nayak wrote: > > > >> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: > >>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > >>> > Bear in mind that I'm almost at the point of not boot-testing anything > I sent to Linus because of the uselessness of the SDP4430 board now > that it's DT only - the only platform which boot-tests anything I send > is the 3430LDP board now. If people care about that, maybe they can > assist with sorting out the issues I've raised on these lists about > the SDP4430 - and why the SDP4430 build remains disabled in my build > and boot system. > >>> > >>> I understand completely... > >>> > Looking at the boot log, it just stops after uboot hands over control. > With the lack of output from the decompressor, it's not possible to > tell whether it's a decompressor problem or a kernel problem. > > I think you need to turn on the LL_DEBUG option, select the appropriate > output option, and also get the decompressor to use the kernel's debug > io functions to output it's stuff (I think the option is > DEBUG_UNCOMPRESS). > >>> > >>> OK, will dig deeper here at the next opportunity. > >> > >> Paul, I can take a look at the 4430sdp issue. Are you also seeing this > >> also on > >> 2430sdp as the subject says, or was that a typo? > > > > Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my > > testbed. > > > > I don't have a 4430SDP, so you might consider touching base with rmk for > > that one. > > So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see > the below errors. (I am using the mainline bootloaders which do not lock any > additional DPLLs like USB) Any update on this? If it's an issue introduced by architectural changes, I'd really like to bisect it down but I don't have a board. Will -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Hi Paul,
On 22/07/13 19:07, Paul Walmsley wrote:
Hi,
After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge
branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the
OMAP2430 SDP here stopped booting.
Here's the bootlog at the commit before the merge, commit 790eac5640:
http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
and here's a log at commit fb2af0020a5:
http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
Any ideas as to what might have caused this?
I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136)
in the hope that we might be able to reproduce this on those boards, but
I'm afraid the integrator works...
I took your config, modified it as little as possible to switch to
Integrator and turn on earlyprintk, and then tried to boot. That *did*
require switching away from ARCH_MULTIPLATFORM, so it isn't as similar
as I'd like, though...
So I think we can at least say that this is not 1136 specific... Sorry
not to be more helpful...
Jonny
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: > Hi Rajendra, > > On Tue, 23 Jul 2013, Rajendra Nayak wrote: > >> On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: >>> On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: >>> Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system. >>> >>> I understand completely... >>> Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem. I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). >>> >>> OK, will dig deeper here at the next opportunity. >> >> Paul, I can take a look at the 4430sdp issue. Are you also seeing this also >> on >> 2430sdp as the subject says, or was that a typo? > > Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my > testbed. > > I don't have a 4430SDP, so you might consider touching base with rmk for > that one. So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB) [0.00] clock: dpll_usb_ck failed transition to 'locked' [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (Ldiv0+0x8/0x10) [0.00] [] (Ldiv0+0x8/0x10) from [] (clk_divider_set_rate+0x10/0x114) [0.00] [] (clk_divider_set_rate+0x10/0x114) from [] (clk_change_rate+0x38/0xb8) [0.00] [] (clk_change_rate+0x38/0xb8) from [] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (Ldiv0+0x8/0x10) [0.00] [] (Ldiv0+0x8/0x10) from [] (clk_divider_set_rate+0x10/0x114) [0.00] [] (clk_divider_set_rate+0x10/0x114) from [] (clk_change_rate+0x38/0xb8) [0.00] [] (clk_change_rate+0x38/0xb8) from [] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (Ldiv0+0x8/0x10) [0.00] [] (Ldiv0+0x8/0x10) from [] (clk_divider_set_rate+0x10/0x114) [0.00] [] (clk_divider_set_rate+0x10/0x114) from [] (clk_change_rate+0x38/0xb8) [0.00] [] (clk_change_rate+0x38/0xb8) from [] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (Ldiv0+0x8/0x10) [0.00] [] (Ldiv0+0x8/0x10) from [] (clk_divider_set_rate+0x10/0x114) [0.00] [] (clk_divider_set_rate+0x10/0x114) from [] (clk_change_rate+0x38/0xb8) [0.00] [] (clk_change_rate+0x38/0xb8) from [] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (Ldiv0+0x8/0x10) [0.00] [] (Ldiv0+0x8/0x10) from [] (clk_divider_set_rate+0x10/0x114) [0.00] [] (clk_divider_set_rate+0x10/0x114) from [] (clk_change_rate+0x38/0xb8) [0.00] [] (clk_change_rate+0x38/0xb8) from [] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [0.00] [] (show_stack+0x10/0x14) from [] (Ldiv0+0x8/0x10) [0.00] [] (Ldiv0+0x8/0x10) from [] (clk_divider_set_rate+0x10/0x114) [0.00] [] (clk_divider_set_rate+0x10/0x114) from [] (clk_change_rate+0x38/0xb8) [0.00] [] (clk_change_rate+0x38/0xb8) from [] (clk_change_rate+0xa0/0xb8) [0.
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Hi Rajendra, On Tue, 23 Jul 2013, Rajendra Nayak wrote: > On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: > > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > > > >> Bear in mind that I'm almost at the point of not boot-testing anything > >> I sent to Linus because of the uselessness of the SDP4430 board now > >> that it's DT only - the only platform which boot-tests anything I send > >> is the 3430LDP board now. If people care about that, maybe they can > >> assist with sorting out the issues I've raised on these lists about > >> the SDP4430 - and why the SDP4430 build remains disabled in my build > >> and boot system. > > > > I understand completely... > > > >> Looking at the boot log, it just stops after uboot hands over control. > >> With the lack of output from the decompressor, it's not possible to > >> tell whether it's a decompressor problem or a kernel problem. > >> > >> I think you need to turn on the LL_DEBUG option, select the appropriate > >> output option, and also get the decompressor to use the kernel's debug > >> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). > > > > OK, will dig deeper here at the next opportunity. > > Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on > 2430sdp as the subject says, or was that a typo? Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed. I don't have a 4430SDP, so you might consider touching base with rmk for that one. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: > On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > >> Bear in mind that I'm almost at the point of not boot-testing anything >> I sent to Linus because of the uselessness of the SDP4430 board now >> that it's DT only - the only platform which boot-tests anything I send >> is the 3430LDP board now. If people care about that, maybe they can >> assist with sorting out the issues I've raised on these lists about >> the SDP4430 - and why the SDP4430 build remains disabled in my build >> and boot system. > > I understand completely... > >> Looking at the boot log, it just stops after uboot hands over control. >> With the lack of output from the decompressor, it's not possible to >> tell whether it's a decompressor problem or a kernel problem. >> >> I think you need to turn on the LL_DEBUG option, select the appropriate >> output option, and also get the decompressor to use the kernel's debug >> io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). > > OK, will dig deeper here at the next opportunity. Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo? > > > - Paul > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: > Bear in mind that I'm almost at the point of not boot-testing anything > I sent to Linus because of the uselessness of the SDP4430 board now > that it's DT only - the only platform which boot-tests anything I send > is the 3430LDP board now. If people care about that, maybe they can > assist with sorting out the issues I've raised on these lists about > the SDP4430 - and why the SDP4430 build remains disabled in my build > and boot system. I understand completely... > Looking at the boot log, it just stops after uboot hands over control. > With the lack of output from the decompressor, it's not possible to > tell whether it's a decompressor problem or a kernel problem. > > I think you need to turn on the LL_DEBUG option, select the appropriate > output option, and also get the decompressor to use the kernel's debug > io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). OK, will dig deeper here at the next opportunity. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
On Mon, Jul 22, 2013 at 06:07:47PM +, Paul Walmsley wrote:
> After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge
> branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the
> OMAP2430 SDP here stopped booting.
>
> Here's the bootlog at the commit before the merge, commit 790eac5640:
>
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
>
> and here's a log at commit fb2af0020a5:
>
> http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
>
> Any ideas as to what might have caused this?
Bear in mind that I'm almost at the point of not boot-testing anything
I sent to Linus because of the uselessness of the SDP4430 board now
that it's DT only - the only platform which boot-tests anything I send
is the 3430LDP board now. If people care about that, maybe they can
assist with sorting out the issues I've raised on these lists about
the SDP4430 - and why the SDP4430 build remains disabled in my build
and boot system.
Looking at the boot log, it just stops after uboot hands over control.
With the lack of output from the decompressor, it's not possible to
tell whether it's a decompressor problem or a kernel problem.
I think you need to turn on the LL_DEBUG option, select the appropriate
output option, and also get the decompressor to use the kernel's debug
io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP2430 SDP boot broken after Linus' rmk merge
Hi,
After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 ("Merge
branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm"), the
OMAP2430 SDP here stopped booting.
Here's the bootlog at the commit before the merge, commit 790eac5640:
http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/
and here's a log at commit fb2af0020a5:
http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/
Any ideas as to what might have caused this?
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
