Hi,
We have made Custom boards using OMAPL138 Chip-set. This Chip-set is rated to operate at 450MHz(CPU Frequency).
Till now we are using this with DaVinci PSP 03.20.00.11 SDK.
- linux version is 2.6.33-rc4
- u-boot version is U-Boot 2009.11
- Compiler version is gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)
The Boards we are using, runs with external clock source as 24MHz.
We are inserting custom modules in the linux which will access uPP module frequently. We are observing two problems
1. uPP underflow error - If clock Source of ASYNC3 domain is kept as PLL1.
2. Random kernel crashes - If clock Source of ASYNC3 domain is kept as PLL0.
If CPU Clock frequency(Sourced from PLL0) is configured to 300MHz, everything is working fine.
But If we move to Higher CPU clock(i.e 360MHz, 372MHz,420MHz or 444MHz), we were seeing uPP under-run problem in most of the boards.
but some boards were working fine without uPP under-run problem even at 444MHz.
By default, in linux, clock Source of ASYNC3 domain was moved from PLL0 to PLL1(in SOURCE_DIR/arch/arm/mach-davinci/da850.c) during linux boot-up. So as a fix for uPP under-run problem, we tried not to move the clock Source of ASYNC3 domain to PLL1 but used PLL0 as clock Source of ASYNC3 domain.
With this change we didn't see any uPP under-run problem, but we are seeing random kernel crashes in all the boards at clock higher than 300Mhz.
One of the crash log has been attached. If we move the ASYNC source from PLL0 to PLL1, then this random crash is not observed, but uPP under-run issue is observed.
Unable to handle kernel NULL pointer dereference at virtual address 00000004 pgd = c0004000 [00000004] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT last sysfs file: /sys/devices/virtual/gpio/gpio67/value Modules linked in: WranNetDrv wran_mac upp I2C_wrapper Timer_module DCXO mmap_app_mac mcbsp_glue EDMA_wrapper Freq_Change [last unloaded: Freq_Change] CPU: 0 Not tainted (2.6.33-rc4 #903) PC is at apply_to_page_range+0x114/0x214 LR is at getnstimeofday+0x80/0xf4 pc : [<c0089194>] lr : [<c0061034>] psr: 20000093 sp : c046bf70 ip : 29aaaa7d fp : 00000000 r10: 00000000 r9 : 41069265 r8 : c046bf90 r7 : c04a8ea0 r6 : 00071270 r5 : 00000000 r4 : ffffffff r3 : 49e655e6 r2 : 00000018 r1 : 00002333 r0 : b7d96b28 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: c6b50000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc046a270) Stack: (0xc046bf70 to 0xc046c000) bf60: c046bfa8 c0472b18 c0027014 c046e3e8 bf80: c04bccd8 41069265 c00255b8 c00610dc 49e655e6 1d164a00 c0472b0c c003a77c bfa0: c0472b18 c0472b88 c046bfb8 c0472b78 c0472b88 c0269318 c046a000 c04a2b5c bfc0: c0027014 c046e3e8 c00255ec c002feac c04aa498 c0008948 c0008488 00000000 bfe0: 00000000 c0027018 00000000 00053175 c04a2c04 c0008034 00000000 00000000 [<c0089194>] (apply_to_page_range+0x114/0x214) from [<c0472b88>] (0xc0472b88) Code: ebfffc62 e3500000 1a000037 e5973000 (e59a0004) 10.10.10.3: seq=---[ end trace eb36b9db90d84c75 ]--- 183 ttl=64 time=Kernel panic - not syncing: Attempted to kill the idle task! 82.236 ms [<c0033640>] (unwind_backtrace+0x0/0xdc) from [<c0347024>] (panic+0x58/0x130) [<c0347024>] (panic+0x58/0x130) from [<c0046224>] (do_exit+0x68/0x694) [<c0046224>] (do_exit+0x68/0x694) from [<c0032554>] (die+0x290/0x2c4) [<c0032554>] (die+0x290/0x2c4) from [<c0034220>] (__do_kernel_fault+0x64/0x74) [<c0034220>] (__do_kernel_fault+0x64/0x74) from [<c00343f4>] (do_page_fault+0x1c4/0x1d8) [<c00343f4>] (do_page_fault+0x1c4/0x1d8) from [<c002e2c0>] (do_DataAbort+0x34/0x94) [<c002e2c0>] (do_DataAbort+0x34/0x94) from [<c002ea6c>] (__dabt_svc+0x4c/0x60) Exception stack(0xc046bf28 to 0xc046bf70) Mac [/Sw/tvws/sathish/dhaval_fw/Wran_stack/ieeemac80222/src/bs/../L1Con/BSModFrameMarker.c BSModFrameMarkerISR:340] : allocDmaRequest returned NULL bf20: b7d96b28 00002333 00000018 49e655e6 ffffffff 00000000 bf40: 00071270 c04a8ea0 c046bf90 41069265 00000000 00000000 29aaaa7d c046bf70 bf60: c0061034 c0089194 20000093 ffffffff [<c002ea6c>] (__dabt_svc+0x4c/0x60) from [<c0089194>] (apply_to_page_range+0x114/0x214) [<c0089194>] (apply_to_page_range+0x114/0x214) from [<c0472b88>] (0xc0472b88)
In summary, problems observed at higher clocks(anything other than 300MHz ):
1. uPP underflow error - If clock Source of ASYNC3 domain is kept as PLL1.
2. Random kernel crashes - If clock Source of ASYNC3 domain is kept as PLL0.
Please let us know if any thing is missed out or anyone has observed similar issues, any pointers to help resolve these issues is highly appreciated.
NOTE:
All Frequency change are verified with the OMAP clocking validation spreadsheet provided in TI website downloaded from
http://processors.wiki.ti.com/index.php/Programming_PLL_Controllers_on_OMAP-L1x8/C674x/AM18xx