Hi all-

I am working on a hardware BSP. The underlying hardware has an oven-controlled quarz oscillator (OCXO) onboard, which is used to count a high precision NTP time at a dedicated HW address, which I can read out memory-mapped from software.

The processor is a Freescale MPC8568. It has a high precision timer, which - I think - is used by the Linux kernel to provide HR timing.

The question is: can I tell Linux to use OUR hardware timer as the system time and thus for all HR time related issues?

At the moment, I have to maintain two parallel clocks. I'd rather like our timer to be used as system time (with all system calls and functions working implicitly), because it's more stable than the CPU's timer.

Edit: I am using Linux 2.6.29.6 RT24

Cheers,
Matt

My understanding is that you need to implement your timer as a clocksource driver, and then use the clocksource kernel parameter to set this as the default source.

Something like the scx200_hrt driver might be a useful model.

The system interface /sys/devices/system/clocksource/clocksource0/current_clocksource and /sys/devices/system/clocksource/clocksource0/available_clocksource will give you information about which source is being used, and what other clock sources are available.

The conference report on the introduction of hrtimers may also be useful.

Thanks for the hints!

I'm trying this out right now, and I'm not so sure what to put into the struct clocksource.

I have two hardware registers:

1. a 64-bit value from the OCXO running at 33 1/3 MHz, resulting in an effictive LSB tick of exact 30 nanosec.

2. a 64-bit NTP register, where the time above is converted by hardware.

Which one should I take, and what are the parameters for .mask, .shift and .mult?

I assume using .flags = CLOCK_SOURCE_IS_CONTINUOUS is correct?!

Thanks again,
Matt

I haven't implemented one of these myself, so if you get stuck, you might want to ask on one of the kernel mailing lists. Looking through clocksource.h, I gather that mult and shift form the scale ratio (to convert hardware ticks into nanoseconds), so I guess you could just work with a 30 times multiply and a zero shift. The mask is intended for registers of less than 64 bits; in your case you will have all the bits set (or just use CLOCKSOURCE_MASK(64)). I don't know which flags you should use, though the CONTINUOUS and the VALID_FOR_HRES look reasonable.

Hi, I am back again with some results:

I managed to create a clocksource driver that reads the monotonically upcounting counter of my hardware.

It is possible, to apply some sort of long time correction to the hardware counter. In fact, it does not count up the register every x-th tick or inserts another tick after x ticks, depending on if I want it to go slower of faster.

Now: I have put a 4 into the correction register which actually means that every fourth tick, the counter is not incremented. Indeed, this is a rather hard correction, but good for testing.

On the command line I start this simple loop:

which is pretty straight forward just printing the current date then sleep for 20 secs.

This is my result:

Obviously, the hardware measures a real amount of time of 20 secs for the sleep. But the wall time actually only increases by approx. 16 secs every time.

Why that? I mean, when I measure externally, the elapsed real time is in fact 16 seconds, what makes sense, as I told the clock to go a lot slower.

But how the hack does Linux still keep track of the outside wall time?

BTW: This also happens, if I do this whole thing only in software by changing the struct clocksource .mult value to the half of what it actually is. A sleep 1 actually takes two seconds for real, but the date-command still maintains the outside wall time...

In another test program, I compared clock_gettime over gettimeofday which also gave me a headache:

WHY AND HOW IS THIS HAPPENING???