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
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.
Few months ago I wrote about Xulrunner/AArch64 patches. Today I was able to make use result of them.
How to easily test? I went to YouTube and selected first suggested video (without logging in). Had to switch to HTML5 player and it worked fine:
Second tab was build configuration page:
And all that on Fedora/rawhide with windows X11 forwarded to my desktop. Nice!
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.
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?
In 2012 I was porting OpenEmbedded to target AArch64 so I can say that I did first OE builds for that architecture.
But today I did kind of reverse thing:
BB_VERSION = "1.21.1"
BUILD_SYS = "aarch64-linux"
NATIVELSBSTRING = "Fedora-21"
TARGET_SYS = "arm-oe-linux-gnueabi"
MACHINE = "genericarmv7a"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES = "armv7a vfp thumb neon callconvention-hard"
TARGET_FPU = "vfp-neon"
Yes — I did build on AArch64 machine targeting ARMv7a system. Had to edit one patch (pseudo-native was set to use very old glibc symbols which are not available on 64-bit ARM) but after that build was running just fine.
I did not tested resulting binaries.
I am not maintaining packages in Fedora. But my work is related to building them for AArch64 architecture. And this means editing patches and/or adding new ones…
When I was doing AArch64 bootstrap in OpenEmbedded it was easy. Altering Debian/Ubuntu packages was also simple task. Why? Because in both situations patches are applied in developer friendly way so it is visible which ones are applied in which order and (as quilt is used) they are also easy to refresh and edit.
But not in Fedora. Here we have
%patch macros which use workflow from 80’s. Yes,
patch <pX file.patch is not modern way of handling patches which may need work. Especially when you first fetch and install all build dependencies just to get build failed cause nth patch does not fully apply. Or when your work requires to alter patches 3rd, 7th and 13th.
Sure, there is
%autosetup macro which should solve a problem. But it does not. There are packages where some patches are reverse applied or with other patch level than 1. I saw also ones where there is extra directory change during applying diffs.
So dear package maintainers — please migrate to
%autosetup (with quilt or git) to make life of other developers easier. I think that there will be more people satisfied when this will happen than just me.