Yes, I flashed SinoVoip's 15.10 image this way. I downloaded it on OS X and transferred it through the network using a gzip pipe to compress the data. It failed the first 3 times until I realized that's something going wrong. I had to lower the maximum cpu clockspeed to be able to realibly write to eMMC (!!!). Just opened another Github issue: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/5 (I assume they will close it without taking notice as usual).
At the moment I set
echo interactive >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1008000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
in /etc/rc.local. Will later have a look whether I can provoce eMMC corruption when clocking higher again.
The first part compresses the image on OS X and the 2nd uncompressed it on Linux.
First impressions: This bug is still unresolved even with SinoVoip's own image: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/3 (already closed since 'hey, why fixing a bug if you can simply ignore the bug report?!'). Compare with
root@bananapi:/usr/lib# cat /proc/loadavg
1.00 1.45 1.69 1/350 27033
And I had already many throttling situations -- you can try
dmesg | grep -i Budget
in a terminal to get a clue. With my image this stopped after applying a heatsink and some finetuning. More to come...