Dear Rasmus,

thank you very much for explanation!

I have set "RTC_SET_DELAY_SECS = 0.0" in hwclock.c and got acceptable result.

It wonder why such critical function does not implemented on kernel level in RTC driver?
It is very strange to rely on specific HW in user space SW.

Best wishes.
Igor Plyatov

On 2018-02-19 07:40, Igor Plyatov wrote:

I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel
and RTC chip DS1340 (rtc-ds1307.c driver).

RTC chip connected by means of I2C-bus, without HW IRQ line connected.

Kernel configured to not use embedded functions for time getting at
startup and saving at shutdown:

The hwclock utility is from util-linux-2.29.1.

The OS does not have external time synchronization sources like NTP, PTP
or else.

Generally I need to achieve error within +-20 ms when RTC's time copied
into OS or back from OS into RTC.

I have made measurements during startup and shutdown of OS and have
found 500 ms delay introduced into RTC's time, when "hwclock --utc
--systohc" executed.

Logical analyzer show to me I2C-bus transactions and PPS signal
generated by Linux. And I see 500 ms delay is between of rising edge of
PPS signal (start of OS second) and moment when time saved into RTC.

Please explain, why this happens? Is this due to absence of IRQ line for
RTC or due to a bug in the hwclock, or kernel bug or I have missed
something else?
cc +=

It's because util-linux's hwclock still assumes the world is x86. See
this comment in the util-linux source code:

          * The Hardware Clock can only be set to any integer time plus one
          * half second.  The integer time is required because there is no
          * interface to set or get a fractional second.  The additional half
          * second is because the Hardware Clock updates to the following
          * second precisely 500 ms (not 1 second!) after you release the
          * divider reset (after setting the new time) - see description of
          * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note

So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
already passed, waits until  01:02:04.5 and sets it to 01:02:04.

On our ARM BSP we patch util-linux to have the "implicit fractional
part" configurable, and trying to upstream something like that has been
on my todo-list for quite a while. See

for the patch we currently use (on top of that, we change the 0.5
initializer to 0.0 to avoid having to always pass the --delay argument).
Incidentally, it seems we're on the same util-linux version, so you
should be able to try out that patch and see if it works for you.


You received this message because you are subscribed to "rtc-linux".
Membership options at .
Please read
before submitting a driver.
--- You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to