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-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.

Regards,
NK









On Tue, Sep 1, 2020 at 6:05 PM Tarmo Kuuse <[email protected]> wrote:

> 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
>
> --
> 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
> [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/338861fc-3973-12a5-e0e9-6fc979c9dfc3%40gmail.com
> .
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF7-PaQ0xJs0rueHHRvdkM6H6BOKFmKvxfFA4XnChb88gxrv2w%40mail.gmail.com.

Reply via email to