a385: sysclock timedrifting compared to hwclock

[Hardik Gohil]

Hello All,

 

root:# hwclock --systohc
root:# while true; do date; hwclock -r; sleep 60; done

 

observing drift of 1 sec.

 

even tried this https://github.com/armbian/build/pull/2352/commits/59cdf431ef691d67d649adbfaf973f9d451823bc#diff-dc13c5522aed383d1b20662d765c5be9f2635553256069dce64f29be94f89b69

 

specs:

 

Armada 38x RTC driver 

ARM_GLOBAL_TIMER

Board : Marvell Armada A385 DB AP  Kernel : 4.14 

 

community help will be grateful

 

Regards

Hardik

 

[ag123]

1 sec every 60 sec? that's a pretty big drift.

oh and btw hwclock seemed to have some ways to adjust for drift, but that'd probably means you need to sync your time to NTP

 

Quote

Usage:
hwclock [function] [option...]

Time clocks utility.

Functions:
-r, --show                      display the RTC time
    --get                       display drift corrected RTC time
    --set                       set the RTC according to --date
-s, --hctosys                   set the system time from the RTC
-w, --systohc                   set the RTC from the system time
    --systz                     send timescale configurations to the kernel
-a, --adjust                    adjust the RTC to account for systematic drift
    --param-get <param>         display the RTC parameter
    --param-set <param>=<value> set the RTC parameter
    --predict                   predict the drifted RTC time according to --date

Options:
-u, --utc                       the RTC timescale is UTC
-l, --localtime                 the RTC timescale is Local
-f, --rtc <file>                use an alternate file to /dev/rtc0
    --directisa                 use the ISA bus instead of /dev/rtc0 access
    --date <time>               date/time input for --set and --predict
    --delay <sec>               delay used when set new RTC time
    --update-drift              update the RTC drift factor
    --noadjfile                 do not use /etc/adjtime
    --adjfile <file>            use an alternate file to /etc/adjtime
    --test                      dry run; implies --verbose
-v, --verbose                   display more details

-h, --help                      display this help
-V, --version                   display version

Arguments:
<param> is either a numeric RTC parameter value or one of these aliases:
  - features: supported features (0x0)
  - correction: time correction (0x1)
  - bsm: backup switch mode (0x2)
  See Kernel's include/uapi/linux/rtc.h for parameters and values.

<param> and <value> accept hexadecimal values if prefixed with 0x, otherwise decimal.

For more details see hwclock(8).

 

 

[Hardik Gohil]

NTP sync is already enabled. 

[ag123]

for some reasons I didn't find related docs in the company's web site

https://www.marvell.com/products/infrastructure-processors/armada-38x.html

those docs links are apparently not accessible

 

but instead stumbled into a copy elsewhere in a web search

https://ulli-kroll.de/Downloads/NAS326/A38x-Functional-Spec-PU0A.pdf

the interesting section is chapter 26 Real time clock pages 303

 

accordingly, the real time clock runs on a 32khz crystal, so check your board to see if it is there.

if it isn't there, maybe it isn't using the real time clock after all. And that if it is there, find in the source codes for the real time clock implementation, apparently some details about the RTC registers are documented, so those should after all match the func spec. And perhaps you may find your way around the code to 'tweak' the register settings etc.

if it is a 'pseudo RTC' i.e. didn't exist, then it is probably a 'simulated' h/w clock which may be written in s/w, it'd take reading the codes to find out that curious facts

 

hope that helps

 

 

Edited August 10 by ag123

[Hardik Gohil]

The board is using armada 38x RTC driver and it can be found in kernel logs.

 

Still I am not able to figure out the fix

Edited August 11 by Hardik Gohil

[Heisath]

Are you using  dvfs on the board? IIRC changing the CPU core speed did lead to some problems with timekeeping. I think we had a patch for that years ago.

Maybe try a newer kernel?

[Hardik Gohil]

I am not using dvfs.

 

did you mean this patch https://github.com/armbian/build/pull/2352/commits/59cdf431ef691d67d649adbfaf973f9d451823bc#diff-dc13c5522aed383d1b20662d765c5be9f2635553256069dce64f29be94f89b69. I have tried that too

 

which kernel version to try ?

[Hardik Gohil]

I have tried with new version too still issue is there