
If so, could this option be set in the next version of the image? Maybe u-boot has not been compiled with CONFIG_OVERWRITE_ETHADDR_ONCE to allow it? (see ).

If I access u-boot at startup (with the debug USB cable) and try to set it manually, it fails too. I tried to add something like “ethaddr=XX:XX:XX:XX:XX:XX” in /boot/armbianEnv.txt but it does not work. I have bought several of these boards but they all have the same MAC address 02:BA:7B:D5:C6:6F, which creates a conflict on the network. It can easily be fixed with “sudo apt install busybox”. There is a broken package dependency in the image. says they’re working fine.Īfter some further testing of this image, I have a few more remarks : Would it be possible to add the patches from !topic/linux-sunxi/JLpU9PqHzvc in your next version? These patches are in the process of being merged in mainline kernel, even if it’s not done yet. I also noticed that hardware encryption/decryption was not enabled in this image (based on “cat /proc/crypto”). I did not seem to have this regression with Armbian_5.75_Lime-a64_Debian_stretch_next_4.19.20.7z image from (even if this image had stability issues when I tested it)Ĭould it “simply” be the CPU frequency? I noticed that cpufreq-info does not manage to read the current CPU frequency on this image, and /sys/devices/system/cpu/cpu*/cpufreq/ does not exist. I’ll try to be more precise if necessary. It’s like the CPU was almost 3 times slower.

I tested the Debian headless version : it looks stable but I noticed a serious regression on CPU performance, compared to the official ubuntu image (with the 3.10.104 kernel : )

Mainline Linux Kernel 5.0 images for A13, A20 and A33 OLinuXino and SOMs is in progress. How to build the images is explained here. The driver doesn’t support monitoring them.

We need some time, right now 50MB/s is the max speed to read write instead of 100-200MB/s which the installed eMMC supports, we will update the image soon with HS200/400 modes enabled.
