Ah, very interesting.

> dmesg | grep clock
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.309448] omap_hwmod: l4_div_ck: missing clockdomain for l4_div_ck.
[    0.716979] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    1.001129] Switching to clocksource 32k_counter
[    6.907501] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:01 UTC (946684801)

Do you recommend using "Get linaro image tools: method 2 (source code)" ( http://releases.linaro.org/12.01/ubuntu/leb-panda/ ) and building the kernel myself? I think we're, for the most part, unconcerned with power usage for our application (we're robotics researchers and, I believe, computation is only a small fraction of the power draw when compared to the motors).

It seems to me that we would want to disable some of the power-saving changes that have been made, such as this timer, and possibly configure other settings like cache behavior, though I have no idea how they're currently set. I have a bunch of docs from ARM on power and cache config, but I haven't messed around with them as I'm not sure where to start. My best guess is that I would have to rebuild the kernel to start handling that configuration myself. Is that true?

Some people ( http://groups.google.com/group/pandaboard/browse_thread/thread/a18fa3514d130720 ) have mentioned enabling line fill and prefetching to speed up memcpy operations, which also seems useful. Is this also a kernel-level setting?

If you think that's the right route, I would appreciate advice on where, within the build process, I need to start changing things to get the settings I want.

Many thanks,
Andrew



On Feb 8, 2012, at 12:21 AM, Dmitry Antipov wrote:

On 02/07/2012 02:43 PM, Andrew Richardson wrote:

I'm experiencing what appears to be a minimum clock resolution issue
in using clock_gettime() on a PandaBoard ES running ubuntu.

Do you have CONFIG_OMAP_32K_TIMER enabled in your kernel?
Look at 'dmesg | grep clock' and check for the following:

...
OMAP clockevent source: GPTIMER1 at 32768 Hz
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
...

Most probably this is the answer - by default, recent OMAPs are configured
to use less-accurate, but more energy-saving timer (32KHz) in favor of
MPU timer.

Disable CONFIG_OMAP_32K_TIMER to switch to MPU timer, and check
'dmesg | grep clock' to see:

...
OMAP clockevent source: GPTIMER1 at 38400000 Hz
OMAP clocksource: GPTIMER2 at 38400000 Hz
sched_clock: 32 bits at 38MHz, resolution 26ns, wraps every 111848ms
...

BTW, I have no ideas why clock_getres(CLOCK_REALTIME,...) returns {0, 1}
regardless of underlying clock source. I expect {0, 30517} for 32K timer
and {0, 26} for MPU timer.

Dmitry