Six years ago I was one of first members of project which later got “Linaro” name. Today I am back. But in different form.
On 30th April 2010 I got email titled “Welcome to Linaro” and became software engineer at Linaro. Time shown that it was done in a way which helped to start project but was not liked by member companies. The plan was to leave in October 2012 but due to someone’s decision I stayed until May 2013.
Today I got “Linaro Assignee On-Boarding” email which means that I am still officially software engineer at Red Hat but assigned to work at Linaro. Same as people from other member companies.
I wonder will I get my unofficial title “main complainer at Linaro” back or do I have to deserve it again ;D
During weekend I was in Puck, Poland at small conference called “Zimowisko linuksowe” (Linux winter camp) where I had a talk called “Dlaczego moje urządzenie nie jest obsługiwane przez dystrybucje” (Why my device is not supported by distributions).
In talk I presented how distributions (Debian, Fedora) handle ARM devices (one kernel for all, one image for all) and why it does not fit Raspberry/Pi or Chromebook. Also mentioned Roseapple/Pi as an example of how not to make support for device.
There were questions about suggested boards (most of people knew Raspberry/Pi and one or two other by name) and ARM powered laptops other than Chromebooks.
And then we went to celebrate birthdays of few friends who had them on same day.
You can download presentation in Polish or English (translation was requested by few folks from IRC after I annouced that there will be such talk).
Few hours ago, somewhere in some hotel in Bangkok Linaro Connect has started. So during morning coffee I watched keynote and noticed that Jon Masters presented RHELSA 7.2 out of the box experience on Huskyboard. And then brand new board from 96boards project was announced: Cello.
Lot of people was expecting that this Linaro Connect will bring Huskyboard alive so people will finally have an option for some cheap board for all their AArch64 needs. Instead Cello was presented:
Compared to Husky (below) there are some hardware differences to notice but it is normal as 96borads enterprise specification only tells where to put ports.
I suppose that both boards were designed by different companies. Maybe it was a request from Linaro to ODM vendors to design and mass produce 96boards enterprise board and Husky was prototyped first but Cello won. Or maybe we will see Husky in distribution as well. Good part is: you can preorder Cello and get it delivered in Q2/2016.
Have to admit that I hoped for some industry standard board (96boards Enterprise specification mentions microATX) instead of this weird 96boards-only format which I ranted about already. Anyway 299 USD for quad-core Cortex-A57 with SATA, UEFI, ACPI, PCIe (and maybe few more four letter acronyms) does not sound bad but good luck with finding case for it ;(
When userspace want to talk to kernel it can use system calls. Applications usually do it via wrappers in libc to not have to deal with different numbers on different architectures.
There are over four hundred system calls in Linux kernel. Many of them have “legacy” status and as such are not available on many new architectures. Riku Voipio from Linaro has nice slides about it.
So to make things easier for developers I worked on creating a table showing all system calls and their number/status on different architectures. But this table was generated partially by hand…
I changed code to keep a list of all syscalls in place, wrote generator of C code and added makefile on top. And then pushed it into a new git repo called syscalls-table. Code is MIT licensed.
Please go, check the code, run it on any architecture and send me pull requests. The only requirements for generating list of architecture specific syscalls list are bash and C compiler. Table generation requires Python but does not have to be run on target platform.
I was mostly offline during last three days. You know — meeting long-time-no-see friends, walking tens of kilometres in other city looking at cellphone screen (aka playing Ingress) etc.
But even then it was hard to not notice that Raspberry Foundation announced new version of their product called Raspberry/Pi 3 — many friends asked me what do I think about it, is it worth buying now, will Fedora run on it etc.
So let make it short. No, it will not run Fedora 24 because there is no support for this device (I would not call it developer board as it would be insult to all developer boards) in mainline kernel, it still boots in insane way, has new binary blob without permissions to distribute etc… And since R/Pi 2 got released year ago there was no community effort to get this board supported and we have better things to do.
Is it worth buying? If all you want to do is connect few sensors to GPIO/I²C/SPI pins then maybe as it is cheap, but I would go for Beaglebone to get wide distribution support. If you want to make a desktop then forget it (1GB of memory). If you want to make anything related to storage/networking forget it too (storage on USB shared with all other USB devices as there is only one USB host port).
For years Raspberry Foundation did not learn that price is not the only thing which makes product worth using. BCM2835 was terrible but usable. BCM2836 got newer cpu core but rest stayed so resulting device was far behind properly made developer boards. BCM2837 should not happen.
Few days ago my manager asked me if I would like to go back to Linaro. This time not as ‘Linaro-but-Canonical engineer’ but as ‘Red Hat assigned engineer’. That made me thinking…
Those three years at Linaro were good time. Learnt a lot about cross toolchains, got possibility to work on bootstrapping AArch64 support in OpenEmbedded, Debian/Ubuntu and then Fedora/RHEL. Met many skilled people from around the world, travelled into places which I would probably not visit on my own.
Going back sounds good. From my discussions with few people from Linaro there is more and more AArch64 related work there (and I have some hardware at home) so my rusty arm32 skills can rust in peace. Have to take a closer look at what exactly is on a plate there to take and find some place.
So if you work for Linaro and will be at FOSDEM (or devconf.cz) then I would love to talk.