Marcin Juszkiewicz

As my wife’s laptop got SSD upgrade I had another spare HDD. But what to do with 320GB hdd? Decided to add it into “pinkiepie” (APM Mustang) and test Fedora installation.

There are probably many ways on how you can install Fedora on x86-64 machine. But on Mustang there are only three:

• DVD boot
• PXE boot
• use any method to load kernel and initrd of net installer

My DVD-RW drive decided to not read any discs so I bought new one. Put fresh Fedora 21 AArch64 installation DVD into it and… still something wrong. Not with contents of disk but with drive or who knows.

Decided to skip PXE as it always involves creation of TFTP server, setting DHCP server to direct into proper one etc. Too much work just to deliver two files.

So I went with last method and used GRUB which I already had on /dev/sda in EFI partition.

Fetched vmlinuz and initrd.img to /boot/pxeboot/ directory and rebooted machine.

Then into GRUB and it’s command line:

linux (hd0,gpt2)/pxeboot/linux console=ttyS0,115200 inst.repo=http://armpkgs.fedoraproject.org/compose/21_Alpha_TC1/Server/aarch64/os/
initrd (hd0,gpt2)/pxeboot/initrd.img

Then just Ctrl-x and it goes. As it has to fetch 258MB squashfs.img with installer I used that time to install VNC viewer (KRDC) on my desktop — it will be used to control installer as text mode over serial one is very limited.

Image fetched, booted. Then something like “Do you want to use VNC (recommended) or go with text mode (limited)?” appeared so I went for remote one, used no password and then installer appeared and I was able to select hard drive and what exactly I wanted to install. Too bad that it had to end due to some dependency issues:

So I went for a fix. Took me some time but next version of “abrt” should be fine.

Anyway why stop? I decided to alter a way of installation a bit. Let’s use Polish Fedora mirror and local copy of “squashfs.img” file:

linux (hd0,gpt2)/pxeboot/linux console=ttyS0,115200 inst.repo=http://ftp.icm.edu.pl/pub/Linux/dist/fedora-secondary/development/21/aarch64/os/ inst.stage2=http://192.168.0.13
initrd (hd0,gpt2)/pxeboot/initrd.img

This time I got wide choice of installation targets (it was only Fedora Server before). Wanted to install XFCE but chosen “Minimal system” instead as installer was unable to tell me what is wrong with my selection.

Few minutes later (after setting root password and creating normal user) I had installed system. Rebooted, went to UEFI shell, selected FS1: and booted GRUB which loaded fresh Fedora 21 for me.

Final words? It went much, much better then my previous installation of F21 on same hardware (I used chroot or other crazy stuff). Not checked iSCSI or other exotic (to me) ways of doing storage but that’s maybe for other day.

When GNU project was announced over 30 years ago it was something great. But time passed and I have a feeling that it is more and more politics instead of coding.

I do builds. For over 10 years now. It was ARM all the time with some bits of AVR32, MIPS, x86. During last two years it is nearly 100% AArch64. And during last months my dislike to GNU project grows.

Why? several reasons.

Commit messages

There is a lot of articles about “how to write good commit messages”. I can tell you where to look for bad ones: gcc, binutils, glibc — base of most of GNU/Linux distributions. All of them can be fetched from GIT repositories but look like deep in CVS era. Want to find what was changed? You will get it in commit message. Why it was changed? Forget.

GNU forks

Do you know what IceCat is? Or GNUzilla? Let me quote official homepage:

GNUzilla is the GNU version of the Mozilla suite, and GNU IceCat is the GNU version of the Firefox browser. Its main advantage is an ethical one: it is entirely free software. While the Firefox source code from the Mozilla project is free software, they distribute and recommend non-free software as plug-ins and addons.

Where is source? Somewhere in GNU cvs probably. I failed to find it. OK, there is a link to something which is probably source tarball but we have XXI century — developers take source control systems got granted.

Of course IceCat fails to build on AArch64. Why? Because it is based on already obsoleted by upstream version 24 of Firefox. Support for 64-bit ARM platform was merged around Firefox 30 and is complete in version 31. Sure, I could dig for patches for IceCat version but no. This time I refuse.

I do not know, but maybe GNU project needs some fresh blood which will make them more developer friendly?

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

I have a bunch of ARMv7a boards at home. They are from different years, have misc CPUs and GPUs. All I think that some of them suck for some reasons.

Pandaboard was great board when got released. Then Texas Instruments fired everyone involved so now it is crap. Sure, mainline kernel works fine but no audio/video decoding in hardware, no OpenGLES due to PowerVR stuff which no one cares about because it is proprietary.

Wandboard Quad. Cool, fast, 2GB of memory, SATA. And hardcoded XGA (1024x768) resolution which can not be changed. Awesome? Not so much when you connect it to FullHD monitor. And forget about community — they are mostly stuck on 3.0 and 3.10 kernels based on Freescale code drops. I should dig deeper when looked at i.mx6 hardware ;(

Looks like it is time to check other boards. Minnowboard Max probably — x86 will fully open drivers.

Lot was written about why upstreaming matters. And why it should be done earlier than later too. And I found out that I have perfect example.

Few days ago Linus Walleij contacted me with a question:

Hi Marcin, do you still have the Nomadik NHK8815 board? I’m contemplating fixing it to work some time, but haven’t got hold of one. I think it only needs a device tree actually, so we could hack it up at some conference if you’re at the same some time.

And then I realized that indeed — I still have it somewhere in my basement gathering dust. We quickly agreed on shipping it so Linus will be able to finish work on adding support for already obsolete board in mainline kernel.

For me NHK-15 is a perfect example of device which was supported in wrong way. When I got it 5 years ago it was already several kernel releases behind with 2.6.16.2 kernel (no stable updates even). I managed to get Poky Linux running on it but told clearly that it will gather dust after finishing task because for me board with no upstream support is worthless.

So board spent few weeks on my desk and then went back to the box and on shelf in basement. Then became forgotten. For 5 years. Today I opened box, checked contents, added some filling so it is ready for courier. Then I will forget about it again.

UPDATE: My Sim.One board joined NHK-15 as it is hard to find working device with EP93xx processor in it.

I am starting to dislike current situation of handling sound under Linux.

On my desktop I am using Fedora which is using PulseAudio to handle sound. And recently something changed cause I have to reach mute button too often.

Normally I have Deezer in Chrome playing some background music with volume in web app set to the highest value. I can use KDE mixer to control how loud it is and it works fine. When I run YouTube, Vimeo it is fine. Adobe Flash videos? Fine as well. And according to PulseAudio mixers it keeps stream value at same level every time.

But I do not like that browser. I use Firefox for most of my web stuff. But every time I play YouTube video it jumps with PA stream volume to the highest possible setting so even my next street neighbors are probably able to hear it. Sure, I can change YT volume to nearly zero but when will have to do it with all other web applications as well (and many of them do not have loudness control).

MPlayer (which I use for movies) plays nicely with volume - alters only own PA stream volume.

I think that it is a time for me to report bug against Firefox.

So this year we are going to Moomins World, Naantali, Finland. All dates are set, PTO granted, car checked.

Trip will start on 5th July with Szczecin -> Łódź trip. There I will take my 6 years old daughter Mira to event named “Old computers & games” to show her which kind of computers I used. Then Łódź -> Olecko to visit my mother. Will spend few days there.

And then crazy trip starts. Friday 11th will take us to Klaipėda, Lithuania to see dolphins. Next day we go to Rīga, Latvia through Hill of Crosses in Šiauliai, Lithuania. Look around and on Sunday -> Tallinn, Estonia where we will spend ~24h as this direction is mostly to not drive everything in one day.

Then ferry to Helsinki, some sightseeing and on 15th we will go to Turku and stay there in yet another hotel.

Finally on 16th July plan is to spend whole day in Moomins World in Naantali. Walk, see, take photos and have a good time.

Next day equals Tampere. Moomins museum and visiting Thomas Ruecker. Then quick run to catch ferry in Helsinki so we can spend some time in Tallinn again and do some proper sightseeing. Similar with Riga and finally Devils’ Museum in Kaunas, Lithuania on last day.

Few days of rest in Olecko and go back home probably through Gdańsk.

I hope that it will be the adventure. One of those nasty disturbing uncomfortable things which you remember for long ;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 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.