Linux kernel 5.0 was just released and as we were working this week to the release of mainline Linux image for A64-OLinuXino (as till now it has the ugly android based 3.10 kernel) we decided to release latest kernel.
The images are available on our FTP.
There are two images Debian headless or Ubuntu desktop.
Known issues with these images:
- LCDs are not supported yet, HDMI output is only available, we need one more week to figure out how to automatically detect if the Ethernet or LCD are enabled (there is jumper on the board which switch between LCD or Ethernet as both share pins and can’t work together). So to make the DTS configurations automatic at boot time.
- eMMC do not work in the fastest possible mode yet. 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.
- No CPU thermal. A64 has 3 thermal zones – CPU, GPU0 and GPU1. The driver doesn’t support monitoring them.
How to build the images is explained here.
Mainline Linux Kernel 5.0 images for A13, A20 and A33 OLinuXino and SOMs is in progress.
olimex 
Mar 09, 2019 @ 19:53:15
Congrats those are great news, finally Allwinner SOCs are usable without the usual BSP crap. I still remember how painful that was roughly 12 years ago with our ARM7tdmi BSP (some Module Made in Germany at the time).
Mar 10, 2019 @ 18:52:25
It’s very promising, thanks!
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 : https://www.olimex.com/wiki/images/4/43/A64olinuxino_ubuntu_16.04.3_20180523_rel5.torrent)
It’s like the CPU was almost 3 times slower.
I’ll try to be more precise if necessary.
I did not seem to have this regression with Armbian_5.75_Lime-a64_Debian_stretch_next_4.19.20.7z image from https://www.armbian.com/olimex-lime-a64/ (even if this image had stability issues when I tested it)
Could 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 also noticed that hardware encryption/decryption was not enabled in this image (based on “cat /proc/crypto”). Would it be possible to add the patches from https://groups.google.com/forum/#!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. http://sunxi.montjoie.ovh/ says they’re working fine.
Mar 11, 2019 @ 08:33:55
Thanks for the feedback! We will look for the cpufreq and the patch will be included in the next build which add support for the LCDs which we intend to release this week.
Mar 29, 2019 @ 23:55:53
Hi,
Can we have some news about the next release you were mentioning?
Apr 14, 2019 @ 15:17:09
Well, we’re 5 weeks after your intention to release a new image “this week”.
I suppose it’s harder than expected?
Could you keep us informed?
Is there a workaround we might apply on the existing image, for the CPU performance issue?
Apr 19, 2019 @ 20:15:42
I noticed that there were new images in ftp://staging.olimex.com/Allwinner_Images/a64-olinuxino/linux/1.latest_images/images/ : Armbian_5.79.1_Olinuxino-a64_Debian_stretch_next_5.0.8.7z and Armbian_5.79.1_Olinuxino-a64_Ubuntu_bionic_next_5.0.8_desktop.7z
I quickly tested the debian version, and the performance is back to normal : thanks a lot!
Unfortunately, the hardware encryption/decryption does not seem to be enabled. But the board is at least running at normal speed, and seems stable.
May 19, 2019 @ 19:53:23
After some further testing of this image, I have a few more remarks :
There is a broken package dependency in the image. It can easily be fixed with “sudo apt install busybox”.
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. I tried to add something like “ethaddr=XX:XX:XX:XX:XX:XX” in /boot/armbianEnv.txt but it does not work. If I access u-boot at startup (with the debug USB cable) and try to set it manually, it fails too. Maybe u-boot has not been compiled with CONFIG_OVERWRITE_ETHADDR_ONCE to allow it? (see https://github.com/linux-sunxi/u-boot-sunxi). If so, could this option be set in the next version of the image?
It’s still possible to change the MAC address manually in /etc/network/interfaces, but setting it in u-boot would be more generic IMHO.
Last issue : if I install armbian on the NAND (through armbian-config), it works well BUT the board fails to start if I insert an empty SD-card in it : it seems to try to boot on the SD-card, fails (which is normal), but does not fall back to the NAND. It’s very sad because I’d like to boot on NAND (because it’s fast and reliable), and put all the data (and logs) on the SD-card (because there’s more space and can be easily replaced if necessary). How could I do that?
My current workaround is to put your image on the SD card, modify /boot/armbianEnv.txt on it to set “rootdev=/dev/mmcblk1p1”, and create another partition on the SD-card to put the data, which is not ideal
May 20, 2019 @ 11:16:45
Thank you for the continued feedback. Much appreciated. You feedback was forwarded to our developers. New image was released last Friday (18/05/2019), and I checked about your points in it. Can’t find the broken package that you mentioned.Not sure about the MAC addresses that is under investigation, it seems like indeed only one MAC address is given to all boards. About the NAND – A64 boards never had NAND but eMMC; the installation to the eMMC works as expected but as you noticed the board would not boot with boot card inserted – this is expected since the card boot has precedence over eMMC boot, and if you want to use the card as storage medium you need to delete the boot partition stored on the card – remove the card, let the board boot, then insert the card and type “dd if=/dev/zero of=/dev/mmcblk0 bs=512 seek=16 count=1” then test again. Typical format doesn’t clear the board from the boot code (since it is stored before the file system). It is kind of hard to keep the communication over wordpress. Please can you send your future feedback over our support e-mail support@olimex.com This way you can include logs and images and more details.
Jun 02, 2019 @ 11:38:41
For anyone interested, I published a blog post about a few tests I made with this image and some other ones.
It’s in French : https://blog.mossroy.fr/2019/05/31/preparation-olinuxino-a64-en-serveur-headless/
Jun 29, 2019 @ 19:12:24
You said “it is kind of hard to keep the communication over wordpress. Please can you send your future feedback over our support e-mail “, but I got no reply for the emails I sent in May.
So I’d say it seems harder to have some communication by e-mail, and it also prevents other people to read and join the conversation.
But maybe https://www.olimex.com/forum/index.php?board=36.0 would be a better place?
Anyway, here is a few more feedback :
– The dd command you provided works perfectly well to remove a boot partition. Thanks! I now can boot on eMMC (sorry for the confusion with NAND), while having a SD-card inserted and used
– The latest image Armbian_5.87.1_Olinuxino-a64_Debian_stretch_next_5.1.4.7z now gives a random MAC address, and it can be overridden in /boot/armbianEnv.txt. That’s good news, thanks! But if you don’t know how to do that, the MAC address changes on each boot, which can be very confusing. It would probably be better if the random MAC address would be automatically kept for subsequent reboots
– Do you plan to maintain this 5.x kernel in the long-term? i.e. release new versions of the kernel when there are security breaches, that will be automatically upgraded through apt upgrade?
– There is no hardware encryption/decryption in this image, where there is in the image from https://www.armbian.com/olimex-lime-a64/. Any reason for that?
Regarding these 2 sources of armbian images, could you please tell us what is your mid/long-term plan? Will both of them still exist, or will they merge at some point? If not, could you give us your advice on which one to choose? (I found a few technical differences but there are probably more)
Jul 03, 2019 @ 07:56:11
support@olimex.com is where you can get faster reply, but if you have your concerns to not use it we reply here:
Maybe the forum is better place for communication, yes.
/> Do you plan to maintain this 5.x kernel in the long-term? i.e. release new versions of the kernel when there are security breaches, that will be automatically upgraded through apt upgrade?/
That is the plan.
/> There is no hardware encryption/decryption in this image, where there is in the image from https://www.armbian.com/olimex-lime-a64/. Any reason for that?/
Can’t say about that, I’m not even sure what does ” hardware encryption / decryption” mean. If you clarify I can give you more info.
/> Regarding these 2 sources of armbian images, could you please tell us what is your mid/long-term plan? /
Unfortunately, we would probably stray away further from Armbian, although our distribution is based on it we are moving forward faster. At this moment it is not possible to implement all capabilities of our hardware using the unmodified Armbian images as they support hundreds of other boards which compatibility we will break if we apply our patches. Some of the changes required would not be approved by Armbian for these reasons.
/
//> Will both of them still exist, or will they merge at some point? /
We hope we can merge but at the current moment I don’t see we can do it safely.
More probably is to try to submit our patches upstream so they get naturally in Armbian.
> If not, could you give us your advice on which one to choose? (I found a few technical differences but there are probably more)
Depends on what features exactly do you need. For experienced users and server purposes probably doesn’t matter. For less experienced users and desktop-like purposes, I’d recommend sticking with the Olimex releases. Notice that this is our first Armbian release for the A64 board and that is why it is preliminary, but we have released a number of releases for the Teres-I laptop (which has A64 chip in its design), so we are quite familiar with the Armbian for A64.
Best regards,
Lub/OLIMEX
Jul 03, 2019 @ 09:21:49
support@olimex.com is where I sent my emails and got no reply. But never mind.
Thanks a lot for these precise answers.
What I mean by “hardware encryption/decryption” is enabling the crypto features of the A64 processor, so that AES streams (for example) can be encrypted/decrypted by the hardware instead of software. It should add some lines in /proc/crypto and significantly speed up commands like “cryptsetup benchmark”.
See the “Crypto line” in https://linux-sunxi.org/Mainlining_Effort. As you can see, it has not been merged upstream yet, but there are some patches for that :
https://groups.google.com/forum/#!topic/linux-sunxi/JLpU9PqHzvc
I suppose it’s what has been used in mainline armbian.