How to setup ds3231 hardware RTC clock on Banana PI

Follwing the last post in this topic I added BALENA_HOST_CONFIG_dtparam “i2c-rtc,ds3231”

but after a restart the system loses the clock.

https://wiki.banana-pi.org/BPI_RTC_real_time_Module
This wiki suggest that the module should be detected at address 68
but when I run i2cdetect -y 2 from a privileged container slot 2 doesn’t exist.

Could you please suggest things I can try to enable the module.

I tried armbian with ``i2cdetect -y 2` and there it exists and I can read and write the time to the module.

balenaOS 2.46.1+rev2

1 Like

Thanks @krasi-georgiev for your message. Let me ask to the balenaOS team to get more information!

Thanks, I have enabled support access.

Maybe the first thing to establish is if the BALENA_HOST_CONFIG_dtparam is applied. When I print the env in a container and in the host I don’t see this env variable. How can I check if the i2c-rtc,ds3231 is enabled?

RESIN_APP_ID=145430
BALENA_APP_ID=145430
I360_STORE_ENABLED=false
I360_AUDIOR_CAPTUREDEVICE=default:CARD=sun4icodec
HOSTNAME=d697324
BALENA=1
RESIN_SUPERVISOR_VERSION=10.6.27
I360_CONTROLLERJAM_GPIOSTOPOFFSET=274
RESIN_APP_LOCK_PATH=/tmp/balena/updates.lock
BALENA_APP_LOCK_PATH=/tmp/balena/updates.lock
BALENA_SUPERVISOR_VERSION=10.6.27
PWD=/
I360_AUDIOR_RATE=48000
BALENA_SERVICE_NAME=i360
I360_REPORTERJAM_GPIOREADYOFFSET=259
BALENA_APP_NAME=kuakata
HOME=/root
I360_REPORTERJAM_GPIOAUDIOOFFSET=275
RESIN_SERVICE_NAME=i360
I360_SYNCER_ENABLED=false
I360_VIDEORRTSP_CAPTUREDEVICE=rtsp://192.168.1.10:554/stream1
RESIN_DEVICE_UUID=d6973249f77d4d928c43684653846b4d
I360_CONTROLLERJAM_GPIOSTARTOFFSET=273
TERM=xterm
I360_NODEID=kuakata
RESIN_APP_NAME=kuakata
USER=root
RESIN=1
BALENA_DEVICE_NAME_AT_INIT=wide-rock
BALENA_DEVICE_UUID=d6973249f77d4d928c43684653846b4d
SHLVL=1
I360_REPORTERJAM_GPIOSYNCOFFSET=275
I360_AUDIOR_RECTIMEOUT=10h
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
BALENA_DEVICE_TYPE=bananapi-m1-plus
RESIN_SERVICE_KILL_ME_PATH=/tmp/balena/handover-complete
RESIN_HOST_OS_VERSION=balenaOS 2.46.1+rev2
RESIN_DEVICE_NAME_AT_INIT=wide-rock
RESIN_DEVICE_TYPE=bananapi-m1-plus
BALENA_HOST_OS_VERSION=balenaOS 2.46.1+rev2
I360_CONTROLLERJAM_GPIOVIDEOOFFSET=275
I360_VIDEORRTSP_RECTIMEOUT=10h
BALENA_SERVICE_HANDOVER_COMPLETE_PATH=/tmp/balena/handover-complete

Hi Krasi,
can you confirm the device you are trying to debug it this one?
I tried to connect to it but can’t get any SSH access to investigate the internal state of the device.

You can get information about your device tree by exploring “/proc/device-tree/” on your hostOS, for instance with find /proc/device-tree/ -name "*rtc*".

You are also mentioning BALENA_HOST_CONFIG_dtparam but the forum link you posted specifies BALENA_HOST_CONFIG_dtoverlay, could you try changing this to see if it improves what you are seeing?

Thanks,
Aurélien

yes it is that device. for some reason, I can’t ssh using the device ID, but I can ssh using the local IP address.
noob mistake about the config name, I just added that one as well, but no difference.

How do I check that it is applied?

When I use i2cdetect -y 2 on armbian it detects the hardware clock on address 68, but on balena I get

Error: Could not open file /dev/i2c-2’ or /dev/i2c/2': No such file or directory

and i2cdetect -y 0 show nothing and i2cdetect -y 1 shows the output below, but nothing on address 68

i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  
find /proc/device-tree/ -name "*rtc*"
/proc/device-tree/soc@1c00000/rtc@1c20d00
/proc/device-tree/__symbols__/rtc

@wolvi-lataniere do you need any more details?

I can try to reflash the device to see if this will recover the vpn access if that helps

Hi @krasi-georgiev,

Thanks for the update. If you can restore VPN access I think it will help for the debugging. I don’t have that hardware on hand and can’t explore the file system to help without access.

you should have access now

Hi @krasi-georgiev,
Thanks for the link. I couldn’t go to it immediately, and now device is offline. Could you fix the issue or do you still want us to have a look?

Thanks,

Aurélien

yes please have a look the device id is different. I posted a link in my last message, but here it is again
It is online

@wolvi-lataniere did you manage to connect to the device?

Hi @krasi-georgiev,
Thanks for the link. I tried to connect on Monday but the connection was very lagy and I coudn’t do much back then. I’m retrying right now.

Hi again!

I think I finally pin pointed the issue, it seems you are missing the overlay directory in your SDCard boot partition, without it you wont be able to get the dtoverlay param to do anything (an overlay is an addition to your device tree, but has to come from somewhere at boot-time).

This is what your boot partition looks like:

root@9bdbb72:/mnt/boot# ls -la
total 8407
drwxr-xr-x 5 root root   16384 Jan  1  1970 .
drwxr-xr-x 6 root root    1024 Jan 13  2020 ..
-rwxr-xr-x 1 root root    2048 Jan  1  1980 FSCK0000.REC
-rwxr-xr-x 1 root root     604 Oct 16 15:15 config.json
-rwxr-xr-x 1 root root    2119 Jan 13  2020 device-type.json
drwxr-xr-x 2 root root    2048 Jan 13  2020 dtb
-rwxr-xr-x 1 root root      44 Jan 13  2020 image-version-info
-rwxr-xr-x 1 root root     208 Jan 13  2020 os-release
-rwxr-xr-x 1 root root      24 Jan 13  2020 resin-image
-rwxr-xr-x 1 root root     571 Jan 13  2020 resinos.fingerprint
drwxr-xr-x 2 root root    2048 Jan 13  2020 splash
drwxr-xr-x 2 root root    2048 Oct 16 15:19 system-connections
-rwxr-xr-x 1 root root  480829 Jan 13  2020 u-boot-sunxi-with-spl.bin
-rwxr-xr-x 1 root root 8087472 Jan 13  2020 uImage

and for instance, this is what a regular BalenaOS rasbperry pi boot partition looks like:

➜  resin-boot ls -la
total 8409
drwxr-xr-x  6 avalade avalade    3072 Jan  1  1970 .
drwxr-x---+ 7 root    root       4096 Nov  2 15:52 ..
-rw-r--r--  1 avalade avalade      24 Jun  1 19:53 balena-image
-rw-r--r--  1 avalade avalade   17578 Jun  1 19:53 balenaos.fingerprint
-rw-r--r--  1 avalade avalade   27696 Jun  1 19:53 bcm2708-rpi-b.dtb
-rw-r--r--  1 avalade avalade   27967 Jun  1 19:53 bcm2708-rpi-b-plus.dtb
-rw-r--r--  1 avalade avalade   27307 Jun  1 19:53 bcm2708-rpi-b-rev1.dtb
-rw-r--r--  1 avalade avalade   27581 Jun  1 19:53 bcm2708-rpi-cm.dtb
-rw-r--r--  1 avalade avalade   27441 Jun  1 19:53 bcm2708-rpi-zero.dtb
-rw-r--r--  1 avalade avalade   28792 Jun  1 19:53 bcm2708-rpi-zero-w.dtb
-rw-r--r--  1 avalade avalade   28842 Jun  1 19:53 bcm2709-rpi-2-b.dtb
-rw-r--r--  1 avalade avalade   28991 Jun  1 19:53 bcm2710-rpi-2-b.dtb
-rw-r--r--  1 avalade avalade   30647 Jun  1 19:53 bcm2710-rpi-3-b.dtb
-rw-r--r--  1 avalade avalade   31266 Jun  1 19:53 bcm2710-rpi-3-b-plus.dtb
-rw-r--r--  1 avalade avalade   28942 Jun  1 19:53 bcm2710-rpi-cm3.dtb
-rw-r--r--  1 avalade avalade   51675 Jun  1 19:53 bcm2711-rpi-400.dtb
-rw-r--r--  1 avalade avalade   51543 Jun  1 19:53 bcm2711-rpi-4-b.dtb
-rw-r--r--  1 avalade avalade   52116 Jun  1 19:53 bcm2711-rpi-cm4.dtb
-rw-r--r--  1 avalade avalade   52460 Jun  1 19:53 bootcode.bin
-rw-r--r--  1 avalade avalade     437 Jun  1 19:53 boot.scr
-rw-r--r--  1 avalade avalade     137 Jun  1 19:53 cmdline.txt
-rw-r--r--  1 avalade avalade     756 Aug  6  2021 config.json
-rw-r--r--  1 avalade avalade   36243 Jun  1 19:53 config.txt
-rw-r--r--  1 avalade avalade    2361 Jun  1 19:53 device-type.json
-rw-r--r--  1 avalade avalade       0 Jun  1 19:53 extra_uEnv.txt
-rw-r--r--  1 avalade avalade    3145 Jun  1 19:53 fixup_cd.dat
-rw-r--r--  1 avalade avalade    7223 Jun  1 19:53 fixup.dat
-rw-r--r--  1 avalade avalade   10199 Jun  1 19:53 fixup_x.dat
drwxr-xr-x  2 avalade avalade     512 Nov  2  2022 .fseventsd
-rw-r--r--  1 avalade avalade      41 Jun  1 19:53 image-version-info
-rw-r--r--  1 avalade avalade  489264 Jun  1 19:53 kernel7.img
-rw-r--r--  1 avalade avalade     157 Jun  1 19:53 os-release
drwxr-xr-x  2 avalade avalade   22016 Jun  1 19:53 overlays
-rw-r--r--  1 avalade avalade       0 Jun  1 19:53 rpi-bootfiles-20220120.stamp
drwxr-xr-x  2 avalade avalade     512 Aug  6  2021 splash
-rw-r--r--  1 avalade avalade  800028 Jun  1 19:53 start_cd.elf
-rw-r--r--  1 avalade avalade 2964864 Jun  1 19:53 start.elf
-rw-r--r--  1 avalade avalade 3716296 Jun  1 19:53 start_x.elf
drwxr-xr-x  2 avalade avalade     512 Jun  1 19:53 system-connections

on the second one I have an overlays folder with all possible overlays.

I’m not sure why it is missing here. You can try to replace it with the one you grab from your standard BananaPi distribution, they could be compatible.

Let us know if it helps.

this is the contents of the boot folder of the armbian.
It has overlay-user directory, but it is emtpy

Can you try to copy the content from the Rpi and check if it works?

Please feel free to do whatever with that BananaPi, there is no data and nothing important on it.

Hello Krasi, as you know, sadly you are using a balenaOS version which is not on production but staging. So not sure it makes sense to experiment on the device.

Having said that, we added this device to the OS test workflow (testbot) but currently the tests are failing. Once a new release passes test, it will be deployed to production, and at that moment we will be able to look into any issues for that production OS release.

Thanks.
Can you maybe explain what is the actual workflow with the dtoverlay logic from the linux perspective so that I can try and set it up manually?

1 Like