Jump to content

martinayotte

Members
 View Profile  See their activity

  • Posts

    3892

  • Joined

  • Last visited

 Content Type 

Posts posted by martinayotte

    Orange Pi zero NOR Flash

    in Allwinner sunxi

    Posted

    You don't need to do all this since nightly builds already provides SPI-NOR support. The only thing you have to do is changing the partitions sizes in the current DT :

     

     

     

                    spi@01c68000 {
                            compatible = "allwinner,sun8i-h3-spi";
                            reg = <0x1c68000 0x1000>;    
                            interrupts = <0x0 0x41 0x4>;
                            clocks = <0x2 0x1e 0x2 0x52>;
                            clock-names = "ahb", "mod";  
                            dmas = <0x19 0x17 0x19 0x17>;
                            dma-names = "rx", "tx";   
                            pinctrl-names = "default";
                            pinctrl-0 = <0x1a>;
                            resets = <0x2 0xf>;
                            status = "okay";
                            #address-cells = <0x1>;
                            #size-cells = <0x0>;   
                            linux,phandle = <0x4c>;
                            phandle = <0x4c>;

                            spi-flash@0 {
                                    #address-cells = <0x1>;
                                    #size-cells = <0x0>;
                                    compatible = "jedec,spi-nor";
                                    reg = <0x0>;
                                    spi-max-frequency = <0x989680>;
                                    status = "okay";

                                    partitions {
                                            compatible = "fixed-partitions";
                                            #address-cells = <0x1>;
                                            #size-cells = <0x1>;

                                            partition@0 {
                                                    label = "uboot";
                                                    reg = <0x0 0x100000>;
                                            };

                                            partition@100000 {
                                                    label = "env";
                                                    reg = <0x100000 0x100000>;
                                            };

                                            partition@200000 {
                                                    label = "data";
                                                    reg = <0x200000 0x200000>;
                                            };
                                    };
                            };
                    };

     

     

     

    You will see the MTD partitions by doing "cat /proc/mtd", and you can use flashcp from mtd-utils to write to /dev/mtd0.

    1

    OrangePi PC GPIO UART and Arduino

    in Allwinner sunxi

    Posted

    For UARTs, you don't need those library, you only need to access kernel serial device, such /dev/ttyS1, using python-serial.

     

    For example, the following piece of code will print any character received on RX :

    import serial

serport = serial.Serial("/dev/ttyS1", 115200, timeout=1)
while True:
    while serport.inWaiting() > 0:
        c = serport.read()
        print c
    1

    CPU is stuck at 408MHz no matter what I try

    in Allwinner sunxi

    Posted

    There are many ways. Some more complex than others.

    The simplest on is running a startup script and call it in /etc/rc.local :

    #!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/root/my-startup-script.sh &

exit 0
    0

    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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept