Unable to make it to work: RTC module ds3231, BPI M2Z and ARMBIAN Bookworm

[Ed van den Enden]

I'm unable to make an RTC module to work:
RTC module ds3231, BPI M2Z and ARMBIAN Bookworm
i2c pins 3 and 5
Driver RTC-ds1307 loaded, because RTC-ds3231 is not available.

 

Why do I need a RTC-module?

Often in the field I'm not online but I do need the right time on my observation camera's.

My application does not allow me for having a monitor.

My system does the recordings by motion detection, and the recordings do need the right time on it. 

 

armbian-config
i2c0 set

 

Tools installed:

apt install python3-smbus i2c-tools

 

i2cdetect -y 0
Detects address 068 and not UU as proof of driver been loaded

 

File "hwclock-set" adapted

#if [ -e /run/systemd/system ] ; then

# exit 0

#fi

 

Fake hwclock removed

sudo apt -y remove fake-hwclock

sudo update-rc.d -f fake-hwclock remove

 

armbianEnv.txt
overlay and dtoverlay correctly set

 

modules.conf added:
rtc-ds1307

 

Still, after a power down, the hardware clock shows 1970 as the date

The same module tested on my RPi Zero 2W, and all is working perfect.

 

If somebody can help me, that would be wonderful.

 

 

[IBV]

Hi,

 

is the hardware clock set before power off ?

What does "sudo hwclock" say ?

Why did you modify the hwclock-set script ?

[Ed van den Enden]

Indeed, the hardware clock has been set and checked before power off.

1) date -s "April 22, 2024 11:54:00"

2) hwclock -w

3) hwclock -r

4) battery hwclock 3.6V

5) works flawless with RPi Zero 2W

6) i2cdetect -y 0 shows address 068

 

Why did you modify the hwclock-set script ?
Suggested by many, but without modifying this script, it does not change mallfunction of the hwclock.

 

When connected to WiFi

hwclock --verbose tells me following:

hwclock from util-linux 2.38.1
System Time: 1745389217.903091
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1745317708 seconds after 1969
Last calibration done at 1745317708 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2025/04/23 06:20:20
Hw clock time : 2025/04/23 06:20:20 = 1745389220 seconds since 1969
Time since last adjustment is 71512 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2025-04-23 08:20:18.895813+02:00

 

After power down and When disconnected from WiFi (my application and so the reason why I need a hwclock to work)

hwclock --verbose tells me following:

hwclock from util-linux 2.38.1
System Time: 1745389772.399976
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1745317708 seconds after 1969
Last calibration done at 1745317708 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 1970/01/01 00:04:02
Hw clock time : 1970/01/01 00:04:02 = 242 seconds since 1969
Time since last adjustment is 1745317466 seconds
Calculated Hardware Clock drift is 0.000000 seconds
1970/01/01 01:04:00.760027+01:00

[IBV]

This would suggest that the battery of the rtc is dead, but it is confusing because you say it works with RPI zero.

Could you provide logs with
 

sudo armbianmonitor -u

 

[Ed van den Enden]

See link

https://paste.armbian.com/alehuretiw
Now connected to WiFi

Edited Wednesday at 07:18 AM by Ed van den Enden

[Ed van den Enden]

Just measured again the battery on the battery pins of the RTC-ds3231, and it shows me 3.6 volt (not the BPI 3.3 volt pins (1 + 9)

[IBV]

After boot, can you show the output of "timedatectl status" ?

[Ed van den Enden]

When connected to WiFi

 

root@clearview:~# timedatectl status
               Local time: Wed 2025-04-23 09:56:59 CEST
           Universal time: Wed 2025-04-23 07:56:59 UTC
                 RTC time: Wed 2025-04-23 07:56:58
                Time zone: Europe/Brussels (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

 

After power down and disconnected from WiFi

 

root@clearview:~# timedatectl status
               Local time: Wed 2025-04-23 10:04:43 CEST
           Universal time: Wed 2025-04-23 08:04:43 UTC
                 RTC time: Wed 1970-01-01 00:02:45
                Time zone: Europe/Brussels (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

[Ed van den Enden]

To my understanding and the documentation I found, by investigating the RTC address, with the outcome 068, it indicates that the RTC driver is not loaded, otherwise the address request would show UU as outcome.

[IBV]

There seems to be a RTC detected on boot

 

[    1.018029] sun6i-rtc 1f00000.rtc: registered as rtc0
[    1.018081] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01T00:00:04 UTC (4)

 

Just to confirm, you could disconnect your RTC and boot again. Then check the boot log if the system says anything about rtc.

[Ed van den Enden]

Another remark/question:
The latest Armbian does not show a driver RTC-ds3231, just the RTC-ds1307 driver.

Therefore I used fo my ds3231 RTC module the available driver RTC-ds1307.
Could that be the reason for the malfunction of the hwclock?

 

Edited Wednesday at 08:39 AM by Ed van den Enden

[Ed van den Enden]

The below output with the RTC module taken off the BPI M2Z

Further below I saw that there were some pin errors. (most probably nothing to do with this topic)

 

https://paste.armbian.com/axoduwanuq
 

[ 1.020506] usbcore: registered new interface driver usb-storage

[ 1.022284] sun6i-rtc 1f00000.rtc: registered as rtc0

[ 1.022371] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01T00:00:04 UTC (4)

[ 1.023147] i2c_dev: i2c /dev entries driver

[ 1.025025] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)

 

 

 

[ 7.721526] sun8i-h3-pinctrl 1c20800.pinctrl: pin PD14 already requested by onewire@0; cannot claim for pps@0

[ 7.721577] sun8i-h3-pinctrl 1c20800.pinctrl: pin-110 (pps@0) status -22

[ 7.721597] sun8i-h3-pinctrl 1c20800.pinctrl: could not request pin 110 (PD14) from group PD14 on device 1c20800.pinctrl

[ 7.721613] pps-gpio pps@0: Error applying setting, reverse things back

[Ed van den Enden]

I notice that there is a linux driver available at GITHUB for the ds3231, but I have no clue how to compile/install this driver.

https://github.com/AxelElRojo/ds3231-linux

 

[IBV]

I believe the rtc_ds1307 is compatible with the ds3231.

You can check that with "modinfo rtc_ds1307"

 

1 hour ago, Ed van den Enden said:

[ 7.721526] sun8i-h3-pinctrl 1c20800.pinctrl: pin PD14 already requested by onewire@0; cannot claim for pps@0

[ 7.721577] sun8i-h3-pinctrl 1c20800.pinctrl: pin-110 (pps@0) status -22

[ 7.721597] sun8i-h3-pinctrl 1c20800.pinctrl: could not request pin 110 (PD14) from group PD14 on device 1c20800.pinctrl

[ 7.721613] pps-gpio pps@0: Error applying setting, reverse things back

I don't know the hardware, can you check that you don't have pin conflicts?

Do you need these overlays : "pps-gpio w1-gpio" ? If not, you might remove them from armbianEnv.txt, boot and check again.

[Ed van den Enden]

Indeed, the rtc_ds1307 is compatible with the ds3231 and removing pps-gpio w1-gpio did the errors disappear.

 

The RTC module still doesn't work.

😭

 

 

 

[IBV]

Try to enable i2c1 also (just a stupid suggestion) in armbianEnv.txt and scan the bus with i2cdetect. Who knows, maybe there's a weird mapping of the bus interfaces.

[IBV]

 

6 hours ago, Ed van den Enden said:

i2cdetect -y 0 shows address 068

This should mean that the rtc is there.

Take a look at https://wiki.banana-pi.org/BPI_RTC_real_time_Module

 

You could try:

echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-0/new_device

 

Then a dmesg to see if there's something new about rtc.

[Ed van den Enden]

Nop, that didn't work

had also both i2c0 and i2c1 activated

 

root@clearview:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- 32 33 34 35 36 -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@clearview:~# i2cdetect -y 1
Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory
root@clearview:~# ls /dev/i2c-*
/dev/i2c-0
 

[Ed van den Enden]

I will leave it for what it is for now.

I will move back to RPi zero 2W, solder an antenna, and I'm good to go.

Would have loved to go to the BPI m2z and later to the BPI m4z, but for now not an option.

By the way, with the latest Armbian upgrade an hour ago, my USB camera is also not working anymore.

Thank you very much for the support.

Kind regards,

Ed👏

Edited Wednesday at 01:16 PM by Ed van den Enden

[going]

22.04.2025 в 15:02, Ed van den Enden сказал:

armbian-config
i2c0 set

kernel version?

uname -r

 

[djurny]

Hi @Ed van den Enden,

I think your BananaPi runs an Allwinner SoC, which is similar to the OrangePi zero. Can you list the RTCs on your board?

ls /dev/rtc*

On my OrangePi's here, the H2+ SoC also has an RTC that is wildly unprecise, but it's still used as /dev/rtc0 and therefore used by the kernel to synchronize to when the kernel boots.

 

I do not know much about your SBC, but perhaps sharing my config for the OrangePi zero helps you as well:

 

I have two RTCs, one from the H2+ SoC and one connected via i2c:

djurny@sinaspi:~$ ls /dev/rtc*
/dev/rtc  /dev/rtc0  /dev/rtc1

 

As the SoC RTC will be seen first by the kernel, i had to update the DTB to make it appear later than the i2c one:

 

Spoiler

/dts-v1/;

/ {
       compatible = "allwinner,sun4i-a10\0allwinner,sun7i-a20\0allwinner,sun8i-h3\0allwinner,sun50i-a64\0allwinner,sun50i-h5";

       fragment@0 {
               target-path = "/aliases";

               __overlay__ {
                       rtc0 = "/soc/i2c@1c2ac00/ds3231@68";
               };
       };

       fragment@1 {
               target = < 0xffffffff >;

               __overlay__ {
                       #address-cells = < 0x01 >;
                       #size-cells = < 0x00 >;

                       ds3231@68 {
                               compatible = "dallas,ds3232";
                               reg = < 0x68 >;
                               status = "okay";
                       };
               };
       };

       fragment@2 {
               target-path = "/aliases";

               __overlay__ {
                       rtc1 = "/soc/rtc@1f00000";
               };
       };

       fragment@3 {
               target = < 0xffffffff >;

               __overlay__ {

                       rtc@1f00000 {
                               status = "disabled";
                       };
               };
       };

       __fixups__ {
               i2c0 = "/fragment@1:target:0";
               rtc = "/fragment@3:target:0";
       };
};

 

The dtb is specifically for the OrangePi zero (1), so most likely not suitable for your SBC. But the idea might help you to fixup your dtb.

 

For my NanoPi neo3 i was not able to apply a dtb fix and had to make some oddball script (attached).

It would check for any RTC that is currently being synced by NTP and if i cannot find one (during boot and before NTP can sync) it will copy the date/time from the first "external" RTC it can find. If it finds NTP is sync'ed, it will write the wallclock to the external "freerunning" RTCs to make sure the "external" RTC will have a reasonably accurate time when the system power cycles/reboots. Let me know if this works for you.

 

About the dtb fixups, i cannot really remember unfortunately, but some other posts on here helped a lot. You can try here for more hints and things you can try:

 

Hope some of this might help your case,

Groetjes,

 

 

rtc-sync

[Ed van den Enden]

For my complete log and Banana pi M2 Zero data, see:

https://paste.armbian.com/yusewapuzi
 

Kernel: 6.12.23-current-sunxi

 

RTC module ds3231, connected to pin 3 and 5 (i2c0)

3.3V from 1 and 9

 

overlays=sun8i-h3-i2c0
dtoverlay=i2c-rtc,ds1307
 

[Ed van den Enden]

@djurny I believe the first code you show me is in "C" and is a ds3231 driver. The missing driver in the today kernel. (Kernel: 6.12.23-current-sunxi)
This driver would work for me but I have no clue how to compile.

The rtc-sync program, makes sense to me but how can I make it to run?

[djurny]

Hi @Ed van den Enden, the blob shown was a device tree overlay. The device tree is the non-PCI variant of PCI config spaces. It specifies which hardware is located where and on what bus and so on.

 

There are default device tree overlays for adding an 'external' RTC to the board, the one I shared is based on this, but just to make sure the 'external' will be 'found' first (and therefore updated by kernel).

 

Edit: to be clear - if you choose to use a device tree overlay where the RTC is listed as the first RTC in your system, you do not need to use the script. If you do not use the device tree overlay to put your external RTC first in line, you can try if the script suits your needs.

 

The scrip attached, you can just put on your system, somewhere in /usr/local/sbin/ would be my advice. To make it work, you have to trigger it during boot and on interval basis. I think I have it triggered from /etc/rc.local (not the best spot, but it works).

 

Set proper ownership (root as owner and anyone in the adm group can execute):

sudo chown root:adm /usr/local/sbin/rtc-sync
sudo chmod 0750 /usr/local/sbin/rtc-sync

 

Add to /etc/rc.local:

/usr/local/sbin/rtc-sync -A start

 

(Create and) Add to /etc/cron.d/rtc-sync:

*/22 * * * * root /usr/local/sbin/rtc-sync -A update

 

The cron job will start rtc-sync 'update' every 22 minutes, which checks if the wallclock is synchronized by ntp. If so, if will update the 'freerunning' clocks with the wallclock. 'freerunning' means "not updated by ntpd" in this case.

 

For all this to work, you do need to install and configure ntp. The ntp daemon will update the wallclock and the kernel will set the first RTC it sees (/dev/rtc0) with the adjusted wallclock it keeps. The kernel will not update any other RTC than the first one -> this is where the rtc-sync script will help. This update will happen every 11 minutes and is hardcoded in the kernel somewhere. (See https://unix.stackexchange.com/questions/285129/switch-off-11-minute-kernel-mode for some more info.)

 

Hope this all helps,

Groetjes,

 

PS I forgot why I added the link to the topic about the NTP server with external GPS receiver... I guess I sometimes get a little bit distra

Edited yesterday at 05:32 PM by djurny
Correct who updates the RTC - it's the kernel, not ntpd.

[djurny]

Hi @Ed van den Enden,

After checking your provided information:
 

[ 1.019881] sun6i-rtc 1f00000.rtc: registered as rtc0 
[ 1.019937] sun6i-rtc 1f00000.rtc: setting system clock to 2025-04-22T10:04:37 UTC (1745316277)

 

This actually shows the SoC provided RTC, not the i2c one. I cannot see any other RTC being picked up by the kernel, so it seems something is not working well with the overlay.

 

See below what you should expect to see:

Apr 24 22:12:12 blippi kernel: [    3.271653] sun6i-rtc 1f00000.rtc: registered as rtc1
Apr 24 22:12:12 blippi kernel: [    3.277001] sun6i-rtc 1f00000.rtc: RTC enabled
Apr 24 22:12:12 blippi kernel: [    5.455786] rtc-ds3232 0-0068: registered as rtc0
Apr 24 22:12:12 blippi kernel: [    5.462541] rtc-ds3232 0-0068: setting system clock to 2025-04-25T05:12:02 UTC (1745557922)

The messages mentioning sun6i-rtc are from the SoC, the ones mentioning rtc-ds3232 are from the i2c attached ds3231 (supported by the ds3232 module by the rtc0-i2c0-ds3231.dts overlay mentioned in the post at the bottom of this reply).

 

Can you list the contents of /boot/overlay* and /boot/overlay-user ? And also, can you share the contents of the dt overlay "i2c-rtc,ds1307" ? 

(Not sure if that is supposed to be seperated by whitespace or a comma.)

(Also not sure if 'dtoverlay=' is the correct keyword here, please check https://docs.armbian.com/User-Guide_Armbian_overlays/#armbianenvtxt-entries-reference to make sure you added the overlay correctly.)

 

While you are at it, any possibility to get the U-Boot output? That will show if the overlay can be found or not.

 

Groetjes,

 

PS Check the topic below for how the same RTC can be made working on an OrangePi 0, which uses the same SoC as the BananaPi M2 0. There are two dt overlay files mentioned there that should add the i2c RTC (and name it rtc0) and one that will 'rename' the SoC RTC to rtc1.

[djurny]

Hi @Ed van den Enden,

Checked a bit more on the internets and found that you have added the device overlay to your BanananaPi in the same manner as you have done on your RaspberryPi:

dtoverlay=i2c-rtc,ds1307

 

On armbian you add overlays using:

# armbian provided overlays
overlays=usbhost2 usbhost3 i2c0 uart1 pps-gpio
# user provided overlays
user_overlays=rtc0-i2c-ds3231-rtc1-soc

Also confirmed that boot.cmd indeed only expects to see user_overlays in the armbianEnv.txt and does not check for dtoverlay. You can check in /boot/dtb/overlay/ which armbian provided overlays are there, but for the i2c RTC you would need to add a user defined overlay.

 

Safest bet would be to use the armbian-add-overlay tool that will compile (and check) then add the overlay to your armbianEnv.txt using the keywords that will make sure the overlay is used during boot.

 

As mentioned before as well, you would need to have the device tree files handy for armbian-add-overlay to process them. These are .dts files and are human readable. The topic mentioned in the reply earlier has the two .dts device tree overlays that should also work for your case.

 

Groetjes,