Using realtime clock?

Hello,

I'm a junior, pls help me...
I'm using Hardhat 2.2.14, and I ported it in a custom board successfully.
This board has its own realtime clock, pls tell me where I can modify in the kernel
so that all of the time function in linux can use my realtime clock...such as
date function...or filesystem....

Quoted 7 lines · Jari Nguyen Trung Thanh

Hello,

I'm a junior, pls help me...
I'm using Hardhat 2.2.14, and I ported it in a custom board successfully.
This board has its own realtime clock, pls tell me where I can

modify in

Quoted 4 lines

the kernel
so that all of the time function in linux can use my realtime clock...such as
date function...or filesystem....

You don't want to use the real time clock for this. Getting the time is a very frequent opeartion and you don't want to do I/O on every gettimeofday. even if your RTC is (hopefully) in UTC, it probably does not keep time in the right format for the kernel (it is much more likely to use a split format with year, month, day, hour, minutes and seconds in different registers). Many do not provide subseconds fields and run off a 32768kHz watch cystal which provides only 30 microseconds or so resolution.

In one word, the RTC is good to save time across reboots and in some cases to measure the CPU timebase rate by measuring the number timebase ticks between two second boundaries.

Regards,
Gabriel.

The "proper" way to handle a RTC is to read it on power up and set the system clock based on it. From then on, the system clock will be correct and everyone will use the system clock efficiently and accurately.

On the x86 (PC host), the utility is "hwclock" (man hwclock). Your best approach is to get the source for that, modify it to read your RTC hardware (which may be different from the PC RTC hardware, although you might get lucky and only have to deal with endian issues). Then add a call to it in your startup scripts, typically in /etc/rc.d/rc.local.

gvb

Quoted 9 lines · Gabriel Paubert

Quoted 7 lines · Jari Nguyen Trung Thanh

Hello,

I'm a junior, pls help me...
I'm using Hardhat 2.2.14, and I ported it in a custom board successfully.
This board has its own realtime clock, pls tell me where I can

Quoted 7 lines

modify in

Quoted 4 lines

the kernel
so that all of the time function in linux can use my realtime clock...such as
date function...or filesystem....

You don't want to use the real time clock for this. Getting the time is

a

Quoted 3 lines

very frequent opeartion and you don't want to do I/O on every gettimeofday. even if your RTC is (hopefully) in UTC, it probably does not keep time in the right format for the kernel (it is much more

likely

Quoted 1 line

to use a split format with year, month, day, hour, minutes and seconds

in

Quoted 1 line

different registers). Many do not provide subseconds fields and run off

a

Quoted 4 lines

32768kHz watch cystal which provides only 30 microseconds or so resolution.

In one word, the RTC is good to save time across reboots and in some

cases

Quoted 8 lines

to measure the CPU timebase rate by measuring the number timebase ticks between two second boundaries.

Regards,
Gabriel.

The "proper" way to handle a RTC is to read it on power up and set the system clock based on it. From then on, the system clock will be correct and everyone will use the system clock efficiently and accurately.

On the x86 (PC host), the utility is "hwclock" (man hwclock). Your best approach is to get the source for that, modify it to read your RTC hardware (which may be different from the PC RTC hardware, although you might get lucky and only have to deal with endian issues). Then add a call to it in your startup scripts, typically in /etc/rc.d/rc.local.

In message <[email protected]> Jerry Van

Quoted 4 lines · Baren

The "proper" way to handle a RTC is to read it on power up and set the system clock based on it. From then on, the system clock will be correct and everyone will use the system clock efficiently and

accurately.

Well, that's the way it's often done, but it's far from being perfect. On many embedded systems I'm working with the RTC is running from a high precision oscillator which provides much better accuracy than the system clock. Both clocks will drift, and usually there will be a noticable difference after a few days. This is not really nice.

Quoted 5 lines

On the x86 (PC host), the utility is "hwclock" (man hwclock). Your best approach is to get the source for that, modify it to read your RTC hardware (which may be different from the PC RTC hardware, although you might get lucky and only have to deal with endian issues). Then add a call to it in your startup scripts, typically in /etc/rc.d/rc.local.

Any idea how to keep the system clock permanently synchronized to the RTC?

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] In an infinite universe all things are possible, including the possi- bility that the universe does not exist.
- Terry Pratchett, _The Dark Side of the Sun_

The astronomy people, among others, are really fanatical about accurate time and have some very elaborate programs to synchronize clocks to the nanosecond (microsecond?) level. These involve NTP daemons. Note that the NTP daemons can synchronize to a radio clock that provides a 1/second tick: your simplest solution would probably be to set up your accurate RTC to do a 1/second interrupt and then tie it into a NTP daemon to keep your kernel clock accurate.

Quoted 8 lines · In message <[email protected]> you wrote:

The astronomy people, among others, are really fanatical about accurate time and have some very elaborate programs to synchronize clocks to the nanosecond (microsecond?) level. These involve NTP daemons. Note that the NTP daemons can synchronize to a radio clock that provides a 1/second tick: your simplest solution would probably be to set up your accurate RTC to do a 1/second interrupt and then tie it into a NTP daemon to keep your kernel clock accurate.

Seems a bit of overhead (especially for embedded systems with limited resources) to add a NTP daemon just to make one part of the kernel timekeeping toal to the other...

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected]
"It's when they say 2 + 2 = 5 that I begin to argue." - Eric Pepke

If you tracked down some references (NTP source code, NTP RFCs, "David L. Mills' clock adjustment algorithm"), I suspect you would be able to figure out how to properly use adjtimex(). Further, I suspect adjtimex() a pretty lightweight routine since it merely adjusts the parameters that presumably already exist in your kernel.

I'm just leaving the fun parts for the reader :-).

Yup. However, adjtimex() is a function call that tweaks the clock parameters in the kernel. If you understood those parameters (I don't), you could keep your clock very accurate.

If you tracked down some references (NTP source code, NTP RFCs, "David L. Mills' clock adjustment algorithm"), I suspect you would be able to figure out how to properly use adjtimex(). Further, I suspect adjtimex() a pretty lightweight routine since it merely adjusts the parameters that presumably already exist in your kernel.

Wolfgang:

A good place to start is the clock mini HOWTO:
http://www.linuxdoc.org/HOWTO/mini/Clock.html

The astronomy people, among others, are really fanatical about accurate time and have some very elaborate programs to synchronize clocks to the nanosecond (microsecond?) level. These involve NTP daemons. Note that the NTP daemons can synchronize to a radio clock that provides a 1/second tick: your simplest solution would probably be to set up your accurate RTC to do a 1/second interrupt and then tie it into a NTP daemon to keep your kernel clock accurate.

Note that utilities like adjtimex (covered in the HOWTO) adjust time slowly so that it is monotonically increasing (i.e. they speed up or slow down the tick announcement rather than jamming a new value in the linux clock). This is a VERY GOOD feature: otherwise you the risk of having Really Bad things happen like your cron job running twice if the clock jam happens to run at just the wrong moment (quite likely, actually, since you probably update the clock as a cron job).