How to automatically set system time of BBB by external DS3231

[Niresh Kumar]

Hi,

I am using beagle Bone Black with debian image. Could any please suggest how to automatically set the system time (on every reboot) by external RTC module DS3231. Once internet is connected, i want to update both system time and DS3231 with the network time.

I am controlling a relay based on system time, my application should take DS3231 time and run perfectly even if internet is disconnected and not available for so many days.

Few things i have tried, the following content has been kept in the script and running @reboot script in crontab. The system time has been changed if we enter this command manually after boot but not in auto start script. Please advice.

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

hwclock -r -f /dev/rtc1

Best regards,

NK

[Robert Heller]

At Tue, 18 Aug 2020 02:40:41 -0700 (PDT) beagl...@googlegroups.com wrote:

>
>
>
> Hi,
>
> I am using beagle Bone Black with debian image. Could any please suggest
> how to automatically set the system time (on every reboot) by external RTC
> module DS3231. Once internet is connected, i want to update both system
> time and DS3231 with the network time.
>
> I am controlling a relay based on system time, my application should take
> DS3231 time and run perfectly even if internet is disconnected and not
> available for so many days.
>
> Few things i have tried, the following content has been kept in the script
> and running @reboot script in crontab. The system time has been changed if
> we enter this command manually after boot but not in auto start script.
> Please advice.
>

> *echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device*
>
> *hwclock -r -f /dev/rtc1*

Well, the simple / dumb option would be to put the above two lines in
/etc/rc.local, which will restore the system clock from the RTC.

The other option is to create a proper RTC service. A properly setup RTC
service will restore the system clock from the RTC early in the boot process
and save the system clock late in the shutdown process.

>
> Best regards,
>
> NK
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Tarmo]

On Tuesday, 18 August 2020 14:45:23 UTC+3, Robert Heller wrote:

At Tue, 18 Aug 2020 02:40:41 -0700 (PDT) beagl...@googlegroups.com wrote:
> I am using beagle Bone Black with debian image. Could any please suggest
> how to automatically set the system time (on every reboot) by external RTC
> module DS3231. Once internet is connected, i want to update both system
> time and DS3231 with the network time.
>
> I am controlling a relay based on system time, my application should take
> DS3231 time and run perfectly even if internet is disconnected and not
> available for so many days.
>
> Few things i have tried, the following content has been kept in the script
> and running @reboot script in crontab. The system time has been changed if
> we enter this command manually after boot but not in auto start script.
> Please advice.
>
> *echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device*
>
> *hwclock -r -f /dev/rtc1*

Well, the simple / dumb option would be to put the above two lines in
/etc/rc.local, which will restore the system clock from the RTC.

The other option is to create a proper RTC service.  A properly setup RTC
service will restore the system clock from the RTC early in the boot process
and save the system clock late in the shutdown process.

 

A proper RTC service is already implemented by the systemd-timesyncd service, installed by default on the debian images:

https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html

It does everything Niresh needs out of box. There's a caveat: systemd-timesyncd only works with /dev/rtc0 device. By default /dev/rtc0 is grabbed by the AM335x CPU-s internal RTC (which has no battery backup) and the external RTC is left with /dev/rtc1 which gets ignored. I did not find any way to configure systemd-timesyncd to use the other device.

Robert pointed me to a device tree which very conveniently swapped the device nodes for those RTCs so the external one got /dev/rtc0. I just had to load the device tree via /boot/uEnv.txt and time syncing worked beautifully. For Niresh, I suggest trying this one:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS3231.dts

--

Kind regards,

Tarmo

[Tarmo]

To clarify the "trying" step: you'll probably find the compiled device tree in the Beagle's file system: "/lib/firmware/BB-I2C2-RTC-DS3231.dtb". Just add this to /boot/uEnv.txt using standard method and reboot. Monitoring the boot log via dmesg should tell you which RTC device was awarded /dev/rtc0.

--

Kind regards,

Tarmo

[Niresh Kumar]

Hi,

1). I have placed the following lines in the  /etc/rc.local, and system time gets updated with external RTC DS3231 automatically at every reboot

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

hwclock -s -f /dev/rtc1

 

dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/340040ae-d9d1-4f28-9518-ec4f5ab8ac1eo%40googlegroups.com.

[Niresh Kumar]

Hi,

I have put the line dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo  in  /boot/uEnv.txt but it does not create /dev/rtc1. The dmesg are

root@beaglebone:/dev# dmesg | grep 3231

[    2.132312] console [ttyS0] enabled

root@beaglebone:/dev# dmesg | grep rtc

[    2.221605] omap_rtc 44e3e000.rtc: already running

[    2.222249] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[    2.572035] PM: bootloader does not support rtc-only!

[    2.573042] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 02:14:15 UTC (946692855)

root@beaglebone:/dev# dmesg | grep rtc1

root@beaglebone:/dev#

root@beaglebone:/dev# dmesg | grep rtc

[    2.221605] omap_rtc 44e3e000.rtc: already running

[    2.222249] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[    2.572035] PM: bootloader does not support rtc-only!

[    2.573042] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 02:14:15 UTC (946692855)

root@beaglebone:/dev# date

Tue Jul 14 13:07:39 IST 2020

root@beaglebone:/dev# hwclock -r -f /dev/rtc

Sat 01 Jan 2000 07:46:54 AM IST  -0.651632 seconds

[Niresh Kumar]

Hi,

1). I have placed the following lines in the  /etc/rc.local, and system time gets updated with external RTC DS3231 automatically at every reboot

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

hwclock -s -f /dev/rtc1

2) I have put the line dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo  in  /boot/uEnv.txt but it does not create /dev/rtc1 and system time not updated with external RTC DS3231. The dmesg are

root@beaglebone:/dev# dmesg | grep 3231

[    2.132312] console [ttyS0] enabled

root@beaglebone:/dev# dmesg | grep rtc

[    2.221605] omap_rtc 44e3e000.rtc: already running

[    2.222249] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[    2.572035] PM: bootloader does not support rtc-only!

[    2.573042] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 02:14:15 UTC (946692855)

root@beaglebone:/dev# dmesg | grep rtc1

root@beaglebone:/dev#

root@beaglebone:/dev# dmesg | grep rtc

[    2.221605] omap_rtc 44e3e000.rtc: already running

[    2.222249] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0

[    2.572035] PM: bootloader does not support rtc-only!

[    2.573042] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 02:14:15 UTC (946692855)

root@beaglebone:/dev# date

Tue Jul 14 13:07:39 IST 2020

root@beaglebone:/dev# hwclock -r -f /dev/rtc

Sat 01 Jan 2000 07:46:54 AM IST  -0.651632 seconds

Best regards,

NK

[Robert Nelson]

On Thu, Aug 20, 2020 at 8:22 AM Niresh Kumar <nireshs...@gmail.com> wrote:
>
> Hi,
> 1). I have placed the following lines in the /etc/rc.local, and system time gets updated with external RTC DS3231 automatically at every reboot
>
> echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
>
> hwclock -s -f /dev/rtc1
>
> 2) I have put the line dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo in /boot/uEnv.txt but it does not create /dev/rtc1 and system time not updated with external RTC DS3231. The dmesg are
>
> root@beaglebone:/dev# dmesg | grep 3231
>
> [ 2.132312] console [ttyS0] enabled
>
>
> root@beaglebone:/dev# dmesg | grep rtc
>
> [ 2.221605] omap_rtc 44e3e000.rtc: already running
>
> [ 2.222249] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
>
> [ 2.572035] PM: bootloader does not support rtc-only!
>
> [ 2.573042] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 02:14:15 UTC (946692855)
>
>
> root@beaglebone:/dev# dmesg | grep rtc1
>
> root@beaglebone:/dev#
>
> root@beaglebone:/dev# dmesg | grep rtc
>
> [ 2.221605] omap_rtc 44e3e000.rtc: already running
>
> [ 2.222249] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
>
> [ 2.572035] PM: bootloader does not support rtc-only!
>
> [ 2.573042] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 02:14:15 UTC (946692855)
>
>
> root@beaglebone:/dev# date
>
> Tue Jul 14 13:07:39 IST 2020
>
>
> root@beaglebone:/dev# hwclock -r -f /dev/rtc
>
> Sat 01 Jan 2000 07:46:54 AM IST -0.651632 seconds

Please run:

sudo /opt/scripts/tools/version.sh

and share it's output, so we can comment on your configuration.

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Ray Willis]

Did you make changes to that .dts and properly rebuild it and install it with the install.sh script?

If it's in the uEnv.txt file properly, it should be loaded. That overlay is pre-built into the initrd.img.

[Niresh Kumar]

We did not make any changes to the .dts file. uEnv.txt file attached for your reference.

There is no script "verison.sh" in the path /opt/scripts/tools/ in kernel version 4.4.30-ti-r64. 

On Thu, Aug 20, 2020 at 7:39 PM 'Ray Willis' via BeagleBoard <beagl...@googlegroups.com> wrote:

Did you make changes to that .dts and properly rebuild it and install it with the install.sh script?

If it's in the uEnv.txt file properly, it should be loaded. That overlay is pre-built into the initrd.img.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1b12d312-a238-42a9-8898-36c676a5bec2o%40googlegroups.com.

[Tarmo]

On Friday, 21 August 2020 06:13:24 UTC+3, Niresh Kumar wrote:

We did not make any changes to the .dts file. uEnv.txt file attached for your reference.

There is no script "verison.sh" in the path /opt/scripts/tools/ in kernel version 4.4.30-ti-r64. 

Wow, you're running a rather old Debian release. The stuff that I suggested was likely not implemented back then. I would upgrade to a recent Debian release:
http://beagleboard.org/getting-started

Note to whoever maintains beagleboard.org: the Letsencrypt SSL cert expired 3 days ago.

--

Kind regards,

Tarmo

[Robert Nelson]

On Thu, Aug 20, 2020 at 10:13 PM Niresh Kumar <nireshs...@gmail.com> wrote:
>
> We did not make any changes to the .dts file. uEnv.txt file attached for your reference.
>
> There is no script "verison.sh" in the path /opt/scripts/tools/ in kernel version 4.4.30-ti-r64.

Then the version of u-boot is way way way to old. PS, on a newer image
this wouldn't work:

dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo
->
dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo

U-Boot's parser doesn't like the "space"...

Feel Free to upgrade.

[Alexander Zangerl]

On Thu, 20 Aug 2020 00:40:38 -0700, Niresh Kumar writes:
>1). I have placed the following lines in the /etc/rc.local, and system
>time gets updated with external RTC DS3231 automatically at every reboot
>

>*echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device*
...
>
>2) I have put the line *dtb_overlay =
>/lib/firmware/BB-I2C2-RTC-DS3231.dtbo * in /boot/uEnv.txt but it does not


the overlay you're using won't work because your rtc chip is
on i2c bus one: as its name (...I2C2...) indicates it's for a
clock chip being on i2c bus two.

use dtc to decompile that overlay, edit for i2c1 and dtc it back into
binary form.


--
Best Regards,
Alexander Zangerl
IT Engineer

BREATHE-SAFE intelligent cabin air filtration
Keeps your lungs and cabin dust free!
Head Office: 37-43 Argon Street, Carole Park QLD 4300 Australia
Western Australia: 169 Chisholm Crescent, Kewdale WA 6105
Tel: +61 7 3276 7833 M. +61 415 482 341 E. a...@breathe-safe.com

[Tarmo]

On Monday, 24 August 2020 00:12:39 UTC+3, Alexander Zangerl wrote:

On Thu, 20 Aug 2020 00:40:38 -0700, Niresh Kumar writes:
>1). I have placed the following lines in the  /etc/rc.local, and system
>time gets updated with external RTC DS3231 automatically at every reboot
>
>*echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device*
...
>
>2) I have put the line *dtb_overlay =
>/lib/firmware/BB-I2C2-RTC-DS3231.dtbo * in  /boot/uEnv.txt but it does not


the overlay you're using won't work because your rtc chip is
on i2c bus one: as its name (...I2C2...) indicates it's for a
clock chip being on i2c bus two.

use dtc to decompile that overlay, edit for i2c1 and dtc it back into
binary form.

Good catch, although it's probably not necessary to decompile binary trees as the source is available here together with a nice makefile to build a single overlay:

https://github.com/beagleboard/bb.org-overlays

Without having tested it, I might imagine a process similar to this one:

$ git clone https://github.com/beagleboard/bb.org-overlays.git
$ cd bb.org-overlays
$ cp src/arm/BB-I2C2-RTC-DS3231.dts src/arm/BB-I2C1-RTC-DS3231.dts
$ vim src/arm/BB-I2C1-RTC-DS3231.dts
... update I2C bus number ...
$ make src/arm/BB-I2C1-RTC-DS3231.dtbo
$ cp src/arm/BB-I2C1-RTC-DS3231.dtbo /lib/firmware

--

Kind regards,

Tarmo

[Niresh Kumar]

Hi,

I am a newbie to the linux environment and BBB, your information is very helpful.

I've have tested both BB-I2C1-RTC-DS3231.dtbo and  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. Please let me know if any other procedure is required and also procedure to update external rtc1 time when the internet is connected.

One thing i have observed, with BB-I2C1-RTC-DS3231.dtbo the timedatectl command displayed "RTC time: n/a" not system time as in normal condition. 

Please clarify the following points

1.  How do you say the rtc chip is in i2c bus one. Using i2cdetect command "i2cdetect -r 2" , 0x68 external device showed in i2c bus two.

2. I understand overlay is an out of  box approach. In 4.4.30-ti-r64, system time updated with "echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device; hwclock -r -f /dev/rtc1" in  /etc/rc.local. Is there any problem if I use this approach in older images? 

Regards,

NK

 

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ffd21cc3-37ea-4526-80da-b4e1ae428d66o%40googlegroups.com.

[Tarmo]

On Thursday, 27 August 2020 08:07:53 UTC+3, Niresh Kumar wrote:

I've have tested both BB-I2C1-RTC-DS3231.dtbo and  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. Please let me know if any other procedure is required and also procedure to update external rtc1 time when the internet is connected.

That's unfortunate. Still, logs from the uboot bootloader (observed from the onboard TTL level UART) or the Linux kernel (from dmesg or syslog) might indicate what's wrong.

To get effective help, please post output from "sudo /opt/scripts/tools/version.sh" and the content of your "/boot/uEnv.txt" file.

 

One thing i have observed, with BB-I2C1-RTC-DS3231.dtbo the timedatectl command displayed "RTC time: n/a" not system time as in normal condition. 

Weird. I would interpret it as the AM335x internal RTC having been pushed aside from /dev/rtc0 successfully, but the external RTC does not pick the device up. 

 

Please clarify the following points

1.  How do you say the rtc chip is in i2c bus one. Using i2cdetect command "i2cdetect -r 2" , 0x68 external device showed in i2c bus two.

There might be differences in how different systems count buses. One might start from 0 and other from 1. TBH it's always been confusing as hell for me.

 

2. I understand overlay is an out of  box approach. In 4.4.30-ti-r64, system time updated with "echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device; hwclock -r -f /dev/rtc1" in  /etc/rc.local. Is there any problem if I use this approach in older images? 

 No, go right ahead. You're left with the task of figuring out a solution for syncing time between the RTC, system clock and NTP - as you wrote out in the very first message. My suggestion was to have systemd-timesyncd do it for you, but you can, as an alternative, do it yourself with a few bash scripts. 

--

Kind regards,

Tarmo

[Robert Nelson]

On Fri, Aug 28, 2020 at 6:31 AM Tarmo <tarmo...@gmail.com> wrote:
>
> On Thursday, 27 August 2020 08:07:53 UTC+3, Niresh Kumar wrote:
>>
>> I've have tested both BB-I2C1-RTC-DS3231.dtbo and 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. Please let me know if any other procedure is required and also procedure to update external rtc1 time when the internet is connected.
>
>
> That's unfortunate. Still, logs from the uboot bootloader (observed from the onboard TTL level UART) or the Linux kernel (from dmesg or syslog) might indicate what's wrong.
>
> To get effective help, please post output from "sudo /opt/scripts/tools/version.sh" and the content of your "/boot/uEnv.txt" file.
>
>>
>> One thing i have observed, with BB-I2C1-RTC-DS3231.dtbo the timedatectl command displayed "RTC time: n/a" not system time as in normal condition.

Every RTC clock is a little different, but sometimes it seems like you
have to "force" the first date write, try a few of these random
commands. ;)

https://www.thegeekstuff.com/2013/08/hwclock-examples/

[Niresh]

Hi,

Attached output from "sudo /opt/scripts/tools/version.sh" and the content of your "/boot/uEnv.txt" file along with boot log message.

debian@beaglebone:/boot$ dmesg | grep rtc1

[    2.285972] omap_rtc 44e3e000.rtc: registered as rtc1

debian@beaglebone:/boot$ dmesg | grep rtc

[    2.283660] rtc-ds1307: probe of 1-0068 failed with error -16

[    2.285972] omap_rtc 44e3e000.rtc: registered as rtc1

[    2.574770] [drm] Cannot find any crtc or sizes

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

[    3.592324] [drm] Cannot find any crtc or sizes

[   57.824450] PM: rtc0 not available

[   59.781548] PM: rtc0 not available

[   59.958344] PM: rtc0 not available

[   60.042066] PM: rtc0 not available

debian@beaglebone:/boot$

Please help me with bash scripts for external RTC and its procedure.

Regards,

NK

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgrYbKzRcC3xfQWaqh1Yp5_ZSQBfyr%3Di-_a1fAxApYfoQ%40mail.gmail.com.

[Tarmo]

Hi Niresh,

On Monday, 31 August 2020 06:45:48 UTC+3, Niresh wrote:

Attached output from "sudo /opt/scripts/tools/version.sh" and the content of your "/boot/uEnv.txt" file along with boot log message.

They look good. I suspect you're mostly there :)

debian@beaglebone:/boot$ dmesg | grep rtc

[    2.283660] rtc-ds1307: probe of 1-0068 failed with error -16

This indicates that the device tree was loaded correctly, but the kernel can't talk to your RTC chip. If you can figure out why, you've enabled systemd-timesyncd.

Hmm, can you double-check that the I2C bus number is correct and the RTC chip is online?

There is a utility called i2cdetect which should reveal your RTC on bus 1, address 68. 
https://linux.die.net/man/8/i2cdetect

 

Please help me with bash scripts for external RTC and its procedure.

Undo your changes to uEnv.txt and follow this guide instead. It's not ideal, but probably covers the relevant requirements.

https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/set-rtc-time

--

Kind regards,

Tarmo

[Niresh]

Hi,

debian@beaglebone:/dev$ i2cdetect -r -y 2

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

debian@beaglebone:/dev$ i2cdetect -r -y 1

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

debian@beaglebone:/dev$ i2cdetect -r -y 0

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- 34 -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: UU -- -- -- -- -- -- --

debian@beaglebone:/dev$

Regards,

NK

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/500b2fb8-177f-4a6e-885a-1d0c612f2e24o%40googlegroups.com.

[Tarmo]

Hi Niresh,

On Monday, 31 August 2020 14:14:05 UTC+3, Niresh wrote:

Hi,

debian@beaglebone:/dev$ i2cdetect -r -y 2

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

Looks like your RTC is connected to I2C bus number 2 (counting starts from 0).

I'm a bit confused. How could the command in your initial post pass and create a working RTC device? You were addressing the wrong bus (number 1) here:

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

Anyway, if you're really connecting the RTC to bus 2 then "BB-I2C2-RTC-DS3231.dtbo" should be your device tree.

--

Kind regards,

Tarmo

[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

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ed5f7cb9-873a-44d0-8715-c5c624f046d4o%40googlegroups.com.

[Tarmo Kuuse]

Hi Niresh,

On 01.09.20 07:43, Niresh wrote:
> 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").

--
Kind regards,
Tarmo

[Niresh]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a8f8f997-41a5-8032-4c21-e8cc425b49ae%40gmail.com.

[Tarmo Kuuse]

On 01.09.20 13:59, Niresh wrote:
> 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.

--
Kind regards,
Tarmo

[Niresh]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/342c4a25-ccc0-f69b-3039-028c3cc59485%40gmail.com.

[Tarmo Kuuse]

On 01.09.20 14:55, Niresh wrote:
> 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_

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.

--
Kind regards,
Tarmo

[Niresh]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/338861fc-3973-12a5-e0e9-6fc979c9dfc3%40gmail.com.

[Tarmo Kuuse]

Hi Niresh,

On 02.09.20 08:41, Niresh wrote:
> 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.

--
Kind regards,
Tarmo

[Tarmo Kuuse]

On 02.09.20 11:55, Tarmo Kuuse wrote:
> "apt-cache search 'kernel-image.*4.4.30*'") but I have no idea what

Sorry, the search term is probably 'linux-image*4.4.30*', I don't
remember what the BB-s kernel packages were named.

--
Kind regards,
Tarmo

[Robert Nelson]

On Wed, Sep 2, 2020 at 12:41 AM Niresh <nireshs...@gmail.com> wrote:
>
> 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.

Can you share the actual "error message"?

[Niresh]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgMqVpXgg6qJ1fgtkCbJCY2f8OtcDfVEYbYW3CWbFA0rw%40mail.gmail.com.

[Niresh]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/m4hZYsA-d8M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgMqVpXgg6qJ1fgtkCbJCY2f8OtcDfVEYbYW3CWbFA0rw%40mail.gmail.com.

[Tarmo Kuuse]

I'd recommend a new thread for a new topic. 

--
Tarmo

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAF7-PaQSOLy9q65Fth%3DjMkAEL5rQSaxGchrDM4%2Bzvtuj8%3D7jaA%40mail.gmail.com.

[Niresh]

Thank you, I posted my mutex lock query in  https://groups.google.com/g/beagleboard/c/-9GlXf8Y9ns.

Regards,

NK

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAPW7rrJHwEoP7%2B1wLK4LWZb0UCapyw%3D_0HrP3%2BMExgF%2B1d%3D96g%40mail.gmail.com.

[Steve Lentz]

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

> --
> For more options, visit http://beagleboard.org/discuss

> --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a8f8f997-41a5-8032-4c21-e8cc425b49ae%40gmail.com.

[Robert Nelson]

On Fri, Sep 4, 2020 at 9:59 AM Steve Lentz <stl...@gmail.com> wrote:
>
> 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?

Let's check some things, please provide a dump of:

sudo /opt/scripts/tools/version.sh

[Steve Lentz]

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

[Robert Nelson]

On Fri, Sep 4, 2020 at 10:28 AM Steve Lentz <stl...@gmail.com> wrote:
>
> 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]

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

[Steve Lentz]

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

[Steve Lentz]

Robert:

Is there a way to make the external DS3231 the wakeup device?  Just like in this RaspPi thread, I want to set the alarm and use the INT pin on the clock chip to activate something.  

https://www.reddit.com/r/raspberry_pi/comments/bn2ht5/ds3231_rtc_using_the_alarm_function/

The RaspPi dtoverlay command seems to use a different format and I’m at a loss how to translate this.

I’ve already made the INT pin work using Adafruit's python libraries for the DS3231, but I’d like to use the linux tools if possible - then I can also use the clock to set the system time.  Of course if the device tree is using the clock, the python libraries can’t get to it.  

Thanks again,

[robert.sty...@gmail.com]

I do not know the AM3358 of the BBB, but from the schematic

P9.42 GPIO0_7 is XDMA_EVENT_INTR2

[Robert Nelson]

On Fri, Sep 4, 2020 at 3:13 PM robert.sty...@gmail.com
<robert.sty...@gmail.com> wrote:
>
> I do not know the AM3358 of the BBB, but from the schematic
> P9.42 GPIO0_7 is XDMA_EVENT_INTR2

Really any GPIO_0 can be used for "wake-up" from "suspend"..

https://e2e.ti.com/support/processors/f/791/t/243392?How-to-wake-up-the-BeagleBone

https://processors.wiki.ti.com/index.php/AM335x_Power_Management_Standby_User%27s_Guide#GPIO_wakeup

It's not trivial..

[Steve Lentz]

That’s not quite what I am asking.  I want to set the alarm in the DS3231, shut down the BBB, completely, then have the Alarm / INT pin on the DS3231 initiate a series of events that eventually powers on the BBB.  Doing this, I can achieve a true zero power sleep state.  Nothing will draw power except the coin cell on the DS3231.  

I can set the alarm in the DS3231 using python libraries, is it possible to set that alarm using the device drivers?  I have a bunch of relay and delay circuits that area all working, this is the last link in the chain.  I will use the python if necessary but would prefer to use the kernel drivers.  

I need the BBB to power up for a couple hours every two weeks and last for a year on a stack of D cells; the normal sleep state draws too much power, I want to shut it off.  

The reddit page I linked describes the exact same problem and solution for RaspPi.  Is there a similar solution for BBB?

Thx,

Steve

https://www.reddit.com/r/raspberry_pi/comments/bn2ht5/ds3231_rtc_using_the_alarm_function/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjBba%2Byja4ZMqXU4u68YLvxFvveycJM5CM%2BQSmkZJmsxA%40mail.gmail.com.

[robert.sty...@gmail.com]

The PWR_BUT P9.9 pulled down to DGND by the DS3231 INT/SQW pin might be the same as pressing the POWER BUTTON

[robert.sty...@gmail.com]

The power chip TPS65217 needs PWR_BUT P9.9  pulled low (<0.4V) for more than 50ms, but less than 8sec.

It appears the DS3231 can hold its INT/SQW pin low for 1 second