Tag Archives: aarch64

From a diary of AArch porter – POSIX.1 functionality

During years of development GCC got several switches which are considered obsolete/deprecated now. And as such they are not available for new ports. Guess what? AArch64 has such status too.

One of switches is “-posix” one. It is not needed anymore as “_POSIX_SOURCE” macro deprecated it:


If you define this macro, then the functionality from the POSIX.1 standard (IEEE Standard 1003.1) is available, as well as all of the ISO C facilities.

But it happens sometimes (I saw it in pdfedit 0.4.5 which is so old that it still uses Qt3). So if you find it somewhere then please save world with “s/-posix/-D_POSIX_SOURCE/g” :)

Use of Valgrind in Fedora packages

Week ago I fetched git repositories of all Fedora packages. This took a while as there are over 26 thousands of them. Now I am going through them and check/add AArch64 bits.

One of changes is Valgrind support. As there is only one architecture in Fedora which does not have Valgrind support I plan to submit pile of patches which will enable it for all except s390 (32-bit s/390 – we hope it will die sooner than later).

Usual piece of spec file looks like this:

  %ifarch %{ix86} x86_64
  BuildRequires: valgrind

My change will look like this:

  %ifnarch s390
  BuildRequires: valgrind

Sure, some maintainers do not like to look at their packages on architectures other than x86(-64) because they do not own hardware, do not like being hit by bugs in valgrind or have other excuses. In such situations I will be fine with note in spec file about it – like “cscppc” package maintainer did.

I am aware that some packages may fail due to bug in valgrind implementation on some secondary architecture. But then we can let know developers so it will get improved (while in same time package may get this build dependency disabled for a while).

96boards goes enterprise?

96boards is an idea from Linaro to produce some 32 and 64-bit ARM boards. So far there were two boards released in “consumer” format and few more announced of rumoured. The specification also lists “extended” version which has space for some more components.

But during Red Hat Summit there was announcement from AMD with mention of “enterprise” format:

How would you like an affordable and compact 160x120mm board to jump start your development efforts with AArch64? AMD and Linaro have been collaborating to develop a 96Boards Enterprise Edition (EE) specification that is ideal for the individual developer. Targeting the server and networking markets, the board will feature a 4-core AMD Opteron A1100 Series processor with two SO-DIMM memory slots, PCIe®, USB, SATA, and Gigabit Ethernet capabilities. Popular operating systems such as CentOS, Fedora, and Red Hat Enterprise Linux Server for ARM Development Preview are targeted for use with this particular board. Additional software downloads, updates, and a forum for software developers will be available via the 96Boards web site. The board is slated to be available in 2H 2015 from distribution partners worldwide and it will be supported through the Linaro Enterprise Group’s 96Boards.org site.

I do wonder where from they took idea to name yet-another-crazy-non-standard board format “Enterprise Edition”. In my understanding what enterprise user like is something which just works and comes with support and does not require crazy embedded nonsense hacks.

So when I saw post from Jeff Underhill with photos of the board I noticed few arghs.

Top view of AMD "Enterprise" board

Bottom view of AMD "Enterprise" board

First of course is board format. 160x120mm does not sound like any industrial format. Nano-ITX is 120×120, Mini-ITX is 170x170mm. But everyone knows that enterprise people love to be creative and make own cases. Why it was not done as 170×120 with partial compatibility with mini-itx cases?

Second thing (related to first) is connectors placing. With PCI-Express x16 slot (with x8 signals) I wonder how it will look when some cables go one side or the other while card sticks out of board. With SATA ports moved to the other side there would be space for USB and Ethernet ports so all cables would be in same area. Note also molex connector to give power to SATA disks.

Nice that there are two memory slots (DDR3 ECC SO-DIMM). But with second on the bottom we probably can say goodbye to all PC cases as it would not fit. Yay for creativity when it comes to cases (again).

There are holes to mount heatsink above CPU. From quick look I think that those for FM2 socket may fit.

HDMI connector suggests some graphics to be present. I did not heard about Radeon core inside AMD Seattle CPU but it could change since last check.

But even with those “issues” I would like to have that board ;)

And now something more enterprise — CentOS on AArch64

Everyone can grab and install Fedora 21-22 on APM Mustang. But what if you want something more enterprise ready? Answer is simple: you can install CentOS 7 (at Alpha stage now).

Requirements are simple:

First fetch iso and then copy to USB thumb drive (simple “dd if=boot.iso of=/dev/sdc bs=4M” is enough). Then just reboot to UEFI shell and run “FS1:\EFI\BOOT\BOOTAA64.EFI” to get into installation.

All files will be read from USB (for Mustang you need official APM firmware 1.1.0 to get proper DTB) and installation goes like with Fedora, RHEL, CentOS — standard Anaconda.

Finally reboot and system is ready for use:

CentOS Linux 7 (Core)
Kernel 4.0.0-1.el7.aarch64 on an aarch64

pinkiepie login: 

AArch64 port is now in progress so not all packages are built yet but they will be.

Running VMs on Fedora/AArch64

There are moments when more than one machine would be handy. But AArch64 computers are not yet available in shop around a corner we have to go for other options. So this time let check how to get virtual machines working.


For this I would use Fedora 22 on APM Mustang (other systems will be fine too). What else will be needed:

  • libvirtd running
  • virt-manager 1.1.0-7 (or higher) installed on AArch64 machine
  • UEFI for AArch64 from Gerd’s Hoffmann firmware repository
  • Fedora or Debian installation iso (Ubuntu does not provide such)
  • computer with X11 working (to control virt-manager)

Is KVM working?

First we need to get KVM working — run “dmesg|grep -i kvm” after system boot. It should look like this:

hrw@pinkiepie-f22:~$ dmesg|grep -i kvm
[    0.261904] kvm [1]: interrupt-controller@780c0000 IRQ5
[    0.262011] kvm [1]: timer IRQ3
[    0.262026] kvm [1]: Hyp mode initialized successfully

But you can also get this:

[    0.343796] kvm [1]: GICV size 0x2000 not a multiple of page size 0x10000
[    0.343802] kvm [1]: error: no compatible GIC info found
[    0.343909] kvm [1]: error initializing Hyp mode: -6

In such case fixed DeviceTree blob from bug #1165290 would be needed. Fetch attached DTB, store as “/boot/mustang.dtb” and then edit “/etc/grub2-efi.cfg” file so kernel entry will look like this:

menuentry 'Fedora (4.0.0-0.rc5.git4.1.fc22.aarch64) 22 (Twenty Two)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.0.0-0.rc5.git2.4.1.fc22.aarch64-advanced-13e42c65-e2eb-4986-abf9-262e287842e4' {
        insmod gzio
        insmod part_gpt
        insmod ext2
        set root='hd1,gpt32'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt32 --hint-efi=hd1,gpt32 --hint-baremetal=ahci1,gpt32  13e42c65-e2eb-4986-abf9-262e287842e4
          search --no-floppy --fs-uuid --set=root 13e42c65-e2eb-4986-abf9-262e287842e4
        linux /boot/vmlinuz-4.0.0-0.rc5.git4.1.fc22.aarch64 root=UUID=13e42c65-e2eb-4986-abf9-262e287842e4 ro  LANG=en_GB.UTF-8
        initrd /boot/initramfs-4.0.0-0.rc5.git4.1.fc22.aarch64.img
        devicetree /boot/mustang.dtb

After reboot KVM should work.

Software installation

Next step is installing VM software: “dnf install libvirt-daemon* virt-manager” will handle that. But to run Virt Manager we also need a way to see it. X11 forwarding over ssh to the rescue ;D After ssh connection I usually cheat with “sudo ln -sf ~hrw/.Xauthority /root/.Xauthority” to be able to run UI apps as root user.

UEFI firmware

Next phase is UEFI which allows us to boot virtual machine with ISO installation images (compared to kernel/initrd combo when there is no firmware/bootloader possibility). We will install one from repository provided by Gerd Hoffmann:

hrw@pinkiepie-f22:~$ sudo -s
root@pinkiepie-f22:hrw$ cd /etc/yum.repos.d/
root@pinkiepie-f22:yum.repos.d$ wget https://www.kraxel.org/repos/firmware.repo
root@pinkiepie-f22:yum.repos.d$ dnf install edk2.git-aarch64

Then libvirtd config change to give path for just installed firmware. Edit “/etc/libvirt/qemu.conf” file and at the end of file add this:

nvram = [

Restart libvirtd via “systemctl restart libvirtd“.

Running Virtual Machine Manager

Now we can connect via “ssh -X” and run “sudo virt-manager“:


Next step is connection to libvirtd:


Now we are ready for creating VMs. After pressing “Create a new VM” button we should see this:


And then creation of VM goes nearly like on x86 machines as there is no graphics only serial console.

But if you forgot to setup UEFI firmware then you will get this:


In such case get back to UEFI firmware step.

Installing Fedora 22 in VM

So let’s test how it works. Fedora 22 is in Beta phase now so why not test it?




2GB ram and 3 cpu cores should be more than enough ;D


And 10GB for minimal system:



But when it went to serial console it did not look good :(


I realized that I forgot to install fonts, but quick “dnf install dejavu*fonts” sorted that out:


Go for VNC controller installation.

After installation finish system runs just fine:



As you can see Fedora 22 has everything in place to get VM running on AArch64. UEFI firmware is the only thing out of distribution but that’s due to some license stuff on vfat implementation or something like that. I was running virtual machines with Debian ‘jessie’ and Fedora 22. Wanted to check Ubuntu but all I found was kernel/initrd combo (which is one of ways to boot in virt-manager) but it did not booted in VM.

96 boards again?

During Linaro Connect 2015 Asia there was announcement about new Linaro project called “96boards”. It is about making cheap ARM/AArch64 boards in same form factor and same placement of ports. And first board named HiKey was presented. Today third one — from Qualcomm. So we have two boards now (2/96 was not yet announced).

I prefer not to comment on form factor, lack of Ethernet, mobile phone cpus and other things people do not like but about software requirements.

96boards specification v1.0 says:

Minimum Software requirements for 96Boards certification will include:

  • Boot architecture (open source implementations are strongly recommended)
    • Support for bootloader such as U-Boot/FDT, UEFI/ACPI, UEFI/FDT
    • Support for a secure execution environment (optional)
    • Support for ARM Trusted Firmware (ARMv8), including PSCI APIs (optional)
  • Accelerated graphics support
    • Accelerated graphics drivers need to be fully supported either with open source code, or through royalty free binary drivers. If binary drivers are utilized, the vendor will provide support to provide updated drivers/libraries to support new mainline Linux kernel features.
  • Kernel
    • A kernel based on one of the following that is buildable from source code and any required binary blobs:
    • kernel.org latest “mainline” or “stable” kernel
    • The latest Google-supported Android kernel version
    • One of the last two kernel.org LTS kernels (for example Linaro LSK)
  • Operating system
    • The latest released (stable) version of one or more of the following open source distributions shall be made available for a 96Boards CE compliant design:
    • Android
    • Debian or Ubuntu
    • Fedora or Red Hat
    • An OpenEmbedded/Yocto build of a Linux distribution

I hoped that Linaro will be a place where free/open source software would matter. But it looks like “let release whatever you want as long as size and ports match” deal. Any blob as bootloader, binary graphics drivers (does someone remember TI OMAP line and PowerVR? Those boards run with raw framebuffer nowadays).

And that kernel requirement… HiKey uses cpu which is not in mainline kernel, so does Qualcomm one. Are they in AOSP kernel? Maybe. But does someone else than Android uses those trees for serious work? Latest I see in kernel-msm (which may not be proper place to check) is 3.10 which was released (in mainline) nearly 2 years ago…

I really wonder how “latest released (stable) version” of Debian/Fedora/Ubuntu can be made available for those boards when all those distributions use mainline kernel only (I do not count user generated remixes which are not supported by anyone).

So I wonder will 96/96 board came with mainline support, open bootloader and open drivers for everything. Time will show. Until that I am not so interested.


So today Linaro announced their first board from 96boards project. It is named HiKey and is based on HiSilicon cpu for mobile phones.

I had an occasion to see that board during FOSDEM and decided to write something about it after it land on my desk (which will happen sooner or later). But I have read specification for this and next boards and decided to write few words from my perspective.

First thing? Footprint. Good that two sizes are available for designs as not everyone may want to squeeze into small one.

Second? Ports. 2015 year and no Ethernet, no SATA? Sure, first board is based on SoC from a mobile phone but there is no place on small board for them and extended version looks like not allow for extra ports too.

Next? Power supply. 8-18V in a world where everything is on 5V already. The only place where 12V is mentioned in spec is “external fan power”.

So as we are on voltage… Serial at pins and 1.8V level. Nice way of forcing everyone to buy new serial dongle (Arduino ones are 3.3 or 5V).

But assume that we got it powered and have serial connected. How to boot it? According to specs mainline kernel (or AOSP one or LTE one) has to be used. I wonder how HiSilicon cpu is supported in any of those. From what I read during day (on quite slow connection) it is still not in a kernel…

Graphics situation is still shitty. Vendor is allowed to provide binary blobs to get display working. Did they not learnt from OMAP? PowerVR again someone? But sure, plain framebuffer is all you need. OpenGL is for weak.

I prefer not to discuss about selection of signals on low/high connectors. There are more capable people for it. I only wonder why 2mm raster where nearly all boards I had played with had 2.500 one.

I like list of distributions listed as ones to choose. No longer Android/Ubuntu but also Debian, Fedora or OpenEmbedded based one

But give them time. It is just first board and next ones are announced. Marvell will produce one (they are in a Linaro group for it), other will (probably) follow. Hope that there will be something better.