RockPi S how to configure RTC clock

I am using DS3231 as RTC for rockpi s.
Enabled rk3308-i2c1, i2c1-hym8563 in overlay.
mraa-i2c detect 01 confirms that rtc clock on i2c is detected.
Also able to read the rtc date time using the DS3231 library.

unable to sync the RTC time using hwclock.

hwclock --debug returns the following error

hwclock from util-linux 2.31.1
System Time: 1517156664.248024
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

hwclock --rtc /dev/i2c-1 gives the following error

hwclock: ioctl(RTC_RD_TIME) to /dev/i2c-1 to read the time failed: Inappropriate ioctl for device

1 Like

Try this (last comment) :


The module to load is ds1307

This option did not work.Can someone please provide the instructions to setup RTC DS3231 on rockpi S

root@rockpis:/home/rock# dmesg | grep rtc

[ 1.339207] rtc -hym8563 1-0051: could not init device, -6

[ 1.573347] hctosys: unable to open rtc device ( rtc 0)

apt install i2c-tools
armbian-config: activate I2C-0
i2cdetect -y 0
(modprobe) rtc-ds1307 ==> /etc/modules

root@rockpi # more /etc/modules
g_serial
rtc-ds1307

in /etc/rc.local:

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device
hwclock -s

Once correct you can write the system date and time to the RTC module using :

sudo hwclock -w

You should be able to read the date and time back from the RTC using :

sudo date; hwclock -r

compare hwclock

sudo hwclock -c

Updating time via ntp from ptbtime3.pt.de

ntpdate -q ptbtime3.ptb.de

writing actual time to hwclock…

hwclock -w

reading actual time from hwclock…

date; hwclock -r

Still not working. Here is more information from dmesg

rock@rockpis:~$ ls /dev/i2c-0
/dev/i2c-0
rock@rockpis:~$ dmesg | grep rtc0
[ 1.599355] hctosys: unable to open rtc device (rtc0)
rock@rockpis:~$ dmesg | grep ds13*
[ 19.096975] i2c i2c-0: new_device: Instantiated device ds1307 at 0x68
rock@rockpis:~$ hwclock --debug
hwclock from util-linux 2.31.1
System Time: 1625548836.440004
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.
rock@rockpis:~$ timedatectl
Local time: Tue 2021-07-06 10:51:12 IST
Universal time: Tue 2021-07-06 05:21:12 UTC
RTC time: n/a
Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no

root@rockpis:/home/rock# i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – 57 – -- – -- – -- – --
60: – -- – -- – -- – -- 68 – -- – -- – -- –
70: – -- – -- – -- – --

I am using DS3231 RTC.

Please use I2C1, PIN 3 & 5 on 26P header1. How do you connect DS3231?

@jack thanks for the followup. I am still not able to get it working. hwclock throws the same error.

I had connected to pin 23(SDA) & 24 (SCL) as per the instructions given today to work with i2C-0.
Now I have gone back to i2c-1

Here are my pin connections:
GND - pin 6
VCC - pin 4
SDA - pin 3
SCL - pin 5

I have enabled i2c-1 in overlays i2c1-hym8563. Is this required in overlays or should I give rk3308-i2c1. Still does not seem to work.

I can see that i2c-1 is detected.

root@rockpis:/home/rock# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – 57 – -- – -- – -- – --
60: – -- – -- – -- – -- 68 – -- – -- – -- –
70: – -- – -- – -- – --

(modproble) rtc-ds1307 ==> /etc/modules is giving error.
root@rockpis:/home/rock# modprobe rtc-ds1307 ==> /etc/modules

modprobe: FATAL: Module rtc-ds1307 not found in directory /lib/modules/4.4.143-61-rockchip-g1f77a85486f7

Not sure if this is the issue.

So have added them manually in /etc/modules
root@rockpis:/home/rock# more /etc/modules

g_serial
rtc-ds1307

in /etc/rc.local:
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
#hwclock -s

hwclock -s is giving error so commented out.

root@rockpis:/home/rock# dmesg | grep rtc0

[ 1.617044] hctosys: unable to open rtc device ( rtc0 )

root@rockpis:/home/rock# dmesg | grep ds13*

[ 18.944222] i2c i2c-1: new_device: Instantiated device ds13 07 at 0x68

Has it got to do with clocksource:

dmesg | grep clocksource

[ 0.000000] clocksource : arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns

[ 0.083648] clocksource : jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns

[ 0.162298] clocksource : Switched to clocksource arch_sys_counter

Any update please on this issue?

Any update? I’m having the same problem with DS3231.
Followed all steps above without result.

We have not found a solution for the Debian and ubuntu versions.
When installing Armbian it worked.

So if you would like to use RTC on rock pi s, you can only use Armbian.
If someone has it working on another OS, please reply

I believe, the issue is that there is no driver module for DS-xxxx in:

/usr/lib/modules/–your-kernel-version–/kernel/drivers/rtc

I checked Debian Buster images, there’s no even β€œrtc” folder.
DietPi (Bullseye version) has a lot of modules in that folder, maybe copying one of them could work (if the module is just a port to i2c-tools).

Otherwise, if you manage to get i2c-tools to detect your DSxxxx module, the solution could be just to write a bash script, which reads the rtc-chip data via i2cget and then sets the system time via sudo date --set …

Try:

i2cdump -y 1 0x68

Where: -y means β€œanswer yes”, 1 means number of i2c line (try 0 or 1), 0x68 is the address of common rtc-chips.

If i2cdump outputs changing data, you’re half way there - it means, you can read the time! Then it’s just about reading the right bytes via i2cget and shuffling them around :slight_smile:

Anyway… I’ve ordered a bunch of DS1307 modules, when they arrive I’ll try to play with them and make a couple of bash-scripts to get/set the data. :slight_smile:

UPDATE:

Found this implementation in Python for Raspberry Pi:

github(dot)com / switchdoclabs / RTC_SDL_DS1307

(See the test.py file)

It does exactly what I mean, just in python. I will try it on Rock Pi S.

Then, you can just setup a cron job, which runs a Python script every 6 hours to sync the clock.
Not exactly a driver, but can get the job done.

UPDATE 2:

Found this script on EEVBlog forums:

  • The script is here: eevblog (dot) com /forum/testgear/hacking-the-dso2x1x/350/
  • (Edited out, because it was for kernel-mode)

The guy at EEVBlog used the script as custom service, in kernel mode (we don’t need to dig so deep).

UPDATE 3 - working bash script

This script was tested on a fresh Debian Buster install, kernel version 4.4.143-69.
The chip was DS1307, should work on other chips with the same memory structure.

Step 1: Add I2C overlay to /boot/uEnv.txt
Example:

overlays=rk3308-uart0 rk3308-i2c1

Step 2: Install i2c-tools

apt-get install i2c-tools

Step 3: Use this script whenever you need to sync the time - add it to the cron, if you want.

#!/bin/bash

I2C_ADDR="68"
RTC_REG="0x00"

I2C_GET="i2cget -y 1 0x$I2C_ADDR"
I2C_SET="i2cset -y 1 0x$I2C_ADDR"
I2C_DETECT="i2cdetect -y 1 0x$I2C_ADDR 0x$I2C_ADDR"

DATE_CHECK="^[12][0-9]{3}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01]) ([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]$";

MYNAMEIS="$(basename $0)"

read_rtc () {
  NEW=""; for NN in {0..6}; do NEW="$NEW $($I2C_GET $(($RTC_REG + $NN)) b)"; done
  NEW="$(echo $NEW | awk '{printf "20%02X-%02X-%02X %02X:%02X:%02X", $7, $6, $5, $3, $2, $1}')"
  echo "RTC time data: $NEW"
  if [[ $NEW =~ $DATE_CHECK ]]; then
    echo "Setting system time, please wait (10 sec.) ..."
    timedatectl set-ntp 0
    sleep 5
    timedatectl set-time "$NEW"
    if [ $? -ne 0 ]; then echo "FAILED: timedatectl (Setting too often?)"; fi
    sleep 5
    timedatectl set-ntp 1
    echo "Finished."
  else
    echo "RTC time is not correct. (Maybe battery replaced?)"
    echo "Try resetting RTC first by running: $MYNAMEIS reset-rtc"
    echo "Nothing changed."
  fi
}

write_rtc () {
  NEW="$(date +'0x%02S 0x%02M 0x%02H 0x%02u 0x%02d 0x%02m 0x%02y')"
  echo "Sending data to RTC: $NEW"
  echo "                     sec. min. hour wkday day mnth year"
  $I2C_SET $RTC_REG $NEW i
  if [ $? -ne 0 ]; then echo "FAILED: i2cset (Some epic fail?)"; fi
  echo "Giving it a sec, then reading back ..."
  sleep 1
  NEW=""; for NN in {0..6}; do NEW="$NEW $($I2C_GET $(($RTC_REG + $NN)) b)"; done
  NEW="$(echo $NEW | awk '{printf "20%02X-%02X-%02X %02X:%02X:%02X", $7, $6, $5, $3, $2, $1}')"
  echo "RTC time data: $NEW"
}


if [ -z "$($I2C_DETECT | grep " $I2C_ADDR ")" ]; then
  echo "RTC not detected, exiting."
  exit 1
fi

if [[ $# -gt 0 ]]; then
  if [ $1 == 'reset-rtc' ]; then
    echo "Resetting RTC with current system time ..."
    write_rtc
    exit 0
  fi
fi 

if [ -z "$(timedatectl status | sed -n 's/.*System clock synchronized[^a-zA-Z]*\(yes\).*/\1/Ip')" ]; then
  echo "NTP time is NOT syncronised, getting RTC-time ..."
  read_rtc
else
  echo "NTP time is syncronised, overwriting RTC-time ..."
  write_rtc
fi

… or use Armbian, where this is reported working well just one post up. Which is the best OS you can get for those devices. Dietpi does not have development below bash - they usually use vendor or Armbian base and add their brand, scripts & bugs to user land.

The question was β€œworking on another OS”, other than Armbian :slight_smile:
The i2c-tools way should work independently on the OS.

Also, I had some issues with watchdog on the latest Armbian.
(And Bluetooth couldn’t connect, which was essential for my application)

I find Debian Buster more flexible, plus on fresh install, Buster takes 8 seconds to boot up until ssh login, and both Armbian and DietPi take about 30 seconds.
And overall Buster seems more swift than Bullseye distributions.

Under assumption that hardware interface is the same. But its not. Kernel comes in two variants. Rockchip + small vendor adjustements or mainstream based Linux (Armbian usually provides both). Both has pros and cons. If you wanna know, do the home work.

Stock kernel has all (most) hardware functionality covered, yes, but will probably never be updated and is only maintained by chip / board vendor.

If you didn’t download it from www.debian.org then this is not Debian :wink: but something that looks like Debian. And if HW functionality is covered well, then this is kernel where chip support was made and is very old.

This is expected. Dietpi guys downloads Armbian, run some script over it and sell as Dietpi. If boot time would be essential for general purpose OS, anyone can improve it. I don’t think a problem here. If you need this professionally, you need to construct and maintain your own OS with yocto / buildroot / armbian tools / LFS, …

If you talk this way in this world, not many knows what you are comparing. You have two very different hardware interfaces. And many different user lands … Android, Bullseye, Buster, Slack, Arch …

Stock kernel has all (most) hardware functionality covered, yes, but will probably never be updated and is only maintained by chip / board vendor.

Man, are we still trying to find a solution here, or it became political discussion of Armbian Party? :grin:

Like I said, the question explicitly was - β€œother than Armbian”.

I’m not interested in fighting which distro is the best (it’s never-ending story with Linux users).
I’m trying to get the job done for the given conditions.

If you would at least read what I wrote …