This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x system time drift in Beaglebone Black

Hi, 

I am using:

  • Beaglebone Black and White
  • Ezlinux sdk: root@user-virtual-machine:/home/user/ti-sdk-am335x-evm-07.00.00.00/board-support/linux-3.12.10-ti2013.12.01#

I have noticed that 01 minute after adjusting the system time in Beaglebone Black, it is 15 seconds advanced from the real time. This is a huge drift. Here is an example:

  Setting the time:

root@Teste-01:~# ./sntp -f -h pool.ntp.org;

connecting to pool.ntp.org [200.192.232.8]
 current time: Thu Jul 21 19:33:53 2016
 server  time: Thu Jul 21 19:33:53 2016
 local clock offset is 0 seconds
 correct time: Thu Jul 21 19:33:53 2016

Checking the time one minute later (a little more):

root@Teste-01:~# ./sntp pool.ntp.org connecting to pool.ntp.org [200.89.75.198] current time: Thu Jul 21 19:35:16 2016 server time: Thu Jul 21 19:35:00 2016 local clock offset is -16 seconds correct time: Thu Jul 21 19:35:00 2016

The same is not noticed when I use a Beaglebone White running the same system.

Of course the system time is ticking faster than he think it is!

What is wrong? What is the clock source of the system time? How can I access it and fix this issue?

Thanks in advance!!

  • Hi,

    I will forward this to the software team. Can you post how you set the system time?
  • Thanks, Biser!

    The system time is set by an sntp application accessing pool.ntp.org for the right time and writing the right time to the system time.

    I would like to emphasize that the hardware clocks are all ok, but the system time (assessed by the date command) advances 15 seconds for every 60 seconds.

    Maybe it is a coincidence, but (60+15)/60=1Ghz/800Mhz. If the system time is ticking based on 1GHz but it "thinks" it is ticking based on a 800Mhz clock, it would be an explanation for this issue. Does it make sense? How could I fix this?

    Best regards!

    P.S.:

    Just updating, I have run dmesg | grep -i timer and found:

    [ 0.000000] OMAP clockevent source: timer2 at 19200000 Hz
    [ 0.000000] OMAP clocksource: timer1 at 19200000 Hz
    [ 0.200708] Switched to clocksource timer1
    [ 1.339698] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
    [ 1.542426] oprofile: using timer interrupt.

    I suspect that the real clocksource is 24000000Hz, so 24Mhz/19.2Mhz=75s/60s.

  • Hi,

    I realized that this issue is the same addressed at the following thread:

    e2e.ti.com/.../431364

    The cause and solution is there!

    It is a hardware issue.

    I have a device connected to some pins (sorry, didn´t mention it! Thought it had zero relation to the issue!) that interfere with SYSBOOT[15:14] during boot. So the system thinks that a 19.2Mhz clock is used, but the real one is 24Mhz.

    The solution is to force the 24Mhz clock in devicetree as explained in the link pointed by the thread!

    Best regards!
  • Hi, 

    I believe I have the same problem can you supply me with the device tree that fixes this problem? The link in the other post doesn't work.

    Thanks

  • Hi,

    I have added the highlighted line to solve the problem:

    /*
    * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
    *
    * This program is free software; you can redistribute it and/or modify
    * it under the terms of the GNU General Public License version 2 as
    * published by the Free Software Foundation.
    */
    /dts-v1/;

    #include "am33xx.dtsi"
    #include "am335x-bone-common.dtsi"

    /* Ensures 24MHz clock in the system
    */
    &sys_clkin_ck {clocks = <&virt_24000000_ck>, <&virt_24000000_ck>, <&virt_24000000_ck>, <&virt_24000000_ck>;
    };

    &ldo3_reg {
    regulator-min-microvolt = <1800000>;
    regulator-max-microvolt = <1800000>;
    regulator-always-on;
    };

    ...

    Regards,

    Levy