Hi Niresh,
Hi,
Sorry, i did mistake in copy paste, actually it is echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-2/new_device
I’ve tested BB-I2C2-RTC-DS3231.dtbo in the new image 4.19.94-ti-r42, they mount rtc1 in /dev but system time is not updated with rtc1. Attached dmesg with and without DS3231 overlay in uEnv.txt .
Following message with DS3231 overlay enabled.
root@beaglebone:/dev# hwclock -r -f /dev/rtc1
2000-01-01 00:49:21.771707+00:00
root@beaglebone:/dev# timedatectl
Local time: Tue 2020-09-01 04:34:29 UTC
Universal time: Tue 2020-09-01 04:34:29 UTC
RTC time: Tue 2020-09-01 04:34:29
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
debian@beaglebone:/dev$ dmesg | grep rtc
[ 1.280996] rtc-ds1307 2-0068: registered as rtc0
[ 1.283636] omap_rtc 44e3e000.rtc: already running
[ 1.284312] omap_rtc 44e3e000.rtc: registered as rtc1
[ 1.574739] [drm] Cannot find any crtc or sizes
[ 1.604280] rtc-ds1307 2-0068: setting system clock to 2020-09-01 04:30:36 UTC (1598934636)
[ 2.600387] [drm] Cannot find any crtc or sizes
[ 56.285738] PM: bootloader does not support rtc-only!
debian@beaglebone:/dev$ dmesg | grep i2c
[ 0.315725] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[ 0.317402] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[ 1.286054] i2c /dev entries driver
[ 1.590657] input: tps65217_pwr_but as /devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024/tps65217-pwrbutton/input/input0
[ 1.592768] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
Thanks,
NK
dmesg with DS3231 dtb overlay - Copy.txt (21 KB)
dmesg without DS3231 dtb overlay.txt (21.1 KB)
Hi Niresh,
I've tested BB-I2C2-RTC-DS3231.dtbo in the new image 4.19.94-ti-r42, they mount rtc1 in /dev but system time is not updated with rtc1. Attached dmesg with and without DS3231 overlay in uEnv.txt .
Following message with DS3231 overlay enabled.root@beaglebone:/dev# hwclock -r -f /dev/rtc1
2000-01-01 00:49:21.771707+00:00
That's OK. The device tree swaps rtc0 and rtc1. Now your DS3231 is /dev/rtc0 - which is what you need.
The AM335x-s RTC is /dev/rtc1 - it goes back to year 2000 on every boot. You don't need it.
root@beaglebone:/dev# timedatectl
Local time: Tue 2020-09-01 04:34:29 UTC
Universal time: Tue 2020-09-01 04:34:29 UTC
RTC time: Tue 2020-09-01 04:34:29
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
Seems to be correct. "RTC time" is your DS3231.
debian@beaglebone:/dev$ dmesg | grep rtc
[ 1.280996] rtc-ds1307 2-0068: registered as rtc0
[ 1.283636] omap_rtc 44e3e000.rtc: already running
[ 1.284312] omap_rtc 44e3e000.rtc: registered as rtc1
[ 1.574739] [drm] Cannot find any crtc or sizes
[ 1.604280] rtc-ds1307 2-0068: setting system clock to 2020-09-01 04:30:36 UTC (1598934636)
That's your DS3231 being assigned /dev/rtc0 by the kernel and the system time correctly set from it. Looks good.
The last step is to enable NTP synchronization:
$ sudo timedatectl set-ntp true
Then you're done. When network comes online, systemd-timesyncd will synchronize both your DS3231 and the system time from NTP. Feel free to fine-tune ("man timedatectl" and man "timesyncd.conf").
Hi,
I am a bit confused. Please correct me if I am wrong. I have removed the internet connection, power to the board and battery from the external RTC DS3231 module too.
Its ok, the device tree swaps rtc0 and rtc1 but the system time is not updated with external RTC time after boot.
Powering up the board without internet connection and external RTC resetted to default time.
debian@beaglebone:~$ timedatectl
Local time: Tue 2020-09-01 10:32:27 UTC
Universal time: Tue 2020-09-01 10:32:27 UTC
RTC time: Sat 2000-01-01 00:15:42
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
Reconnecting internet connection.
debian@beaglebone:~$ timedatectl
Local time: Tue 2020-09-01 10:47:37 UTC
Universal time: Tue 2020-09-01 10:47:37 UTC
RTC time: Tue 2020-09-01 10:47:37
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
debian@beaglebone:~$ hwclock -r -f /dev/rtc1
2000-01-01 00:17:30.204350+00:00
debian@beaglebone:~$ sudo hwclock -r -f /dev/rtc0
2020-09-01 10:48:49.965
Regards,
NK
I am a bit confused. Please correct me if I am wrong. I have removed the internet connection, power to the board and battery from the external RTC DS3231 module too.
Well, removing the battery will reset your DS3231. This defeats the purpose of having a battery powered RTC.
Its ok, the device tree swaps rtc0 and rtc1 but the system time is not updated with external RTC time after boot.
Powering up the board without internet connection and external RTC resetted to default time.
Yes, because you disconnected the battery from the RTC. Don't.
Hi,
I purposefully disconnected the battery to confirm system time updates with external RTC time. But the below message shows not updated right.
Local time: Tue 2020-09-01 10:32:27 UTC
Universal time: Tue 2020-09-01 10:32:27 UTC
RTC time: Sat 2000-01-01 00:15:42
Regards,
NK
Ah, you're expecting the system time to be set to 2000-01-01? Won't happen. RTC knows it's been reset and because of that the system refuses to sync with it.
The reason why your system time is close to accurate (but still off by several minutes, if you check) after everything has been powered off is due to a fallback method in timesyncd. It will occasionally (e.g. on NTP sync and on shutdown) store the current timestamp in a magic file on disk. If there is no source of time available during boot (no RTC and no NTP) then timesyncd will declare the value of that timestamp as current time. At least it guarantees a monotonously increasing time.
Hi,
You are right, I’ve done a little experiment to confirm the same.
Test #1: Made both system and RTC time synchronized with 2020-09-02 09:00:30 and then rebooted , both time syncs.
Test #2: Made RTC time delay with an hour by using command hwclock --set --date "09/02/20 08:00:30 "and system time 2020-09-02 09:00:30 and then rebooted. Now, the system time is not sync with RTC,it remains unchanged 2020-09-02 09:00:30
Test #3: Made RTC time advance with an hour by using command hwclock --set --date "09/02/20 10:00:30 "and system time 2020-09-02 09:00:30 and then rebooted. Now, the system time is sync with RTC, that’s with 2020-09-02 10:00:30
Could you please tell me starts from which version of kernel “BB-I2C2-RTC-DS3231.dtbo” device tree works. I will tell you why, I was using arm-linux-gnueabihf-gcc-4.9 to compile my application code in the 4.4.30-ti-r64 kernel, and it compiled and ran perfectly. Now the same application code gives me an error message with compiler arm-linux-gnueabihf-gcc-8 in the new image 4.19.94-ti-r42.
Like I said before, I am not a linux guy and the developer, who coded this and has left the organisation, cautioned me to stick with 4.4.30-ti-r64 kernel for stable operation of application code. Please advise which version is good to go and how to overcome this issue.
Regards,
NK
Hi Niresh,
You are right, I've done a little experiment to confirm the same.
Good to hear!
Could you please tell me starts from which version of kernel "BB-I2C*2*-RTC-DS3231.dtbo" device tree works. I will tell you why, I was using arm-linux-gnueabihf-gcc-4.9 to compile my application code in the 4.4.30-ti-r64 kernel, and it compiled and ran perfectly. Now the same application code gives me an error message with compiler arm-linux-gnueabihf-gcc-8 in the new image 4.19.94-ti-r42.
Like I said before, I am not a linux guy and the developer, who coded this and has left the organisation, cautioned me to stick with 4.4.30-ti-r64 kernel for stable operation of application code. Please advise which version is good to go and how to overcome this issue.
I haven't a clue.
Looking at the the larger picture, the Debian distribution installed on your BeagleBone (version 10 a.k.a. "buster") is happy to work with a few different versions of the gcc compiler and the kernel. The problem here is that you're looking to use some really old stuff.
Regarding gcc - Debian 10 has out of box support for gcc-7 and gcc-8, but not gcc-4. You can search for older versions (e.g. "apt-cache search gcc-7") and install them (e.g. "sudo apt install gcc-7").
If gcc-4.9 is really required, you might try the official packages from Debian 8 "jessie" (when it was last supported), but it's going to be tricky to install and leave the package system in a weird state. You can also compile gcc-4.9 yourself from source :). As an alternative, you can try to keep your code up to date with newer compiler releases and try fixing the code so it compiles with gcc-8.
Regarding the kernel - there are probably old kernel releases which are OK to use on Debian 10 and might even support the recent device trees that you need. You can search for them in the package system (e.g. "apt-cache search 'kernel-image.*4.4.30*'") but I have no idea what happens if you install them. Maybe Robert can comment on that.
Sorry, the search term is probably 'linux-image*4.4.30*', I don't remember what the BB-s kernel packages were named.
Can you share the actual "error message"?
Regards,
Hi Tarmo,
Thank you for your suggestion.
I have a few queries related to USB dongle connection to BBB and mutex operation. Shall I ask that query in this post or separate?
Regards,
NK
Hi,
The error messages during compiling of my smartmeter application code written in c language are
/usr/bin/ld: rtc_time.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol’ can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: jsparser.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol’ can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: populateListFromFile.o: relocation R_ARM_THM_MOVW_ABS_NC against `file1’ can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: readFromFileNPopulateList.o: relocation R_ARM_THM_MOVW_ABS_NC against `file1’ can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: jsparser.o(.text+0x46): unresolvable R_ARM_THM_CALL relocation against symbol `json_object_get_boolean’
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [Makefile:152: smartmeter] Error 1
Regards,
NK
I’d recommend a new thread for a new topic.
Thank you, I posted my mutex lock query in https://groups.google.com/g/beagleboard/c/-9GlXf8Y9ns.
Regards,
NK
Tarmo:
I’ve been following this with some interest and finally got around to trying it on my BBB running the 2020-04-06 release.
I have an external DS3231 connected to I2C2. I’ve got it working and mounted as RTC1, but the magic of swapping the DS3231 for the AM335x-s is not happening for me.
I have confirmed the DS3231 is RTC1 by the simple method of asking for the time with the I2C jumpers disconnected, which results in an error. Reconnecting the jumpers restores operation of RTC1. RTC0 works whether the jumpers are connected or not.
I added the dtb_overlay command to /boot/uEnv.txt and restarted. I don’t have an rc.local file, so I ran echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-2/new_device from the command line after rebooting.
What is needed so that the device tree swaps the two clocks, making the external DS3231 RTC0, as indicated in the thread below? Is this something in the alpha image?
Thx,
-Steve
Let's check some things, please provide a dump of:
sudo /opt/scripts/tools/version.sh
Regards,
Robert:
Here you go; thanks for looking into this.
-Steve
debian@beaglebone:/dev$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[7cdc270818b76d829d247cf05fe309c320a3929a]
eeprom:[A335BNLTEIA04218BBBK03D9]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
UBOOT: Loaded Overlay:[BBORG_PROTO-00A2]
kernel:[4.19.94-ti-r47]
nodejs:[v10.21.0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait uboot_detected_capes=BBORG_PROTO, coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 58.172688] remoteproc remoteproc0: wkup_m3 is available
[ 58.383916] remoteproc remoteproc0: powering up wkup_m3
[ 58.383945] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[ 58.384202] remoteproc remoteproc0: remote processor wkup_m3 is now up
[ 62.993005] remoteproc remoteproc1: 4a334000.pru is available
[ 63.024061] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[ 62.993005] remoteproc remoteproc1: 4a334000.pru is available
[ 62.993220] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[ 63.024061] remoteproc remoteproc2: 4a338000.pru is available
[ 63.024270] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[ 0.952687] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[ 0.966071] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
This is the second time i've seen this.. is there a wiki somewhere
showing the spaces??? We need to NUKE that asap..
dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo
Regards,
Good now. It’s what comes from retyping commands from mailing lists while being spoiled by a lifetime of parsers that ignore whitespace. I do not know the original source.
Thanks,
-Steve