Quantcast
Channel: Processors forum - Recent Threads
Viewing all articles
Browse latest Browse all 17527

Problem with higher CPU Clock frequency(360MHz, 372MHz,420MHz or 444MHz) in OMAPL138

$
0
0

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.

(Please visit the site to view this file)

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


Viewing all articles
Browse latest Browse all 17527

Trending Articles