Tag Archives: debian

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?

It is 10 years of Linux on ARM for me

It was somewhere between 7th and 11th February 2004 when I got package with my first Linux/ARM device. It was Sharp Zaurus SL-5500 (also named “collie”) and all started…

At that time I had Palm M105 (still own) and Sony CLIE SJ30 (both running PalmOS/m68k) but wanted hackable device. But I did not have idea what this device will do with my life.

Took me about three years to get to the point where I could abandon my daily work as PHP programmer and move to a bit risky business of embedded Linux consulting. But it was worth it. Not only from financial perspective (I paid more tax in first year then earned in previous) but also from my development. I met a lot of great hackers, people with knowledge which I did not have and I worked hard to be a part of that group.

I was a developer in multiple distributions: OpenZaurus, Poky Linux, Ångström, Debian, Maemo, Ubuntu. My patches landed also in many other embedded and “normal” ones. I patched uncountable amount of software packages to get them built and working. Sure, not all of those changes were sent upstream, some were just ugly hacks but this started to change one day.

Worked as distribution leader in OpenZaurus. My duties (still in free time only) were user support, maintaining repositories and images. I organized testing of pre-release images with over one hundred users — we had all supported devices covered. There was “updates” repository where we provided security fixes, kernel updates and other improvements. I also officially ended development of this distribution when we merged into Ångström.

I worked as one of main developers of Poky Linux which later became Yocto Linux. Learnt about build automation, QA control, build-after-commit workflow and many other things. During my work with OpenedHand I also spent some time on learning differences between British and American versions of English.

Worked with some companies based in USA. This allowed me to learn how to organize teamwork with people from quite far timezones (Vernier was based in Portland so 9 hours difference). It was useful then and still is as most of Red Hat ARM team is US based.

I remember moments when I had to explain what I am doing at work to some people (including my mom). For last 1.5 year I used to say “building software for computers which do not exist” but this is slowly changing as AArch64 hardware exists but is not on a mass market yet.

Now I got to a point when I am recognized at conferences by some random people when at FOSDEM 2007 I knew just few guys from OpenEmbedded (but connected many faces with names/nicknames there).

Played with more hardware then wanted. I still have some devices which I never booted (FRI2 for example). There are boards/devices which I would like to get rid of but most of them is so outdated that may go to electronic trash only.

But if I would have an option to move back that 10 years and think again about buying Sharp Zaurus SL-5500 I would not change it as it was one of the best things I did.

The story of Qt/AArch64 patching

In over a year of my work as AArch64 porter I saw a lot of patches. But Qt one has the most interesting history.

Around year ago when I was building whatever possible during my Linaro work we got to the point when Qt jumped into a queue. Build failed but fixing was quite easy — all I had to do was to take “webkitgtk” patch written by Riku Voipio and apply it to Qt 4. Resulting file landed in “meta-aarch64″ layer of OpenEmbedded and is still there.

Time passed. More common distributions like Debian, Fedora, OpenSUSE, Ubuntu (alphabetical order) started working on their AArch64 ports. And one day Fedora and Ubuntu started working on building Qt 4. I do not know who wrote QAtomic stuff but I saw few versions/iterations of it and it took me quite long time (first on model, then on real hardware) to get it fully working in Fedora — used Ubuntu version of patches.

Up to this moment it was over 9 months and still no upstreaming was done. So one day I decided to go for it and opened QTBUG #35442. Then reopened issue #33 in “double-conversion” project (which is used in few places in Qt) as they got good fix and merged wrong one (but it is fixed now). For that one I opened a request to update to newer version of “double-conversion” as QTBUG #35528.

But story did not end there. As Qt 4 development is more or less ended I was asked to provide fixes for Qt 5. Took me a while. Had to create a graph of build time dependencies between Qt 5 components (had to break few in meantime) and slowly module after module I got most of it built.

There were 3 components which required patching:

First one is solved upstream and waits for Qt guys. I was told that 5.3 will get it updated. Second one is already reviewed and merged. Last one left and here is a problem as it looks like the only person who does QtWebKit code reviews is Allan Sandfeld Jensen but he can not review code he sent. I am not able to do that due to Qt Contributor License Agreement which needs to be signed and (due to legal stuff) I can not do that.

So how it looks now? I would say that quite good. One 3rd party project needs update (in two places of Qt 5) and one patch needs to get through code review. I still need to send package updates to Fedora bug tracker. Ubuntu will need to merge patches when they move to 5.2 version.

Another distribution said goodbye to ARMv5 devices

Fedora 18 just became EOL. Most of the people do not care as F20 is present so they can run it on their PCs. But there is a group of users which may care.

All those people with ARMv5t hardware are left with Debian/armel now as there is no other big distribution supporting their devices anymore. Someone will ask “what about Ångström or Gentoo?” but who sane would build Gentoo on armv5te?

I do not remember when last time I used something with arm926 core (or similar – like Kirkwood). Probably few years ago when helped friend to get Sheevaplug booting into Debian.

But there are still Sheevaplugs, Guruplugs, *plugs and QNAP devices out there serving their users with selected services. And some of their owners will have to decide what next…

Start: Waiting for yumcache lock

Have you ever tried to build a package under Fedora (or RHEL)? Did you used “mock” for it? If you answered “yes” to both questions I have a task for you: do 2 or 3 builds at SAME time…

Curses, curses and other ugly words will start in your mind. I have no idea why in days of multiple cpu cores and gigabytes of memory “mock” tool forces users to do one build at time. Sure, there are ways to make several builds at same time but all sucks. And I am going to write why and compare it to “pbuilder” from Debian world.

Ok, so what “mock” is? It is a tool which do some tasks in defined order:

  • creates chroot with base system
  • installs required development packages
  • creates source package
  • installs build dependencies
  • builds package
  • copies resulting packages and logs into results dir

So where the problem is? First thing: there are multiple problems ;(

First issue: mock assumes that there will be one run at time and does it in /var/lib/mock/TARGET/ (where TARGET is ‘fedora-rawhide-aarch64′ for example). This can be solved with “–uniqueext=packagename” argument.

Second issue: there is ONE yum! Instead of using yum inside of chroot mock is using system one. So if you run few mocks at time (remember: cpu time and memory are cheap) you will see “Start: Waiting for yumcache lock” message for most of time (twice per build).

Why it drives me mad? Because “pbuilder” in Debian did not have such silly issues. Each build was done in “mktemp” named directory and APT was used inside of chroot. Sure, that could mean more fetching of packages but I had local APT proxy for it which allowed me to do 30-50MB/s downloads.

And I do not want to mention fact that if you want to configure mock you have to do that system wide…

I miss Debian tools

It is nearly two months since I switched from Debian/Ubuntu to Fedora/RHEL. And I start to miss Debian tools…

Under Debian (which also means derivatives like Ubuntu) I used simple set of tools and I have found their Fedora replacements:

Debian Fedora
dpkg rpm
apt-get yum/dnf
apt-cache yum/dnf
dpkg-buildpackage rpmbuild
debuild rpmbuild
pbuilder mock
debdiff rpmdev-diff
dgit(?) fedpkg/rhpkg

The problem with Fedora tools is that they feel like few years behind Debian ones ;(

While Debian world moved to use “quilt” to manage patches in source packages few years ago, Fedora’s RPM just got it recently so it is hard to find package which makes use of it. Updating patches is far from being pleasure.

Yum (and it’s younger brother ‘dnf’) work in other way than APT. But are usable and do what they have to. The fun starts when you run “yum upgrade -y” on slow machine (like AArch64 model) and someone will regenerate repository data in meantime — you end with 404 errors cause repodata/ directory uses random file names…

rpmbuild works. It even has some limited support for running separate steps. But without dependencies between them so “rpmbuild -bi specfile” needs “rpmbuild -bc specfile” first while in Debian world “debian/rules install” is enough. There is also “--short-circuit” option to not clean build directory when you want to go through single steps. But resulting binary packages are tainted and can not be installed without using “–nodeps” switch to RPM. I see a sense behind it but it hit me hard on AArch64 when I was building Qt (do not ask how long it took cause I did it several times during last 2 months).

Then we have mock. Argh… I put it in one line with pbuilder but it is not worthy. No user setup possible, just one build at time (my machine is now 10% busy) make mock wasting lot of developer time. I opened bugs with feature requests for user config and multiple builds — hope that one day it will appear.

And last entry is what I like. Both fedpkg and rhpkg allow me to clone git repository of package so I can create patches for packaging in quick way. In Debian world I never used such tool. Under Ubuntu packages were kept in Bazaar repositories but you know already what I think of this SCM.

My first day with Fedora

Yesterday I switched my home desktop from Ubuntu 13.10 to Fedora 19 to have work environment ready for my Red Hat tasks.

Installation was easy as Fedora installer does not ask too many questions. But also does not give any software choice so I took KDE one. Made a backup of Ubuntu rootfs and /home partition and 10 minutes later I was running same X11 session but with Fedora logo in a corner.

Installing extra packages is argh… There is yum and basically nothing else. I tried Apper and Yumex — none of them was useful. Apper was unable to remove Konversation and message I got was useless (“some package depend on it” like). Yum did not have any objections. Yumex was even worse as it gave me a list of all packages without any grouping applied. Even “dselect” was better in 1999 when I started with Debian.

So I installed APT. This one works but only kind of… “apt-cache search something” takes eons, installing packages is impossible due to a way how RPM works…

Because RPM allows to have more than 1 version of package installed at same time. WHY? How it is supposed to work at all??? And no, I did not have any filesystem corruptions or something like that…

Anyway those problems can be bypassed or ignored. But then there are other ones. I always thought that Debian legal team has very strict rules about what can go into distribution. Fedora proved that I was wrong. External repositories are a must have here. MP3 or AAC playback? Forget. Probably also video playback etc. Want Google Chrome? Forget. I understand why Adobe Flash is not in repo (but there is one with it as well) but all that? Probably there are more entries here but I did not yet finished installing stuff I use/need.

Will have to add few tweaks here and there (like bumping “nr_uarts” kernel option to have all 7 serial ports) but it works. And I like “journalctl -b” way of checking what was going on since system boot ;D