• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    barish reacted to guidol in Failing to Rescue EspressoBin   
    link doenst work, so please try this git command:
    git clone -b A3700_utils-armada-17.10  
  2. Like
    barish got a reaction from Bernie_O in A20 SATA write speed improvement   
    To sum up my not too excessive tests of the new kernel on the Lime2 - I did not encounter any read/write errors up to now. Right from the start I switched to nightly builds and still had a reasonably stable system. What I found dissapointing were the speeds over network (SMB): I did never exceed 44MB/s in any condition (reading, writing, HDD, SSD, SD card, SATA, USB, always GBit-Ethernet).
    If there's any procedure of testing read/write over SATA excessively - please let me know. Does a benchmark apply?
    OT: So this board might be a good update to my first generation Raspberry Pi (which makes 6MB/s ;-) ) but compared to the EspressoBin V5, which I obtained a couple of days ago and which is stable (other than the V7 I had to send back), it is about half as fast. And I am running the EspressoBin at a conservative 800MHz.
  3. Like
    barish got a reaction from Bernie_O in A20 SATA write speed improvement   
    Thanks @Tido for this link, I hadn't seen it and it gives quite a good explanation to why it took so long and why it's so difficult to have a decent SATA speed on Allwinner boards. :-)  So I think testing should include all different kinds of transfer block sizes, verifying the write result on the fly, just to be sure that one trial-and-error-finding is as good as the previous trial-and-error-finding, which has already been tested since 2014.
  4. Like
    barish reacted to martinayotte in I2C busses changed with update?   
    If you do a "i2cdetect -l", you will probably see that i2c-0 is dedicated to "sun4i_hdmi_i2c adapter", which maybe wasn't present before ...
  5. Like
    barish reacted to Igor in I2C busses changed with update?   
    Most likely settings were changed upstream since I don't recall seeing anyone around Armbian fiddling around this.
  6. Like
    barish reacted to lagerschaden in [RfC] Make Armbian more IoT friendly?   
    It would be GREAT if rootless access to gpio was integrated in armbian (just like in raspbian).
    I made a little test on my Orangepi-One:
    created a group gpio and added the user to the group gpio, then created the file /etc/udev/rules/99-gpio.rules, this makes the access rootless
    # /etc/udev/rules/99-gpio.rules SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\ chown -R root:gpio /sys/devices/platform/sunxi-pinctrl/gpio && chmod -R 770 /sys/devices/platform/sunxi-pinctrl/gpio;\ '" Edit (02/09/2018): for later versions of armbian the file must change (tested with 4.14.18 and 4.14.65):
    # /etc/udev/rules.d/97-gpio.rules SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 0770 /sys/class/gpio &&\ chown -R root:gpio /sys/devices/platform/soc && chmod -R 0770 /sys/devices/platform/soc'"  
    Now you can use the access on the bash for the PIN PA12 (calculation see
    echo 12 > /sys/class/gpio/export # enable access to PA12 sleep 0.1 # wait some time to become gpio12 active echo out > /sys/class/gpio/gpio12/direction # PA12 is output echo 0 > /sys/class/gpio/gpio12/value # PA12 is low echo 1 > /sys/class/gpio/gpio12/value # PA12 is high echo 12 > /sys/class/gpio/unexport # disable access to PA12 My skills in programming are not good enough  to transform this to C, C+, Python etc, but you don't need any root privileges.
  7. Like
    barish reacted to tkaiser in safe GPIO access (no root)   
    Did you read through this already? 
  8. Like
    barish got a reaction from Igor in What happens when booting with SATA drive connected?   
    Sorry for not testing for so much time, it was quite a bad situation with the Olinuxino at work all the time.
    But I have good news: I just downloaded the latest Jessie-image, and the problem seems to be solved, I can boot with attached SATA drive without any issues.
    Thanks a lot for the ongoing development!
  9. Like
    barish reacted to zador.blood.stained in GPIO in Olinuxino Micro A20   
    Look at GPIO numbering scheme in mainline kernel here:
    It is tied to SoC pin bank (port) numbers, so GPIO 1 would be pin PA01, and this pin (for A10/A20 CPUs) is probably used by network driver, so no wonder kernel crashed here.
    You will need to calculate GPIO numbers for pins manually by their names (i.e. PG0 -> GPIO 192 if I'm not mistaken).