1 1
Arjan van Vught

Orange Pi Zero: internal RTC

Recommended Posts

Dear forum,

 

When looking at the Orange Pi Zero schematic V1.1, the OSC-RTC box is empty. Does this mean that there is no crystal for the internal RTC? The internal RTC cannot be used at all?

 

When just checking the time register, the RTC is running too fast.

 

Thanks, Arjan

Share this post


Link to post
Share on other sites
38 minutes ago, Arjan van Vught said:

The internal RTC cannot be used at all?

RTC is by default set to run with internal OSC, so no need for external one.

39 minutes ago, Arjan van Vught said:

When just checking the time register, the RTC is running too fast.

How did you check that ?

"hwclock" seem to provide the right time ...

 

Share this post


Link to post
Share on other sites
4 minutes ago, martinayotte said:

RTC is by default set to run with internal OSC, so no need for external one.

The internal clock (which is about 16MHz) does not give an accurate reference. So I did not try to use that option.

I will check your source code for the configuration.

 

6 minutes ago, martinayotte said:

How did you check that ?

Just reading the register directly and printing the value when the seconds have changed.

Share this post


Link to post
Share on other sites
14 minutes ago, Arjan van Vught said:

Right ! But since the RTC has no external source, it stays with internal one.

Check the registers description of Allwinner H3 user manual and check values with "devmem2"

"devmem2 0x01f00000" report 0x0001, which is effectively mean LOSC_SRC_SEL bit is set to External, but "devmem2 0x01f00004" (the LOSC_AUTO_SWT_STA_REG) report 0x4, where LOSC_SRC_SEL_STA status bit is 0 meaning InternalOSC.

To my understanding, the LOSC_AUTO_SWT_STA_REG autoswitch probably detect that there is no clock present and doesn't switch the clock ...

 

Did you verify with "hwclock" on your board if it is accurate ?

Share this post


Link to post
Share on other sites
8 minutes ago, martinayotte said:

but "devmem2 0x01f00004" (the LOSC_AUTO_SWT_STA_REG) report 0x4, where LOSC_SRC_SEL_STA status bit is 0 meaning InternalOSC.

So the check here https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L512 is basically wrong. The CTRL tells what has been set, and then AUTO_STA really tells the status.

 

And the RTC goes into default internal with prescaler 0xF -> 16 MHz / 32 / 15 that is about 33KHz. Which is slightly faster than the desired 32768 Hz. 

Share this post


Link to post
Share on other sites
18 minutes ago, Arjan van Vught said:

So the check here https://github.com/armbian/linux/blob/sun8i/drivers/rtc/rtc-sunxi.c#L512 is basically wrong. The CTRL tells what has been set, and then AUTO_STA really tells the status.

You're right ! I don't see those warning in my dmesg ... something fishy there ... But, at least, it still seems to work in my case.

 

EDIT: Oh ! But rtc-sunxi.c doesn't even look at LOSC_AUTO_SWT_STA_REG, it is only validate that write to SUNXI_LOSC_CTRL_REG was successful ... hmmm !

Share this post


Link to post
Share on other sites

Simple test

pi@orangepizero:~$ cat ./rtc_test.sh
while true
do
        ./dev2mem 0x01f00014 | tail -n 1
        echo `date +"%S"`
        sleep 1
done

 

pi@orangepizero:~$ sudo ./rtc_test.sh

Value at address 0x1F00014 (0xb6ff7014): 0xF162D

22

Value at address 0x1F00014 (0xb6f63014): 0xF162E

23

Value at address 0x1F00014 (0xb6f09014): 0xF162F

24

Value at address 0x1F00014 (0xb6f4a014): 0xF1630

25

Value at address 0x1F00014 (0xb6f9f014): 0xF1632

26

Value at address 0x1F00014 (0xb6f0a014): 0xF1633

27

Value at address 0x1F00014 (0xb6ffb014): 0xF1634

28

Value at address 0x1F00014 (0xb6f8b014): 0xF1635

29

^C

 

Skipping a second here. 

 

Quote

pi@orangepizero:~$ cat /etc/armbian-release

# PLEASE DO NOT EDIT THIS FILE

BOARD=orangepizero

BOARD_NAME="Orange Pi Zero"

BOARDFAMILY=sun8i

BUILD_REPOSITORY_URL=https://github.com/armbian/rkbin

BUILD_REPOSITORY_COMMIT=3e533c9

DISTRIBUTION_CODENAME=buster

DISTRIBUTION_STATUS=supported

VERSION=20.02.1

LINUXFAMILY=sunxi

BRANCH=current

ARCH=arm

IMAGE_TYPE=stable

BOARD_TYPE=conf

INITRD_ARCH=arm

KERNEL_IMAGE_TYPE=Image

 

Share this post


Link to post
Share on other sites
10 minutes ago, Arjan van Vught said:

Skipping a second here.

That is not really a good way to test, since your loop is a bit more than 1 second due to execution of previous lines.

Do a sleep of 120 seconds or even bigger, such 1 hour, and calculate the number of seconds elapse between the two devmem2.

Share this post


Link to post
Share on other sites
4 minutes ago, martinayotte said:

hat is not really a good way to test, since your loop is a bit more than 1 second due to execution of previous lines.

Therefore I am also showing the seconds from the date command. I will do another test. However, the apt update/upgrade I just did, it broke the startup. 

Share this post


Link to post
Share on other sites
2 hours ago, Arjan van Vught said:

In fact, this URL is completely obsolete, it is a snapshot of code from 4 years ago ... :P

The current Mainline is here : https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c

But they still don't check the LOSC_AUTO_SWT_STA_REG register ...

 

EDIT: I've done few tests with measurement at 8 minutes intervals, it is loosing/gaining around 8 seconds / 8 minutes, but since it is both loosing/gaining, overall the average should be good.

Share this post


Link to post
Share on other sites

See the remarkable output below. Many observations and some questions:

  • The internal RTC seems to be useless with the internal OSC.
  • The internal RTC gets updated; once every ? seconds. From which source?
  • What is the source for the date command? Specific which ARM Counter or with SoC Timer?
  • This test is with an Internet connection; hence the system clock gets updated with the NTP Client. Interesting to know what happens with no Internet connection.
Quote

pi@orangepizero:~$ sudo ./rtc_test.sh

17:00:39

17:00:21

==============

17:02:47

17:02:21

==============

17:04:55

17:04:21

==============

17:07:04

17:06:21

==============

17:08:25

17:08:21

==============

17:10:34

17:10:21

==============

17:12:42

17:12:21

==============

17:14:51

17:14:21

==============

 

pi@orangepizero:~$ cat ./rtc_test.sh 
while true
do
        ./devmem2 0x01f00014 | tail -n 1 |rev|cut -f1 -d' '|rev | ./convert
        echo `date +"%H:%M:%S"`
        echo ==============
        sleep 120
done
/*
 * convert.c
 */

#include <stdio.h>
#include <stdlib.h>

#define TIME_GET_SEC_VALUE(x)			((x) & 0x0000003f)
#define TIME_GET_MIN_VALUE(x)			(((x) & 0x00003f00) >> 8 )
#define TIME_GET_HOUR_VALUE(x)			(((x) & 0x001f0000) >> 16)

int main(void) {
	unsigned num;
	fscanf(stdin, "%x", &num);
	printf("%.2d:%.2d:%.2d\n", TIME_GET_HOUR_VALUE(num), TIME_GET_MIN_VALUE(num), TIME_GET_SEC_VALUE(num));
	return EXIT_SUCCESS;
}

 

Share this post


Link to post
Share on other sites
43 minutes ago, Arjan van Vught said:

See the remarkable output below

That strange, you drifts is really bigger than mines, mines are 1 or 2 or 3 seconds per 2 minutes ...
I've added "hwclock -w" before the loop and get the following results (not that I forgot to add UTC to "date") :

 

 

 


17:30:39
12:30:39
---------------
17:32:41
12:32:39
---------------
17:34:40
12:34:39
---------------
17:36:43
12:36:39
---------------
17:38:46
12:38:39
---------------
17:40:48
12:40:39
---------------
17:42:51
12:42:39
---------------
17:44:54
12:44:39
---------------
17:46:42 <---- drift correction
12:46:39
---------------
17:48:44
12:48:39
---------------
17:50:47
12:50:39
---------------
17:52:50
12:52:39
---------------
17:54:53
12:54:39
---------------
17:56:55
12:56:39
---------------
17:58:43 <---- drift correction
12:58:39
---------------
 

 

 

Yes, it seems that a background process is doing "hwclock -w" in background, maybe every 12 minutes, as you said, most probably the ntp or chrony service ...

BTW, I've the same test on my OPi3 which actually has an external crystal, no drifts at all ...

 

Share this post


Link to post
Share on other sites
1 hour ago, Arjan van Vught said:

Many observations

Some new ones : I've done tests on my OPiPC2, OPiZeroPlus2, OPi+2E, OPiOne and OPiLite which also don't have a external 32768 crystal, drifts are seen only on H3 but not on H5 ...

Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.

Share this post


Link to post
Share on other sites
15 minutes ago, martinayotte said:

.. drifts are seen only on H3 but not on H5 ...

Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.

That's a shame as I am using the Orange Pi Zero LTS 256MB and the Orange Pi One boards only. I will try to contact Steven and ask if it is doable getting the external 32768 crystal on the(se) H2+/H3 boards.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
1 1