Jump to content

martinayotte

Members
 View Profile  See their activity

  • Posts

    3892

  • Joined

  • Last visited

 Content Type 

Posts posted by martinayotte

    A64 date/time clock issue

    in Advanced users - Development

    Posted

    Maybe I've didn't explain it well : ntpdate or ntp server are also facing the same -EINVAL seen with date when symptoms kick in, but not after reboot. Something happened, probably at the 24th hour (I will see later today) which make the symtoms resurrect somehow, probably after a systemd or cron task job. I will check dmesg/syslog next time ...

    But, still, why PineA64 is having that trouble and not OPiPC2, they are both using the same kernel branch ?

    0

    A64 date/time clock issue

    in Advanced users - Development

    Posted

    Let's first recap from the other thread :

     

    I found a strange bug and seen it twice in a week :

     

    After few days running, my PineA64 had wrong date, some thing like "Tue Mar 13 20:50:11 EDT 2153".

    Trying to restart NTP didn't fix it. Trying to set it manually give me an error :

    root@pine64:~# date -s "2017-02-03 00:00:01"
    date: cannot set date: Invalid argument

    Doing an "strace" with it reveal that it can not write system clock :

    settimeofday({1486098000, 0}, NULL) = -1 EINVAL (Invalid argument)
    openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3

    Doing search on the net, I've found http://nerdbynature.de/s9y/2009/07/22/cannot-set-date-Invalid-argumentand http://www.mail-archive.com/bug-coreutils@gnu.org/msg14103.html, but not real answers other than it is really the kernel that are f*k*ing up with the system clock. And the issue is gone if I simply reboot the board. Really strange ... Especially that it happened only on PineA64 ...

     

    As someone got the similar issue ?

     

    And here is Zador's first reply :

     

    Is there support for the hardware RTC in mainline (assuming you are testing the mainline)? If yes, then it may be related to wrong RTC settings like external or internal oscillator. If not - then maybe it's related to the arch timer bug? https://github.com/longsleep/linux-pine64/issues/44#issuecomment-263060276
     


    I think kernel just prevents unsafe date/time changes, there are several -EINVAL returns in the date/time changing code.

     

    And my first reply :

     

    I was just looking at DT about this, because if I remember, I didn't had the issue up until recently.

    I'm seeing that in the old longsleep DT, it was using 'sun50i-rtc' and in the current it is using 'sun6i-a31-rtc'.

    Since I kept also several A64 armbian previous images, I will look into them too.

    (I will also check what is the frequency of the occurence, because maybe it happen every 24hrs by reading wrong value from a sync service call. Let see tomorrow ...)

    (Another thing I found : the H3 has /dev/rtc and clear trace in dmesg, but not with H5 or A64, no trace at all. But why I don't have the same issue with H5 ?)

     

    Now, here is my latest investigations :

     

    Both H5 and A64 doesn't probe RTC driver successfully, explaining why dmesg doesn't mentioned it (I hate driver which are not verbose on failures !)

    But, why H5 doesn't react the same as A64 ?

    I will have to wait until issue re-appear to dig further in /var/log/syslog , maybe tomorrow !

     

    BTW, Zador, the -EINVAL seen on "date" command is only shown when symptom occurred, not after reboot... (let's wait tomorrow to see)

    As I said, I suspect "systemd" compatiblilty issue here.

     

    BTW, each time the issue occurred, the current SSH session has been kicked out, probably due to time elapsed been too large, 120 years ... :P

     

    0

    Armbian running on Pine64 (and other A64/H5 devices)

    in Pine A64

    Posted

    I was just looking at DT about this, because if I remember, I didn't had the issue up until recently.

    I'm seeing that in the old longsleep DT, it was using 'sun50i-rtc' and in the current it is using 'sun6i-a31-rtc'.

    Since I kept also several A64 armbian previous images, I will look into them too.

    (I will also check what is the frequency of the occurence, because maybe it happen every 24hrs by reading wrong value from a sync service call. Let see tomorrow ...)

    (Another thing I found : the H3 has /dev/rtc and clear trace in dmesg, but not with H5 or A64, no trace at all. But why I don't have the same issue with H5 ?)

    0

    Armbian running on Pine64 (and other A64/H5 devices)

    in Pine A64

    Posted

    I found a strange bug and seen it twice in a week :

     

    After few days running, my PineA64 had wrong date, some thing like "Tue Mar 13 20:50:11 EDT 2153".

    Trying to restart NTP didn't fix it. Trying to set it manually give me an error :

    root@pine64:~# date -s "2017-02-03 00:00:01"
date: cannot set date: Invalid argument

    Doing an "strace" with it reveal that it can not write system clock :

    settimeofday({1486098000, 0}, NULL)     = -1 EINVAL (Invalid argument)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3

    Doing search on the net, I've found http://nerdbynature.de/s9y/2009/07/22/cannot-set-date-Invalid-argumentand http://www.mail-archive.com/bug-coreutils@gnu.org/msg14103.html, but not real answers other than it is really the kernel that are f*k*ing up with the system clock. And the issue is gone if I simply reboot the board. Really strange ... Especially that it happened only on PineA64 ...

     

    As someone got the similar issue ?

    0

    Orange Pi Zero went to the market

    in Allwinner sunxi

    Posted

    I don't understand you !!!

    Who has "positive attitude" or "negative attitude" here, outside of YOU ...

    The hardware design choice of Xunlong about eMMC on OPi0 is NOT an Armbian design choice !!! Armbian has NO relationship with Xunlong except to get some sample board to help community !

     

    As I keep saying, even volunteers have responsibilities- or they are just people running amok

     

    (I'm usually a quiet gentle guy, but here, please @igor, I'm getting out, if he fight, please BAN if forever)

    What the FUCK ! As Volunteer, I'm should simply say to you :  GET OUT OF OUR FORUM !!! YOU'RE A SICK GUY !!!

     

    EDIT : as I said eailer, STOP complain and become YOURSELF a CONTRIBUTOR !

    3

    Orange Pi Zero wireless AP

    in Allwinner sunxi

    Posted

    OPiPC+ is powered using traditional Barrel 4mm x 1.7mm.

    Of course, OPiPC+ is twice as big footprint form-factor of OPi0, but 3 USB instead of 1, 2x or 4X DRAM, 8MB eMMC which once initialized with "nand-sata-install", you remove MicroSD forever, reducing BoM cost.

    0

    Armbian running on Pine64 (and other A64/H5 devices)

    in Pine A64

    Posted

    That is strange !

     

    With the build I did yesterday morning with sunxi64-next-20170125 branch, I was able to mount /dev/sda1 external drive and update its rootfs, and reboot with it as USB-Boot.

    What kind of USB drive are you using ?

     

    BTW be aware that some USB dongle such as "058f:6387 Alcor Micro Corp. Flash Drive" are failing in 64 bits SPL-USB-U-Boot, while some MicroSD reader such "14cd:121c Super Top microSD card reader" are working fine.

    0

    Orange Pi Zero, Python GPIO Library

    in Allwinner sunxi

    Posted

    The I2C buses are already present in the DT, but "disabled" by default.

    You can decompile DTB into DTS, after having done a backup of the DTB, edit it to enabling the buses by changing status "disabled" by "okay", and then recompile DTB for edited DTS.

     

    Or you could use DT Overlay, similar to the following :

    // Enable the i2c interface
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
	target-path = "/aliases";
	__overlay__ {
            /* Path to the i2c controller nodes */
            i2c0 = "/soc@01c00000/i2c@01c2b000";
            i2c1 = "/soc@01c00000/i2c@01c2b400";
        };
    };
    fragment@1 {
        target = <&i2c0>;
        __overlay__ {
            status = "okay";
        };
    };
    fragment@2 {
        target = <&i2c1>;
        __overlay__ {
            status = "okay";
        };
    };
};
    0
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept