A64-OLinuXino got mainline Linux Kernel 5.0 images


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.

10 Comments (+add yours?)

  1. Diego
    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).


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


    • OLIMEX Ltd
      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.


  3. Mossroy
    Mar 29, 2019 @ 23:55:53


    Can we have some news about the next release you were mentioning?


  4. Mossroy
    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?


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


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


    • Lub Olimex
      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.


  7. Trackback: Préparation Olinuxino A64 en serveur headless | Mossroy
  8. Mossroy
    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/


Leave a Reply to Mossroy Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: