On August 17, 2021 9:21:03 PM GMT+08:00, Alexandre Belloni [off-list ref] wrote:

On 17/08/2021 19:09:28+0800, tonywwang-oc@zhaoxin.com wrote:

quoted

On August 16, 2021 8:36:48 PM GMT+08:00, Alexandre Belloni

[off-list ref] wrote:

quoted

quoted

On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote:

quoted

On 16/08/2021 16:24, Alexandre Belloni wrote:

quoted

Hello,

On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:

quoted

When the RTC divider is changed from reset to an operating time

base,

quoted

quoted

quoted

the first update cycle should be 500ms later. But on some

Zhaoxin

quoted

quoted

SOCs,

quoted

quoted

quoted

this first update cycle is one second later.

So set RTC time on these Zhaoxin SOCs will causing 500ms delay.

Can you explain what is the relationship between writing the

divider and

quoted

quoted

the 500ms delay?

quoted

Isn't the issue that you are using systohc and set_offset_nsec

is

quoted

quoted

set to

quoted

quoted

NSEC_PER_SEC / 2 ?

No.
When using #hwclock -s to set RTC time and set_offset_nsec is
NSEC_PER_SEC / 2, the function mc146818_set_time() requires the

first

quoted

quoted

quoted

update cycle after RTC divider be changed from reset to an

operating

quoted

quoted

quoted

mode is 500ms as the MC146818A spec specified. But on some Zhaoxin

SOCs,

quoted

the first update cycle of RTC is one second later after RTC

divider

quoted

quoted

be

quoted

changed from reset to an operating mode. So the first update cycle

after

quoted

RTC divider be changed from reset to an operation mode on These

SOCs

quoted

quoted

quoted

will causing 500ms delay with current mc146818_set_time()

implementation.

quoted

What happens with hwclock --delay=0 -s ?

With "hwclock --delay=0 -s" still have this problem. Actually, this

500ms delay caused by writing the RTC time on these Zhaoxin SOCs.

quoted

As I've tested, with hwclock --delay=0 -w can fix it too. 

Both -s and -w end up calling set_hardware_clock_exact() so both should
end up with the correct time. If this is not the case, then hwclock
needs to be fixed.

I checked Util-linux-2.37.2, hwclock -w will call
set_hardware_clock_exact() and hwclock -s will not.
Please correct me if I'm wrong.

Sincerely
TonyWWang-oc