Paul Another problem: >Sent: Thursday, December 20, 2007 3:53 PM > >> Tried and ES2.0 boots now. > >Great, thanks for your help. I'll respin those patches with the fix >included. Another problem I am observing in your clock patch is that occasionally there is a crash as follows in dm timer: [SNIP] <7>cm_write_reg: writing 0x3ffff to 0xd8005010 <7>cm_write_reg: writing 0x3fff7 to 0xd8005000 <7>clock: in omap2_get_clksel_by_parent: clk gpt2_fck <7>clock: in omap2_get_clksel_by_parent: looking for parent clk omap_32k_fck <7>clock: set parent of gpt2_fck to omap_32k_fck (new rate 32768) <7>cm_write_reg: writing 0x3ffff to 0xd8005000 <1>Unhandled fault: external abort on non-linefetch (0x1028) at 0xd9032010 Internal error: : 1028 [#1] Modules linked in: CPU: 0 Not tainted (2.6.24-rc5-omap1-g047c6b0c-dirty #52) PC is at omap_dm_timer_reset+0x78/0xbc LR is at omap_dm_timer_set_source+0x48/0x54 pc : [<c003ed34>] lr : [<c003ecb0>] psr: 600001d3 sp : c02bff40 ip : c02c9840 fp : c02bff54 r10: c02c419c r9 : 411fc081 r8 : 80020634 r7 : 00000000 r6 : c02c41c0 r5 : 89705f41 r4 : c02c923c r3 : d9032000 r2 : c02c9224 r1 : d8005000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004018 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc02be2d8) Stack: (0xc02bff40 to 0xc02c0000) ff40: c02c923c 89705f41 c02bff6c c02bff58 c003ed98 c003ecc8 c005f9f4 c02c923c ff60: c02bff84 c02bff70 c003ee00 c003ed84 00c65d40 36b4a597 c02bffb4 c02bff88 ff80: c0011638 c003eda8 c02bffc4 c02e3404 c02e3410 c0021f28 c02c1d68 80020634 ffa0: 411fc081 0000001f c02bffc4 c02bffb8 c000f8fc c001154c c02bfff4 c02bffc8 ffc0: c0008c74 c000f8ec c0008544 00000000 00000000 c0021f28 00000000 00c5387d ffe0: c02e3d10 c002232c 00000000 c02bfff8 80008034 c0008b18 00000000 00000000 Backtrace: [<c003ecbc>] (omap_dm_timer_reset+0x0/0xbc) from [<c003ed98>] (omap_dm_timer_prepare+0x20/0x24) r5:89705f41 r4:c02c923c [<c003ed78>] (omap_dm_timer_prepare+0x0/0x24) from [<c003ee00>] (omap_dm_timer_request+0x64/0x70) r4:c02c923c [<c003ed9c>] (omap_dm_timer_request+0x0/0x70) from [<c0011638>] (omap2_gp_timer_init+0xf8/0x1e0) r4:36b4a597 [<c0011540>] (omap2_gp_timer_init+0x0/0x1e0) from [<c000f8fc>] (time_init+0x1c/0x24) [<c000f8e0>] (time_init+0x0/0x24) from [<c0008c74>] (start_kernel+0x168/0x2b4) [<c0008b0c>] (start_kernel+0x0/0x2b4) from [<80008034>] (0x80008034) r6:c002232c r5:c02e3d10 r4:00c5387d Code: ebffffcf e59f203c e5943010 e5922000 (e5933010) <0>Kernel panic - not syncing: Attempted to kill the idle task! ------- Possible Root Cause: The GPT2 f-clk and i-clk are not getting enabled properly. For the clocks: gpt1_fck and gpt1_ick I don't see the function omap2_wait_clock_ready() getting called, that checks the status of GPT2 clocks is good or not. Function omap2_clk_wait_ready() is getting called but due to the checks in this function, the function omap2_wait_clock_ready() does not get called. As a result the clocks are still not enabled and a register access causes a crash. Please check > > >- Paul - To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
