Jump to content

martinayotte

Members
  • Posts

    3892
  • Joined

  • Last visited

Posts posted by martinayotte

  1. 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 ?)

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

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

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

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

  6. 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";
            };
        };
    };
    
  7. Unfortunately, all those boards are not providing easy access to SPI1, they are provding SPI0 instead.

    Even if PA15 is used for LED_STATUS, it is could probably still be used as SPI1_MOSI, since MOSI is "Master-Out-Slave-In".

    Of course, this LED maybe will affect speed efficiency, but you can give it a try.

    Also, you need to make sure that UART3 is disabled, and finally MUTE is the more difficult to access, since it it the PA16 SPI1_MISO, and should not be used as MUTE output anymore.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines