Re: OMAP3 migrating: partition / clock
2010/2/8 Paul Walmsley p...@pwsan.com: On Mon, 8 Feb 2010, Arno Steffen wrote: Thanks Paul for your help. Switch on the #define DEBUG in this both files skip almost all kernel boot messages before this warning and gives just this: !?! You probably need to enable CONFIG_DEBUG_LL to see all of the messages. Uncompressing Linux done, booting the kernel. lock: associated clk usbtll_ick to clkdm core_l4_clkdm Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz [ cut here ] WARNING: at arch/arm/mach-omap2/clock34xx.c:773 omap3_noncore_dpll_set_rate+0x1d4/0x308() Modules linked in: [c002a924] (unwind_backtrace+0x0/0xdc) from [c004a168] (warn_slowpath_common+0x48/0x60) I expected to get more messages, not less: You are right, my board is running at 12 instead of 13MHz, but this setting is (or should be) done in uboot. I don't know what this new line withb the lock means. The leading c was apparently dropped. You can recursively grep through the source tree to locate messages, if you are curious as to where they come from. On my board there is no USB at all. If you're not using any of the DPLL5-connected devices (USB, USIM, etc.), what happens if you comment out the omap3_clk_lock_dpll5() call in clock34xx.c? This is not a proper fix, of course, but it may help narrow down the problem. - Paul Thanks Paul! Sorry for bothering you again: Although I set #define DEBUG in clock.c and clock34xx.c and checked that kernel has been new compiled with CONFIG_DEBUG_LL=y the debub messages are quite strange. Uncompressing Linux. done, booting the kernel. kout2_src_ck to clkdm core_clkdm Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz Reprogramming SDRC clock to 33200 Hz GPMC revision 5.0 ... This strange behaviour is just happend if I do a #define DEBUG in clock.c. Changing the debug setting in clock34xx.c has no effect at all ?!? Anyhow there are good news too: I removed the call of omap3_clk_lock_dpll5() and you are right - the message disappers. How did you know that? This call clk_set_rate(dpll5_clk, DPLL5_FREQ_FOR_USBHOST); causes the first message, and thus I assume that dpll5_clk might be wrong, which is get by this command: dpll5_clk = clk_get(NULL, dpll5_ck); I could live with this workaround (remove the call), but have to be sure, that clock is not powered (save energy). Best regards Arno -- 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: OMAP3 migrating: partition / clock
Thanks Paul for your help. Switch on the #define DEBUG in this both files skip almost all kernel boot messages before this warning and gives just this: !?! Uncompressing Linux done, booting the kernel. lock: associated clk usbtll_ick to clkdm core_l4_clkdm Clocking rate (Crystal/Core/MPU): 12.0/332/600 MHz [ cut here ] WARNING: at arch/arm/mach-omap2/clock34xx.c:773 omap3_noncore_dpll_set_rate+0x1d4/0x308() Modules linked in: [c002a924] (unwind_backtrace+0x0/0xdc) from [c004a168] (warn_slowpath_common+0x48/0x60) I expected to get more messages, not less: You are right, my board is running at 12 instead of 13MHz, but this setting is (or should be) done in uboot. I don't know what this new line withb the lock means. On my board there is no USB at all. Regards Arno 2010/2/5 Paul Walmsley p...@pwsan.com: Hello Arno, On Thu, 4 Feb 2010, Arno Steffen wrote: I am trying to migrate from kernel 28 to 32 on TI OMA3. Our board is derived from EVM board. ... Also I do get this warning now while boot: Hierarchical RCU implementation. NR_IRQS:368 Clocking rate (Crystal/Core/MPU): 12.0/332/500 MHz I don't have an 3530 EVM here, but I'd assume this is one difference between your board and the EVM, since TI usually seems to build boards with 26MHz HF clock (resulting in a 13MHz sys_clk). [ cut here ] WARNING: at arch/arm/mach-omap2/clock34xx.c:773 omap3_noncore_dpll_set_rate+0x280/0x2c4() The above lines tell you exactly where to find the code that's emitting the warning. In this case, the problem is that the DPLL rate rounding code picked DPLL parameters that resulted in an invalid jitter correction value (from _omap3_dpll_compute_freqsel()). The caller is presumably omap3_clk_lock_dpll5() in clock34xx.c, which probably got inlined which is why it isn't showing up specifically in the backtrace. I'd first suggest confirming this by changing the '#undef DEBUG' to '#define DEBUG' in clock34xx.c and mach-omap2/clock.c, rebuilding, and sending along the output. If the above hypothesis is confirmed, and the problem is not due to some other bug in the code, it might be necessary to call _omap3_dpll_compute_freqsel() to test the freqsel value in _dpll_test_mult(), and reject values that result in an invalid freqsel. Modules linked in: [c002a924] (unwind_backtrace+0x0/0xdc) from [c0049e74] (warn_slowpath_common+0x48/0x60) [c0049e74] (warn_slowpath_common+0x48/0x60) from [c0033d30] (omap3_noncore_dpll_set_rate+0x280/0x2c4) [c0033d30] (omap3_noncore_dpll_set_rate+0x280/0x2c4) from [c0031674] (omap2_clk_set_rate+0x20/0x2c) [c0031674] (omap2_clk_set_rate+0x20/0x2c) from [c003494c] (clk_set_rate+0x4c/0xb0) [c003494c] (clk_set_rate+0x4c/0xb0) from [c000e980] (omap2_clk_init+0x124/0x1a0) [c000e980] (omap2_clk_init+0x124/0x1a0) from [c000d6ec] (omap2_init_common_hw+0x4c/0xe0) [c000d6ec] (omap2_init_common_hw+0x4c/0xe0) from [c000ead8] (omap3_evm_init_irq+0x28/0x94) [c000ead8] (omap3_evm_init_irq+0x28/0x94) from [c000b1b0] (init_IRQ+0x30/0x40) [c000b1b0] (init_IRQ+0x30/0x40) from [c0008978] (start_kernel+0x140/0x29c) [c0008978] (start_kernel+0x140/0x29c) from [80008034] (0x80008034) ---[ end trace 1b75b31a2719ed1c ]--- Reprogramming SDRC clock to 33200 Hz GPMC revision 5.0 Do you know the reason and how to solve it? Thanks regards Arno - 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: OMAP3 migrating: partition / clock
Hello Arno, On Thu, 4 Feb 2010, Arno Steffen wrote: I am trying to migrate from kernel 28 to 32 on TI OMA3. Our board is derived from EVM board. ... Also I do get this warning now while boot: Hierarchical RCU implementation. NR_IRQS:368 Clocking rate (Crystal/Core/MPU): 12.0/332/500 MHz I don't have an 3530 EVM here, but I'd assume this is one difference between your board and the EVM, since TI usually seems to build boards with 26MHz HF clock (resulting in a 13MHz sys_clk). [ cut here ] WARNING: at arch/arm/mach-omap2/clock34xx.c:773 omap3_noncore_dpll_set_rate+0x280/0x2c4() The above lines tell you exactly where to find the code that's emitting the warning. In this case, the problem is that the DPLL rate rounding code picked DPLL parameters that resulted in an invalid jitter correction value (from _omap3_dpll_compute_freqsel()). The caller is presumably omap3_clk_lock_dpll5() in clock34xx.c, which probably got inlined which is why it isn't showing up specifically in the backtrace. I'd first suggest confirming this by changing the '#undef DEBUG' to '#define DEBUG' in clock34xx.c and mach-omap2/clock.c, rebuilding, and sending along the output. If the above hypothesis is confirmed, and the problem is not due to some other bug in the code, it might be necessary to call _omap3_dpll_compute_freqsel() to test the freqsel value in _dpll_test_mult(), and reject values that result in an invalid freqsel. Modules linked in: [c002a924] (unwind_backtrace+0x0/0xdc) from [c0049e74] (warn_slowpath_common+0x48/0x60) [c0049e74] (warn_slowpath_common+0x48/0x60) from [c0033d30] (omap3_noncore_dpll_set_rate+0x280/0x2c4) [c0033d30] (omap3_noncore_dpll_set_rate+0x280/0x2c4) from [c0031674] (omap2_clk_set_rate+0x20/0x2c) [c0031674] (omap2_clk_set_rate+0x20/0x2c) from [c003494c] (clk_set_rate+0x4c/0xb0) [c003494c] (clk_set_rate+0x4c/0xb0) from [c000e980] (omap2_clk_init+0x124/0x1a0) [c000e980] (omap2_clk_init+0x124/0x1a0) from [c000d6ec] (omap2_init_common_hw+0x4c/0xe0) [c000d6ec] (omap2_init_common_hw+0x4c/0xe0) from [c000ead8] (omap3_evm_init_irq+0x28/0x94) [c000ead8] (omap3_evm_init_irq+0x28/0x94) from [c000b1b0] (init_IRQ+0x30/0x40) [c000b1b0] (init_IRQ+0x30/0x40) from [c0008978] (start_kernel+0x140/0x29c) [c0008978] (start_kernel+0x140/0x29c) from [80008034] (0x80008034) ---[ end trace 1b75b31a2719ed1c ]--- Reprogramming SDRC clock to 33200 Hz GPMC revision 5.0 Do you know the reason and how to solve it? Thanks regards Arno - 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
OMAP3 migrating: partition / clock
I am trying to migrate from kernel 28 to 32 on TI OMA3. Our board is derived from EVM board. In new kernel I can't see the partitions in flash, and found no file to set them. Also I do get this warning now while boot: Hierarchical RCU implementation. NR_IRQS:368 Clocking rate (Crystal/Core/MPU): 12.0/332/500 MHz [ cut here ] WARNING: at arch/arm/mach-omap2/clock34xx.c:773 omap3_noncore_dpll_set_rate+0x280/0x2c4() Modules linked in: [c002a924] (unwind_backtrace+0x0/0xdc) from [c0049e74] (warn_slowpath_common+0x48/0x60) [c0049e74] (warn_slowpath_common+0x48/0x60) from [c0033d30] (omap3_noncore_dpll_set_rate+0x280/0x2c4) [c0033d30] (omap3_noncore_dpll_set_rate+0x280/0x2c4) from [c0031674] (omap2_clk_set_rate+0x20/0x2c) [c0031674] (omap2_clk_set_rate+0x20/0x2c) from [c003494c] (clk_set_rate+0x4c/0xb0) [c003494c] (clk_set_rate+0x4c/0xb0) from [c000e980] (omap2_clk_init+0x124/0x1a0) [c000e980] (omap2_clk_init+0x124/0x1a0) from [c000d6ec] (omap2_init_common_hw+0x4c/0xe0) [c000d6ec] (omap2_init_common_hw+0x4c/0xe0) from [c000ead8] (omap3_evm_init_irq+0x28/0x94) [c000ead8] (omap3_evm_init_irq+0x28/0x94) from [c000b1b0] (init_IRQ+0x30/0x40) [c000b1b0] (init_IRQ+0x30/0x40) from [c0008978] (start_kernel+0x140/0x29c) [c0008978] (start_kernel+0x140/0x29c) from [80008034] (0x80008034) ---[ end trace 1b75b31a2719ed1c ]--- Reprogramming SDRC clock to 33200 Hz GPMC revision 5.0 Do you know the reason and how to solve it? Thanks regards Arno -- 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
