This was good lesson. I learnt more about how UseCase Manager works, took profiles from ChromeOS and added them into Ubuntu so other users will be a bit more safe (due to lack of testers it took months to merge it into “precise” and “quantal” releases).

During last months I had discussions with some Debian, Ubuntu, Fedora developers about how to solve such problems and how to keep UCM profiles shared between distributions.

In meantime Liam Girdwood pointed me to (not used) UCM git tree at ALSA Project server. So finally I spent some time and sent Ubuntu ones for merging.

I also got newer profiles for OMAP4 devices and some updates for Chromebook ones.

The idea is to collect UCM profiles, keep them in one place and share in each distribution packages. So if your hardware has profiles created then join us to make users life easier.

All rights reserved © Marcin Juszkiewicz
Call for ALSA UCM profiles was originally posted on Marcin Juszkiewicz website

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.

All rights reserved © Marcin Juszkiewicz
State of Linaro layers for OpenEmbedded was originally posted on Marcin Juszkiewicz website

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.

All rights reserved © Marcin Juszkiewicz
Looks like it is time for me to say good bye again was originally posted on Marcin Juszkiewicz website

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.

All rights reserved © Marcin Juszkiewicz
Linux 3.9 and Chromebook support was originally posted on Marcin Juszkiewicz website

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…

All rights reserved © Marcin Juszkiewicz
3 years at Canonical was originally posted on Marcin Juszkiewicz website

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?

All rights reserved © Marcin Juszkiewicz
Time to visit UK again? was originally posted on Marcin Juszkiewicz website

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.

All rights reserved © Marcin Juszkiewicz
Death to Raspberry/Pi — Beaglebone Black is on a market was originally posted on Marcin Juszkiewicz website

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.

All rights reserved © Marcin Juszkiewicz
Automatic sorting of mailing lists with maildrop was originally posted on Marcin Juszkiewicz website

OpenGL ES

There is a driver for OpenGL ES for Samsung Exynos5 Dual cpu present in Chromebook. But there are two versions of it: Week35 and Week45. Both require different kernel versions.

Ubuntu 13.04 has 3.4.0-5 kernel package which was built from R23 kernel branch. Week35 OpenGL ES driver works with it and you have to grab it from ChromeOS (but maybe it got updated there already).

I still have to find time and get R25 (or R26 or R27) kernel working so we could upgrade to Week45 driver. This one is available in ChromeOS as well (beta or dev).

Where are my packages?

There were packages which provided OpenGL ES driver binaries (week45). I removed them due to license issues as it looks like Samsung bought Mali T604 license from ARM Ltd. and got it working with Exynos5 Dual. Then they sub licensed it to Google for use with ChromeOS.

So Samsung does not distribute the driver — Google does. And even when they give tarball with files there is no license in it — just standard “Google Terms of Service” note.

No redistribution license == no packages. Sure, someone can make “chromebook-opengles-driver-installer” like package which would grab binaries from ChromeOS (I did such for week35) or will fetch them from network. Feel free to do it — you can use my chromebook-mali-driver repository as a base. Once you will get it working I can put it into Samsung Chromebook PPA.

Multimedia decoding

Other thing is hardware accelerated multimedia decoding (maybe also encoding). Under ChromeOS it was done with OpenMAX stuff. Google even had some binaries available but they crashed badly under Ubuntu.

How situation looks today? No idea as I did not had time for Chromebook stuff in last months.

All rights reserved © Marcin Juszkiewicz
Hardware acceleration on Chromebook was originally posted on Marcin Juszkiewicz website

Please note (RSS readers mostly) that this post will contain many YouTube videos embedded. Please go to my blog to have them properly displayed (I use WordPress + Jetpack plugin to embed them).

Friday

Took us 12 hours to get there (mostly due to waiting on TXL and FRA airports) but we managed to be at party place around 19:00 on Friday. Registered, met friends and went to Kirchberg Hotel to drop bags.

Hotel has two stars but was perfectly fine for such trip as our. Clean bed, good breakfast, quiet place (except church bells at 10:00 on Sunday). All just ~2km from E-Werk where Revision took place.

Back to party, more people to meet, discuss a bit with guys from ARM Ltd about Samsung Chromebook, Cortex-A15, Mali etc. One guy joined with his Chromebook and recognized me when I asked “may I fry your speakers?” :D

Timetable listed one interesting thing: “Curio’s 2012 Essentials” which was ~1 hour long set of PC demos from previous year. It was nice as I was totally out of PC scene so was able to check how it looks.

Taxi to hotel was just 6€ ;D

Saturday

Attended “How to start writing compilers without a Ph.D” seminar as it sounded interesting to me. And it was ;) Video below:

Also had discussion with ARM guys about presenting not only technical demos (like Unreal Engine one) but also to show some demoscene productions. Soon “Beginnings” by Elude started on one of Nexus 10 tablets and was working nice. But coder who wrote it was not so happy about that when we discussed that later… I think that it would be a good thing for ARM Mali team to get some good demoscene groups to write demos for Android platform to amaze people with nice looking productions. ARM even had seminar for OpenGLES 3.0 API:

But Saturday was also full of competitions. Tracked music, oldskool music (read: 8-bit mostly), photo, animation/video, game, ascii/ansi, Amiga intros, PC 4K intros, Oldskool demos (8-bit, Atari STE, Amiga 500)…

There were many entries in compos where productions from long time no see groups/people were presented. For example in oldskool demo we got “RINK A DINK REDUX” from Lemon which was astonishing:

There were also demos for Amstrad CPC, MSX1, ZX Spectrum, Commodore 64 and other platforms. Oldskool music compo had even NES entry ;)

But it was also visible that demoscene is not full of amateurs like it was years ago. Some of videos in animation/video compo had professional level. “Lübeck 24x7x365″ took 50 days of recording but was really nice:

There was a concert in the evening… Ear plugs were not strong enough for me so I spent most of time outside talking with people. Next time need to take some better hearing protectors…

Sunday

As Saturday ended really late for us and competitions were planned for 13:00 we decided to not rush and stay in bed longer :) But at around 10:00 bells in local church started their music compo so we were not able to sleep anymore.

We got music, graphics, wild and of course PC 64K intro, web browser demo/intro, Amiga demo and PC demo competitions that day.

Graphics one was won by “Double Trouble by the Royal Forces” made by forcer & prince. Huge amount of details which was not so visible on big screen as it was on a tunnel’s wall where it was hanging as few square meters photo copy.

Wild compo… Man, that was something great. From productions made for Arduino (with some shields) though ARM Cortex-M3 one to interesting hack by Dexter/Abyss which shown one view on monochrome TV and second on oscilloscope while both were connected to Composite video signal only… See it for yourself (or grab separate entries from scene.org FTP server):

Then DJ set by h0ffman (skipped by me) and clue of party — Amiga and PC demos/intros. Different quality but most of them was really good — both from technical or design view (but not always from both at same time).

But as I am not a coder I looked mostly at design and audio/video part. All those names like ‘ray matching’ etc meant nothing to me so when someone tried to explain why demo which I did not like was so great I just told similar thing ;D

Monday

Wake up, breakfast, pack, pay, go to party place. We did not manage to get there before voting ended so not voted for PC demo compo entries. Greeted those who was still present, discussed a bit and then return trip… This time just ~9 hours but next time (if there will be such) we plan to go there by car. Less time needed.

Random stuff

I liked how party was organized — it was my first such event abroad and many people told me that Revision is the last demoscene party in old style. I really liked it. Saw many different platforms like MSX1, MSX2, C= VIC20, Amstrad CPC or Videoton…

Due to Easter time shops where closed on Sunday/Monday but it was not a problem for me as there was free coffee/tea, beer/water/orange juice was available to buy at low price (2.5€ for 0.5l beer) and there was hot food served all time (like 10:00 – midnight) also not so expensive.

Weather could be better as it was cold but at least there was no snow (which we still have here).

It was also nice to see Kiero at work as he was finishing “Machinist” Amiga demo on his x86-64 laptop with WinUAE running fullscreen. I was surprised that ASUS UL30A is capable to run it fast enough.

Amount of discussions with people is probably uncountable. Chromebook, ARM, Android, Amiga, scene were just subset of topics…

Will I go there next year? Will see…

All rights reserved © Marcin Juszkiewicz
Revision 2013 was originally posted on Marcin Juszkiewicz website