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/a18fa3514d130... ) 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