Tag Archives: ubuntu

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.

Requirements

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' {
        load_video
        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
        else
          search --no-floppy --fs-uuid --set=root 13e42c65-e2eb-4986-abf9-262e287842e4
        fi
        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 = [
   "/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2.git/aarch64/vars-template-pflash.raw"
]

Restart libvirtd via “systemctl restart libvirtd“.

Running Virtual Machine Manager

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

vm1

Next step is connection to libvirtd:

vm2vm3

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

vm4

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:

vm5

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?

vm6

vm10

vm11

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

vm12

And 10GB for minimal system:

vm13

vm14

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

vm15

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

vm16

Go for VNC controller installation.

After installation finish system runs just fine:

vm17

Summary

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.

Git commands which you should really know

Git is now ten years old. More and more developers get lost when have to deal with CVS or Subversion as first SCM they learnt was git. But in daily work I see many people limited to very basic use of it ;(

There is a lot of commands and external plugins for git. I do not want to mention them but rather concentrate on ones installed as part of git package. And only those which I think EVERY developer using git should know that they exist and how to use them.

Dealing with other repo is easy set: “pull” to merge changes (“fetch” if you only want to have them locally), “push” to send them out. “git remote” is useful too.

Branching is easy and there is a lot of articles how to do it. Basically “git branch” to see which one you use, “git branch -a” to check which are available and “git checkout” to grab code from one.

Checking changes is next step. “git diff” with all variants like checking local not committed changes against local repo, comparing to other branches, checking differences between branches etc. “git log -p” to check what was changed in earlier commits.

Then goes “status” to see which local files are changed/added/removed and need attention. And “add”, “rm” and finally “commit” to get all of them sorted out.

Lot of people ends here. The problem appears when they get patches…

So how to deal with patches in git world? You can of course do “patch -p1 <some.patch” and take care of adding/removing files and doing commit. But git has a way for it too.

To generate patch you can use “git diff” and store output into file. But this will lack author information and description. So it is better to commit changes and then use “git format-patch” to export what you did into file. Such file can be attached to bug tracker, sent by email, put online etc. Importing it is simple: “git am some.patch” and if it applies then it is merged like you would do local commit.

There are other ways probably too. Quilt, stgit etc. But this one is using basic git commands.

And I still remember days when I thought that git and me do not match ;D

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.

Rawhide: unwanted baby in Fedora world?

For something about 15 years I was using Debian distribution and ones which derived from it (like Ubuntu). Basically whole time I used development versions of them and amount of issues was nearly not existing. Now I run Rawhide…

For those who do not know: Fedora world contains four distributions: Fedora, RHEL, CentOS and Rawhide. All new stuff goes to Rawhide which is then branched to make Fedora release. Every few years Red Hat forks released Fedora and uses it as a base for new RHEL release. Then CentOS guys create new release based on RHEL. At least this is how I see it — others will say “but rawhide is fedora”.

I think that the problem lies in development model. All new stuff goes to Rawhide but at same time nearly no one is using it anything can happen there. For example my KDE session lacks window decorations, Konsole5 freezes on any window resize and the common answer for such issues is “You should expect that in rawhide”.

Going into Fedora irc channels with questions is just waste of TCP/IP pockets because in a moment when you mention rawhide it is like everyone fired /ignore on you.

And it is some kind of fun (for some sick/weird definition of it) to watch how people start development of packages just after Fedora releases something. They upgrade and then start to seek what interesting happens in rawhide and can be built.

Each day I am closer to go back to Debian/Ubuntu for a desktop with just keeping Fedora in VM for development of some packages.

96boards?

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.

2 years of AArch64 work

I do not remember exactly when I started working on ARMv8 stuff. Checked old emails from Linaro times and found that we discussed AArch64 bootstrap using OpenEmbedded during Linaro Connect Asia (June 2012). But it had to wait a bit…

First we took OpenEmbedded and created all tasks/images we needed but built them for 32-bit ARM. But during September we had all toolchain parts available: binutils was public, gcc was public, glibc was on a way to be released. I remember that moment when built first “helloworld” — probably as one of first people outside ARM and their hardware partners.

At first week of October we had ARMv8 sprint in Cambridge, UK (in Linaro and ARM offices). When I arrived and took a seat I got information that glibc just went public. Fetched, rebased my OpenEmbedded tree to drop traces of “private” patches and started build. Once finished all went public at git.linaro.org repository.

But we still lacked hardware… The only thing available was Versatile Express emulator which required license from ARM Ltd. But then free (but proprietary) emulator was released so everyone was able to boot our images. OMG it was so slow…

Then fun porting work started. Patched this, that, sent patches to OpenEmbedded and to upstream projects and time was going. And going.

In January 2013 I started X11 on emulated AArch64. Had to wait few months before other distributions went to that point.

February 2013 was nice moment as Debian/Ubuntu team presented their AArch64 port. It was their first architecture bootstrapped without using external toolchains. Work was done in Ubuntu due to different approach to development than Debian has. All work was merged back so some time later Debian also had AArch64 port.

It was March or April when OpenSUSE did mass build of whole distribution for AArch64. They had biggest amount of packages built for quite long time. But I did not tracked their progress too much.

And then 31st May came. A day when I left Linaro. But I was already after call with Red Hat so future looked quite bright ;D

June was month when first silicon was publicly presented. I do not know what Jon Masters was showing but it probably was some prototype from Applied Micro.

On 1st August I got officially hired by Red Hat and started month later. My wife was joking that next step would be Retired Software Engineer ;D

So I moved from OpenEmbedded to Fedora with my AArch64 work. Lot of work here was already done as Fedora developers were planning 64-bit ARM port few years before — when it was at design phase. So when Fedora 15 was bootstrapped for “armhf” it was done as preparation for AArch64. 64-bit ARM port was started in October 2012 with Fedora 17 packages (and switched to Fedora 19 during work).

My first task at Red Hat was getting Qt4 working properly. That beast took few days in foundation model… Good that we got first hardware then so it went faster. 1-2 months later and I had remote APM Mustang available for my porting work.

In January 2014 QEmu got AArch64 system emulation. People started migrating from foundation model.

Next months were full of hardware announcements. AMD, Cavium, Freescale, Marvell, Mediatek, NVidia, Qualcomm and others.

In meantime I decided to make crazy experiment with OpenEmbedded. I was first to use it to build for AArch64 so why not be first to build OE on 64-bit ARM?

And then June came. With APM Mustang for use at home. Finally X11 forwarding started to be useful. One of first things to do was running firefox on AArch64 just to make fun of running software which porting/upstreaming took me biggest amount of time.

Did not took me long to get idea of transforming APM Mustang (which I named “pinkiepie” as all machines at my home are named after cartoon characters) into ARMv8 desktop. Still waiting for PCI Express riser and USB host support.

Now we have October. Soon will be 2 years since people got foundation model available. And there are rumors about AArch64 development boards in production with prices below 100 USD. Will do what needed to get one of them on my desk ;)

Year at Red Hat

In the morning I got an email:

Dear Marcin Juszkiewicz,

Congratulations on your one-year anniversary with Red Hat! Thank you for your commitment and work over the past year. We hope that it has been everything you expected it to be and look forward to celebrating your future success with the company.

Yes, already year passed since I joined ARM team at Red Hat. It was a good time and I do not plan to change it ;)

What I did during that time? Managed to get several packages built for AArch64, sent many patches upstream (some were easy, other required several updates) and even got one machine to use at home. It was not an easy ride but I am glad that I went that way.

I had some ARMv7a work done but over 80% of time spent with AArch64. First in simulators but then hardware started coming. First shared one with other developers (timezone differences helped a lot), then got remote one for own development use and finally one machine landed under my desk (the only one in Poland at that time). Do I have to add how it simplified work? GVim over X11 just works so the only difference is colorscheme and font used ;D

What next? More AArch64 work. There are still packages which fail to build ;D