Marcin Juszkiewicz

As I will leave Linaro at the end of May I would like to write a summary of current state of Linaro layers for OpenEmbedded.

At Linaro we have 3 layers:

1. meta-aarch64
2. meta-linaro
3. meta-linaro-toolchain

First one is BSP kind. I know that it had some issues which affected each build which had it in BBLAYERS but I fixed those issues. I would like to thank Khem Raj for pointing me at those.

We have git version of binutils there due to some changes which were not present in 2.23 line. But use of this version is not required as builds are fine with OE Core one.

We have “tune-armv8.inc” in this layer as well. There was attempt to merge that into OE Core but “/lib or /lib64” discussion started and at that time I decided to skip it. There are similar discussions at GCC and Glibc mailing lists. Once they sort that out OE tune file will be adapted by someone (I hope).

Rest of recipes can be split into 2-3 types. Few (like sysprof, emacs) just disable recipes for AArch64. Other have extra patches to add missing functionality or defines. And we have Linaro kernel for AArch64 there.

Second layer has ARMv7a(b) machine definitions used for our machine independent builds and some recipes.

There are no patches for OE recipes here. The only exception is busybox where we enable “dpkg(-deb)” command which we need for our tools used to merge rootfs with hardware support.

We have “recipes-extra” where we keep new recipes which may not be in a nicest state so are not yet merged into OpenEmbedded (or have no use there like “meta-toolchain-hhvm” one).

“recipes-linaro” is for our stuff. Images, automatic root shell on serial port etc.

And finally is toolchain layer. Everything here is related to gcc-linaro and Linaro binary cross toolchains (armv7a and aarch64 ones). GCC 4.6 and 4.7 is there but 4.6 one will be removed when 4.8 will be added into OE Core.

Who will maintain those layers after my leave? This was not decided yet. There are few guys at Linaro who know how to use OpenEmbedded but I think that most of them is outside of Builds and Baselines team.

If you have any questions then better ask now.

Good things have one ugly part in common — they have to end one day… For me that day will be 31st May 2013 when contract between Canonical and Linaro will end.

Those 3 years were great. I wrote a lot about it half year ago so those of you who are new - go to my previous “good bye Linaro” post before reading rest of this post.

Half year ago I was going to Canonical but got hold at Linaro for longer. Then I made a mistake by agreeing to postpone my move to Linaro instead of joining as soon as possible — my fault…

Last 6 months were full of interesting things. We went from just bootstrapped AArch64 port to fully working LAMP and SDK images built with OpenEmbedded. I integrated all Linaro layers into one repository and reorganized in a way that those who want only our toolchains can have them without using any of our changes. This move was greeted by lot of maintainers and users from OpenEmbedded community. Wherever new toolchain components were provided for tests I had them checked on first day to see how AArch64 situation got improved and provided fixes when they were needed.

Recent release of Yocto Project has several changes done by me and Riku Voipio integrated. OpenEmbedded project also made release and has even more our changes in it. Most of those were AArch64 related, some were software updates or fixes to low level stuff.

Linaro Enterprise Group has Owen Yamauchi from Facebook working on porting HipHopVM. He is using SDK created by OpenEmbedded to not worry about any build dependencies or missing libraries. With my work (and work from porters like Riku Voipio, Steve McIntyre, Yvan Roux and others) he got not only libraries but also tools he needed for his job.

Andy Johnson started OpenJDK porting — also with OpenEmbedded. Riku provided instructions which I merged into our ‘jenkins-setup’ scripts to make live easier for Andy.

Due to all that work I am often contacted by random people (not only from Linaro) wherever they have some AArch64 related questions. Sometimes even with ARMv4/EABI related like post from Nicolas Pitre a day after RMK wrote that FPU emulator has to be removed from the Linux kernel. I provided him instructions how to make such build and just to be sure that I did not made any mistakes I tried one on my machine. IIRC none of main distributions support EABI for ARMv4 (no thumb) processors.

But looks like all that has to end. Unless someone from Linaro member companies (or who knows, maybe even Linaro itself) wants to hire me. I am open for offers.

If I go outside of @linaro.org then I would like to stay around and check how things go — probably as ‘community member’ or how it is called.

And one more thing at the end. As usual when I end my work at one place I gather recommendations on LinkedIn. If you have few spare minutes and want to write something then it will be appreciated.

Linus Torvalds released Linux 3.9 and many websites published summaries what’s new in it. One of common entries is support for ChromeOS laptops. But what that means for Samsung ARM Chromebook users?

Let’s start with Kernel Newbies summary which lists 5 commits:

• Platform: x86: Add Chrome OS Laptop driver
• Platform: x86: chromeos_laptop - Add Acer C7 trackpad
• Platform: x86: chromeos_laptop - Add HP Pavilion 14
• Platform: x86: chromeos_laptop - Add Pixel Touchscreen
• Platform: x86: chromeos_laptop - Add Taos tsl2583 device

None of them are for ARM Chromebook. But that does not mean that nothing was done for it. Touchpad driver was merged, many Exynos platform changes were made but yeah — still lot to do.

But that’s a curse of ARM platforms…

UPDATE: Arnd Bermann wrote a comment on my Google+ post that Olof Johansson has “linux-next” bootable on ARM Chromebook. YAY!

UPDATE: I got ChromeOS 3.8 kernel running on my Chromebook. Needs some testing and then will land in “saucy” as default one probably.

Today I can celebrate 3 years of working for Canonical.

First days

I was supposed to start from 1st May but as I had vacations already planned for that week (in Poland 1st and 3rd May are national holidays) they asked me to start work one week earlier — on 26th April 2010.

First week was usual learning about company rules, structure, reading wiki etc. Then I went for vacations and right after I was going for UDS-M (somewhere around Brussels, Belgium) where I met a team of people of unnamed project. Some days after event that team got a name: Linaro.

Linaro Developer Platform

I am a member of Developer Platform from beginning. Our team was changing, we got more people than we lost some as they moved to newly created teams and we had few renames. First it was Foundations (like Ubuntu Foundations at Canonical), then Developer Platform, then just Platform. Now we are Bold & BeautifulBuilds and Baselines.

We work on delivering components done by other teams (like ARM and AArch64 cross toolchains, Linux kernel), provide test images created from Ubuntu packages or built with OpenEmbedded (soon also Fedora).

Since September 2012 I am working on AArch64 (64-bit ARM) bring-up with use of OpenEmbedded (as at that time none of distributions had anything working to base on). Updated toolchain, fixed many issues with different software packages, patched some applications/libraries. Cooperated with few teams at Linaro and with several upstream projects.

Canonical or Linaro?

As some people remember there was a moment last year when I was supposed to leave Linaro and go to Canonical. But someone decided to keep me for longer…

But such things does not last forever. At the end of May I will probably end my journey at Linaro cause contract for Canonical’s engineers will end. Unless someone wants to keep me for longer…

I plan to visit London and Cambridge on 16-22 May. Just for sight-seeing and meeting friends — no business this time.

Plan is to meet old OpenedHand fellows, some old friends from Poland, maybe visit Canonical office just to see it (as I work for them for nearly 3 years). And of course see something cause I was few times in London but managed to see only train/metro stations and nearly nothing more.

Then Cambridge for 40th Cambridge Beer Festival. There are friends to meet as well and maybe see something as well (but here I saw far more things than in London).

As usual flights from/to Berlin to one of London airports (plan to return from Stansted as it is the easiest to get there from Cambridge). Need to sort out some places to stay.

Also have to check which UK prepaid is useful today. I need few gigabytes over HSPA — previously Giffgaff was fine for it for just 10 GBP but they have changed rules. Tethering required due to tablet and Chromebook (which I plan to get repaired or replaced).

Any suggestions for 3G or place to stay?

As guys from/around Texas Instruments promised there is new Beaglebone Black on a market. Faster, cheaper, with video output and other extras. For me it looks like Raspberry/Pi killer done right.

What is on board?

There is a lot of goods:

• 1GHz TI AM355x cpu with ARM Cortex-A8 core supporting ARMv7-a instruction set
• PowerVR GPU with OpenGL ES support (closed source driver)
• HDMI output (with audio)
• 512MB ram
• 2GB eMMC
• 92 expansion pins
• USB Host
• USB device
• Ethernet
• microSD slot
• user controlled LEDs
• serial port header

And it still supports (most of) expansion boards from the original Beaglebone which can add extra functionality so possibilities are uncountable. All that for only 45$.

But why it is better?

1. ARMv7-a cpu core. It means that you can run any Linux distribution on it. Think Ubuntu/armhf, Debian/armhf, Fedora/armhf. No need to reinvent a wheel (aka armhfv6 done for Raspbian distribution).

2. No dependencies on closed source components. You can boot board and use it with what ever you want and still have control on all sources used. Sure, there are some binary blobs for OpenGL ES but if you do not need this then you are fine. Try to boot R/Pi without binary blobs…

3. Texas Instruments level of support. Sure, we heard that they abandoned mobile market but Sitara line of processors is still in development, there are new CPUs and they provide documentation and source code for product. Also amount of work done in mainline kernel is not something to be ignored.

4. Expansion headers. Compare 26 pins of R/Pi with 92 of Beaglebone… Then add capes to this.

So which one to choose?

Beaglebone Black of course ;D

As people on IRC told there are other cheap devices made in China with faster cpus and more memory. But for me Beaglebone is not ‘yet another ARM computer’ but rather ‘yet another microcontroller on ultra steroids’ and this is where the true power of this board resides.

I am subscribed to many mailing lists. Creating filters for them was usually pain but keeping all in one folder was also not useful. So I decided to make it more automatic.

There are many pages which will tell you how to use maildrop, how nice it is etc. But as I am used to “autofolder” set of procmail rules written by Kamal Mostafa from Canonical I had some requirements already and some ideas how to handle few things in other way.

So what I did? Maybe not so much so far:

• handle @list[sy].DOMAIN servers
• autocreation of folder structure (/ML/{DOMAIN}/{LISTNAME})
• all GitHub projects are handled as folders of github.com

There is a lot of work to do but for now I am happy with what I did.

You can see it in hrw/dotfiles-mailfilter repository on github.

If someone finds it useful then please comment, fork, send merge requests, patches etc.

Around week ago courier brought me Nexus 7 tablet (32GB, wifi only) as kind of upgrade to my Archos G9 80 ‘so called’ Turbo one.

First steps

Charged a bit, booted into Android 4.2 and was greeted by “upgrade to 4.2.2 is possible” soon after wifi connection. But decided to go my way instead ;)

Fetched Clockworkmod touch recovery, CyanogenMod 10.1 nightly image and Google Apps 4.2.2 pack and booted into bootloader. Quick ‘OEM unlock’, flash of new recovery and few minutes later I had CM 10.1 running just like I wanted.

Restored apps from Archos with use of TitaniumBackup and after some configuration I had tablet which responds fast and behaves properly.

Multiuser stuff

As my daughter was main user of Archos I waited for Android 4.2 to get multi user capabilities. Played a bit with them on G9 (with Paranoid Android installation) but 512MB ram and OMAP4430 gave my terrible experience with far too many moments when I wanted to crush tablet into pieces…

So when Mira had come from kindergarten I shown her Nexus 7, made a photo with internal ‘want to be a camera’ thing and gave instructions on how to turn device on and switch to her configuration. She had no problems with understanding it ;)

There are some issues with multiuser stuff. Each user is expected to have Google account, applications are not shared etc. I understand why but in my case it was annoying.

But there is Multi-User App Share app which allows to share applications with different users. So Mira has all her children apps and games available and is not able to spend real money on in-app payments due to lack of Google account (and credit card). I was able to remove them from my configuration as well.

Sharing files is more complicated as so far I did not check is there a shared space for them. So each of us has own music/movies.

Do I miss something?

There are few things which Archos G9 80 has and Nexus does not:

• HDMI output
• microSD slot
• USB Host port

I may miss video output sometimes but had not used it for over half a year now. MicroSD would be nice so I would not have to buy 32GB version. But ~20% of tablet (50$) was sponsored by Tizen ;)

And by USB Host port I mean normal EHCI host port. Not an OTG one present in Nexus 7.

But I do not miss crazy upgrade scheme invented by Archos. Also do not miss I Scream for Sandwitch version of Android they offered. We have XXI century and their upgrade path is from previous millenium.

Complains?

So far I did not find something to complain about. OK, screen could be more square (4:3 Archos, 16:10 Nexus) but it is fine for me. Ask me in few months ;)