Re: 500 ms delay in time saved into RTC

2018-02-24 Thread Alexandre Belloni 
Hi,

On 19/02/2018 at 12:03:28 +0100, Karel Zak wrote:
> On Mon, Feb 19, 2018 at 08:11:05AM +0100, Rasmus Villemoes wrote:
> > 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
> > 
> > https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch
> > 
> > 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.
> 
> Would be possible to somehow detect what is the right default setting for
> --delay? I mean for example detect architecture / clock HW, etc.
> 
> I have no problem with --delay, but it's tuning for advanced users and
> HW specific stuff. It would be nice to have something more portable.
> 

This is what I'm using to synchronize the RTC to the system time:

https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-sync.c

With sane RTCs, it manages to do so with a good precision, 10µs on a
pcf85363 connected to a sama5d4 xplained, 96µs on my PC.

It can still be improved and doesn't handle RTCs in localtime.

I'm planning to integrate that in hwclock at some point i(hopefully
soon) but I didn't have the time to dive too much in the code yet.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: 500 ms delay in time saved into RTC

2018-02-24 Thread Alexandre Belloni 
Hi,

On 19/02/2018 at 12:03:28 +0100, Karel Zak wrote:
> On Mon, Feb 19, 2018 at 08:11:05AM +0100, Rasmus Villemoes wrote:
> > 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
> > 
> > https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch
> > 
> > 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.
> 
> Would be possible to somehow detect what is the right default setting for
> --delay? I mean for example detect architecture / clock HW, etc.
> 
> I have no problem with --delay, but it's tuning for advanced users and
> HW specific stuff. It would be nice to have something more portable.
> 

This is what I'm using to synchronize the RTC to the system time:

https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-sync.c

With sane RTCs, it manages to do so with a good precision, 10µs on a
pcf85363 connected to a sama5d4 xplained, 96µs on my PC.

It can still be improved and doesn't handle RTCs in localtime.

I'm planning to integrate that in hwclock at some point i(hopefully
soon) but I didn't have the time to dive too much in the code yet.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov 

Dear Karel,



Would be possible to somehow detect what is the right default setting for
--delay? I mean for example detect architecture / clock HW, etc.

I have no problem with --delay, but it's tuning for advanced users and
HW specific stuff. It would be nice to have something more portable.

 Karel



As I understood, issue exists only at x86 platform, where 
MC146818-compatible RTC used.


But even if you will correctly detect platform, there is no guaranty to 
get exactly MC146818 RTC. RTC can be other type. It even can be not 
single in the system.


What is more or less usable is "/sys/class/rtc/rtcX/name" file, which 
contains driver name.
For x86 and MC146818-compatible RTC its name is "rtc_cmos". And it can 
be used to distinguish RTC type by hwclock utility.


Best wishes.
--
Igor Plyatov

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov 

Dear Karel,



Would be possible to somehow detect what is the right default setting for
--delay? I mean for example detect architecture / clock HW, etc.

I have no problem with --delay, but it's tuning for advanced users and
HW specific stuff. It would be nice to have something more portable.

 Karel



As I understood, issue exists only at x86 platform, where 
MC146818-compatible RTC used.


But even if you will correctly detect platform, there is no guaranty to 
get exactly MC146818 RTC. RTC can be other type. It even can be not 
single in the system.


What is more or less usable is "/sys/class/rtc/rtcX/name" file, which 
contains driver name.
For x86 and MC146818-compatible RTC its name is "rtc_cmos". And it can 
be used to distinguish RTC type by hwclock utility.


Best wishes.
--
Igor Plyatov

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Karel Zak 
On Mon, Feb 19, 2018 at 08:11:05AM +0100, Rasmus Villemoes wrote:
> 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
> 
> https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch
> 
> 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.

Would be possible to somehow detect what is the right default setting for
--delay? I mean for example detect architecture / clock HW, etc.

I have no problem with --delay, but it's tuning for advanced users and
HW specific stuff. It would be nice to have something more portable.

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Karel Zak 
On Mon, Feb 19, 2018 at 08:11:05AM +0100, Rasmus Villemoes wrote:
> 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
> 
> https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch
> 
> 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.

Would be possible to somehow detect what is the right default setting for
--delay? I mean for example detect architecture / clock HW, etc.

I have no problem with --delay, but it's tuning for advanced users and
HW specific stuff. It would be nice to have something more portable.

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Rasmus Villemoes 
On 2018-02-19 11:07, Alexandre Belloni wrote:
> On 19/02/2018 at 12:16:04 +0300, Igor Plyatov wrote:
>> 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.
>>
> 
> Because of the way the API is designed, handling the MC146818A oddity is
> not possible in the driver (i.e. 50% of the time, it will be too late
> to handle it).

Well, I suppose one could implement an ioctl that would not actually
take a struct rtctime from userspace but simply use the current value of
clock_realtime (which is what 99% of rtc_set_times are using anyway),
and doing it as accurately as possible (which requires implementations
in each driver) - i.e., have the kernel do the appropriate sleeping
which is currently done in userspace: a generic implementation of that
ioctl would sleep until clock_realtime is a whole second, while the x86
driver could sleep until a .5 second. Sure, clock_realtime can jump or
get adjusted while we sleep, and we can oversleep for all kinds of
reasons, but the kernel is in a much better position to do the sleeping
and knowing when to attempt the rtc setting than userspace.

Said ioctl could also take an integer offset to apply to the
clock_realtime value to support setting the rtc to some non-UTC timezone.

> You can use busybox hwclock which has the x86 insanity commented out:
> https://git.busybox.net/busybox/tree/util-linux/hwclock.c 

No, the code that is commented out is code that would actually try to do
the rtc setting at a whole (system clock) second, which is what one
wants on non-x86. It is apparently commented out because aiming for a
whole second is not the right thing to do on some platforms (i.e., x86).
So the current busybox code, on rtcs which set the fractional part to 0,
end up discarding (losing) some uniformly distributed number from [0,1]
instead of consistently .5 seconds.

Also, AFAIR, the busybox code which implements the --hctosys doesn't do
anything to do it right after the rtc has incremented, losing another
[0, 1] uniformly.

Rasmus

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Rasmus Villemoes 
On 2018-02-19 11:07, Alexandre Belloni wrote:
> On 19/02/2018 at 12:16:04 +0300, Igor Plyatov wrote:
>> 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.
>>
> 
> Because of the way the API is designed, handling the MC146818A oddity is
> not possible in the driver (i.e. 50% of the time, it will be too late
> to handle it).

Well, I suppose one could implement an ioctl that would not actually
take a struct rtctime from userspace but simply use the current value of
clock_realtime (which is what 99% of rtc_set_times are using anyway),
and doing it as accurately as possible (which requires implementations
in each driver) - i.e., have the kernel do the appropriate sleeping
which is currently done in userspace: a generic implementation of that
ioctl would sleep until clock_realtime is a whole second, while the x86
driver could sleep until a .5 second. Sure, clock_realtime can jump or
get adjusted while we sleep, and we can oversleep for all kinds of
reasons, but the kernel is in a much better position to do the sleeping
and knowing when to attempt the rtc setting than userspace.

Said ioctl could also take an integer offset to apply to the
clock_realtime value to support setting the rtc to some non-UTC timezone.

> You can use busybox hwclock which has the x86 insanity commented out:
> https://git.busybox.net/busybox/tree/util-linux/hwclock.c 

No, the code that is commented out is code that would actually try to do
the rtc setting at a whole (system clock) second, which is what one
wants on non-x86. It is apparently commented out because aiming for a
whole second is not the right thing to do on some platforms (i.e., x86).
So the current busybox code, on rtcs which set the fractional part to 0,
end up discarding (losing) some uniformly distributed number from [0,1]
instead of consistently .5 seconds.

Also, AFAIR, the busybox code which implements the --hctosys doesn't do
anything to do it right after the rtc has incremented, losing another
[0, 1] uniformly.

Rasmus

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Alexandre Belloni 
On 19/02/2018 at 12:16:04 +0300, Igor Plyatov wrote:
> 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.
> 

Because of the way the API is designed, handling the MC146818A oddity is
not possible in the driver (i.e. 50% of the time, it will be too late
to handle it).

You can use busybox hwclock which has the x86 insanity commented out:
https://git.busybox.net/busybox/tree/util-linux/hwclock.c


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Alexandre Belloni 
On 19/02/2018 at 12:16:04 +0300, Igor Plyatov wrote:
> 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.
> 

Because of the way the API is designed, handling the MC146818A oddity is
not possible in the driver (i.e. 50% of the time, it will be too late
to handle it).

You can use busybox hwclock which has the x86 insanity commented out:
https://git.busybox.net/busybox/tree/util-linux/hwclock.c


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov 

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:

Hi!

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:
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1307_CENTURY=y

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 += util-li...@vger.kernel.org

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

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

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.

Rasmus

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov 

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:

Hi!

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:
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1307_CENTURY=y

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 += util-li...@vger.kernel.org

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

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

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.

Rasmus

Re: 500 ms delay in time saved into RTC

2018-02-18 Thread Rasmus Villemoes 
On 2018-02-19 07:40, Igor Plyatov wrote:
> Hi!
> 
> 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:
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> # CONFIG_RTC_SYSTOHC is not set
> CONFIG_RTC_INTF_DEV_UIE_EMUL=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1307_CENTURY=y
> 
> 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 += util-li...@vger.kernel.org

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

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

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.

Rasmus

Re: 500 ms delay in time saved into RTC

2018-02-18 Thread Rasmus Villemoes 
On 2018-02-19 07:40, Igor Plyatov wrote:
> Hi!
> 
> 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:
> CONFIG_RTC_CLASS=y
> # CONFIG_RTC_HCTOSYS is not set
> # CONFIG_RTC_SYSTOHC is not set
> CONFIG_RTC_INTF_DEV_UIE_EMUL=y
> CONFIG_RTC_DRV_DS1307=y
> CONFIG_RTC_DRV_DS1307_CENTURY=y
> 
> 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 += util-li...@vger.kernel.org

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

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

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.

Rasmus