Tag Archives: debian

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.


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.

Let’s install Debian on AArch64

Today I took a small break and decided to install Debian on APM Mustang. How it went? Read on.

Requirements: – kernel and initramfs from Debian daily d-i builds – USB stick with GRUB from Fedora (one from my second Fedora installation – APM Mustang with UEFI – serial cable connected to Mustang and other computer – Ethernet cable to get network on Mustang

Why did I used GRUB from Fedora? Debian one had issues with finding own modules (or something like that).

Ok, so let’s boot into GRUB. Once there load kernel and initramfs:

linux /debian/vmlinux console=ttyS0,115220
initrd /debian/initrd.gz

Installation went smooth. To the point when installer tried to install GRUB :(

Rebooted, loaded freshly installed kernel/initramfs from Fedora boot loader but still failed:

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ... done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)

So will not check how Debian works on APM Mustang. But bug will be reported.

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 ;)

From a diary of AArch porter –- testsuites

More and more software come with testsuites. But not every distribution runs them for each package (nevermind is it Debian, Fedora or Ubuntu). Why it matters? Let me give example from yesterday: HDF 4.2.10.

There is a bug reported against libhdf with information that it built fine for Ubuntu. As I had issues with hdf in Fedora I decided to look and found even simpler patch than one I wrote. Tried it and got package built. But that’s all…

Running testsuite is easy: “make check”. But result was awesome:

!!! 31294 Error(s) were detected !!!

It does not look good, right? So yesterday I spent some time yesterday on searching for architecture related check and found main reason for so big amount of errors — unknown systems are treated as big endian… Simple switch there and from 31294 it dropped to just 278 ones.

Took me a while to find all 27 places where miscellaneous variations of “#if defined(__aarch64__)” were needed and finally got to point where “make check” simply worked as it should.

So if you port software do not assume it is fine once it builds. Run testsuite to be sure that it runs properly.

AArch64 is in the house

Today FedEx courier delivered me a package. Inside was APM Mustang in 19″ rack case.

I unpacked, grabbed all required cables from my cable boxes (power, Ethernet, serial), connected it and booted. It arrived at very good moment as we are in a middle of Fedora 21 mass rebuild so I do not have to use remote machines anymore.

Will not write about technical details cause those are already known (8 cores, 16GB ram, SATA storage, 1GbE networking). Do not expect benchmarks as I am not allowed to publish results. If you want to compare build speed then go to Launchpad and check how long it takes to build Ubuntu packages for arm64 target.

My plans for machine? Run Fedora rawhide, fix building issues. I also plan to play with virtualization to check how Ubuntu and Debian work.

ARM7 != ARMv7

ARM architecture is fun when it comes to names and numbers. And it is around 30 years old as well. So from time to time I have a discussion where I say something like in title…

There are few sources of mistakes when it comes to ARM. Family names, instruction sets, core names and marketing. Hard to tell which makes biggest mess…

Anything below ARMv7a is history — there is ARMology about it so please read it. But it does not mean that we have clear situation now :D

ARMv7a (and higher) means Cortex-A family. But due to companies like AllWinner and Apple we have it more complicated:

  • A4 is Apple cpu with Cortex-A8 core
  • A5 is low-end Cortex-A5 core but also Apple cpu with Cortex-A9 cores (there was also A5X)
  • A6 is Apple cpu with their own core (also A6X)
  • A7 is Cortex-A7 core but also Apple cpu with 64-bit ARMv8 cores
  • A8 is Cortex-A8 core (the only single core Cortex-A)
  • A9 is Cortex-A9 core
  • A10 is AllWinner cpu with Cortex-A8 core (there was also A10s)
  • A12 is Cortex-A12 core
  • A13 is AllWinner cpu with Cortex-A8 core (stripped down A10)
  • A15 is Cortex-A15 core
  • A17 is Cortex-A17 core
  • A20 is AllWinner cpu with Cortex-A7 cores
  • A23 is AllWinner cpu with Cortex-A7 cores
  • A31 is AllWinner cpu with Cortex-A7 cores (also A31s)
  • A53 is Cortex-A53 core (64-bit ARMv8)
  • A57 is Cortex-A57 core (64-bit ARMv8)
  • A80 is AllWinner cpu with eight cores (4xA7 + 4xA15)

There are also other Cortex cores but their name do not start with “A” :) But the good thing is that all ARMv7a cpus can run same code. ARMv8 ones can run own code — 32-bit support is optional. All all major distros like Debian, Fedora, OpenSUSE or Ubuntu work on support for both families.

UPDATE: Arnd Bergmann wrote in comment (switch to Blog below article) there is also A2, which is the PowerPC core used in BlueGene. Further, AMD has x86 CPUs called A4, A6, A8 and A10, which are also not ARM. Fun, isn’t it?