barish

Not sure if this is related, but the Netgate team is seeing an unusually high instability failure percentage on the SG1100, which is a branded Espressobin.  They say this is related to the power system on the board I think, and caused by a supplier component problem. I imagine it is possible the same supply chain issue has impacted the Espressobin. 
 
https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots

Even with the latest build, I'm still experiencing random hard-resets (that is, no panic, just a complete reboot to TIM/WTMI). I'm now pretty sure that Netgate are correct (https://forum.netgate.com/topic/144636/sg-1100-intermittent-reboots) and there are component issues on some espressobin v7 boards. 
 
I'm asking GlobalScape if they know the root cause, that is the component that is not functioning correctly, wonder if I will receive of a response, Netgate don't seem to want to say.

link doenst work, so please try this git command:
 
git clone -b A3700_utils-armada-17.10 https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git  

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.

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.

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

Most likely settings were changed upstream since I don't recall seeing anyone around Armbian fiddling around this.

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 https://linux-sunxi.org/GPIO)
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.

Did you read through this already? 
 

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!

Look at GPIO numbering scheme in mainline kernel here: https://linux-sunxi.org/GPIO
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).