Marcin Juszkiewicz

During last few days I played with CyanogenMod 10.1 nightly builds on my Nexus S phone. Then went back to CM 10 as it is more stable. But this also reminded me that I have 2 years old device…

So I did another round of checking what are options. As it will be for next 2 years I want 2GB of RAM, 720p screen and LTE support. And there is very small amount of those :(

1. HTC Butterfly. MicrosD slot, 1080p screen, Japan only so far.

2. LG Nexus 4. Latest Android for few releases granted. But also lack of microSD slot and only 16GB of storage.

3. LG Optimus G. Base of Nexus 4. Not available outside of few operators (mostly US).

4. Samsung Galaxy S3 LTE (GT-9305). MicroSD slot, MHL video output.

5. Samsung Galaxy Note II. MicroSD slot, MHL video output.

Now it is time to complain :)

LG Nexus 4 is available only in some stores (or phone operators) for 450+ € — no Google Play Store like it was with earlier models (I do not call current state as selling). Also no LTE on European frequencies. No 32GB storage model.

Samsung GT-9305 sounds interesting. But… It is Exynos 4412 based. And I read The Saga of a CyanogenMod Exynos4 device maintainer by Andrew Dodd which gives clear message “avoid Exynos4 if you can”. If even Samsung update can break your device then something is going wrong. And so far SGS3 LTE lacks CyanogenMod support which is one of main blockers for me as it shows that there are no custom “ROMs” for it (I do not count images remixed from stock images).

Galaxy Note II is huge and would take some time to get used to it. Has CM support already. But again — Exynos4 ;(

So it looks like I need to wait another few months and check will there be something worth buying. In meantime I will stay with last CM10 release running on my Nexus S.

Few people already asked me how open Samsung Chromebook is. So let’s take a look.

Kernel is open. Git tree is available and so are instructions on how to build it. You can check post by Olof Johansonn or take a look at Chromium ebuild. Remember that images need to have DeviceTree attached.

There are few firmware blobs but most of them are available in “linux-firmware” package in Ubuntu. The only exception is “mrvl/sd8797_uapsta.bin” file which is present in Marvell’s firmware repo.

You also need to sign kernels. But tools and developer keys are available as well. We have preliminary version of package for it.

X11 drivers are available as well. Both video (armsoc) and input (cmt) are open. You can run X11 just fine without them even. I provide armsoc one but decided to skip “cmt” one cause “evdev” one works ok.

So where are those ugly binary blobs? In standard places…

One is OpenGL ES support. There is “libmali.0.0.35” which works as libEGL and libGLESv2 but no source for it (kernel part is open). Also license is missing. You can copy it from Chromium (I made package for Ubuntu) but results vary. I would love to get it working cause it can make Chromium browser faster.

Other is video acceleration. Under Chromium there is set of OpenMAX libraries. Under Ubuntu I see only crashes.

Flash plugin is yet another story. Rune K. Svendsen got it partially working but it is still not like it could be.

There is also Google Hangouts plugin under Chromium. So far no information will it work under non-Chromium distribution.

If you have anything to add here then write a comment. And consider joining “Samsung Chromebook (ARM) hackers” team to help us in getting our distros working better and better.

Some time passed since my earlier post. I had to think about few things and made some decisions.

I will write an installation instruction for Samsung Chromebook users — about installing other operating system on internal storage. Targeted at advanced users but with more or less exact steps. If you do not know how to enable “developer” mode in Chromium then sorry…

And in meantime I worked on packaging. Few minutes ago I pushed kernel to my PPA and once it get built I will offer it in Chromebook hackers PPA so users will be able to use it instead of Chromium OS one. It will need signing and putting on proper partition but, like I wrote above, my packages are not only for novice level users.

Thanks to work started by Antonio Terceiro we have preliminary version of vboot utilities package. I cleaned it a bit and got to state when “cgpt” and “vbutil_kernel” are provided so playing with partitioning will not need files from Chromium OS. Will upload it into PPA as well.

Left speaker in my Chromebook died totally so I decided to spend some time on getting UCM profiles available in “quantal” and “precise” releases of Ubuntu as well. SRU process in progress…

Also got 32GB microSD card so one step closer to having other distributions running. Thinking of Debian here of course. But it is in deep freeze now so harder to get new packages there.

How can you help? Test, file bugs, attach fixes to bugs. And can also replace speaker in my Chromebook so I will not have to use headphones ;D

Lot of people asked me how I managed to fry left speaker in my Chromebook. There are also few which said that it is Ubuntu fault.

So today I used recovery to wipe out my installation of Ubuntu from device and decided to check under Chromium OS. And yes, I got nice smell of burnt plastic etc coming from left speaker area.

Why? Because it is kernel bug. Not Ubuntu, ALSA or user. Ok, it is a bit of user’s fault cause you should not have to play with ALSA mixer. But you can — all binaries are part of Chromium OS stable.

So let me give you needed steps:

1. Boot Samsung Chromebook (ARM one) to Chromium OS
2. Login or use guest session
3. Run terminal (Ctrl+Alt+t)
4. Run “alsamixer -c0”
5. Set “Lineout” to highest value
6. Unmute everything what starts with “Left” or “Right” (depends which speaker you do not like)
7. Touch speakers (but better not for long)
8. Hold “Power” button to shut down before it will burn though your desk.

In normal situation I would assume that sound driver will take care of combinations which may break your hardware. But looks like Chromebook developers did had such idea.

Is this howto useful? I think it is. Cause if you have device broken in some way and you want to get it replaced you can just run it and hope for replacement instead of repair.

And when next time someone will write me “go and fix ubuntu rather than putting blame on samsung. Its Ubuntu which is the cause” like I got in recent comment I will just ban such person from commenting.

I bought many Samsung products. There were monitors, cellphones, storage and others. But I am starting to feel that it is time to change vendor…

All because Chromebook…

Device pushed to market in a big rush with kernel allowing users to burn devices. I really do not like smell of burnt speakers and plastics. Like Dylan Reid commented my Google+ post:

I’m guessing that a path was set up from MIC1 (wired to DMIC in) to the left speaker output. Playing the digital mic input as analog at full volume seems like something that might cause speaker failure, and wouldn’t necessarily be audible while it is happening.

My device runs Ubuntu 13.04, has UCM profiles installed to get sound working on what left from speakers but if application touch ALSA in wrong way then I have to open windows to get some air and get smoke out.

I never had such problems with all devices I played with. NEVER

I do a lot of cross compilations. With different software elements. But sometimes I want to kick their authors into ass…

There is a good sign when you see $(CC) in Makefiles as it shows that author of code learnt that “gcc” is not the only compiler. But this is not the only compiler you should know about.

Recently I was adding one component (will save a name) into OpenEmbedded as this is one of dependencies for some bigger project (which I do not want to blog about). Argh… I managed to cross built it but patches are UGLY (will get better).

Using $(CC) to build everything is just broken. Especially when you need to compile a tool which will generate some code to get everything built. There is $(BUILD_CC) for it but you have to use it wisely. If there are common parts then compile them with $(BUILD_CC) if you need to run it and with $(CC) if you not. This way we, cross compilation guys, can just do “./configure;make;make install;package” is it native or cross build. Autotools (die, die, die) are able to handle that — so is your code if you write Makefiles properly.

But do not reuse same object files for target and native binaries — let it be “common.o” and “native/common.o” for example. OK, if you do only native builds then it will take a bit more disk space but we have 2012 not 1995… Storage is cheap.

There is also $(HOST_CC) but that’s for other post…

Somewhere in 2010/11 I decided to clean up mess of naming machines at home and decided to go with character names from “Winnie the Pooh” books (Polish edition). Today I got new developer board and had to spend a moment to get a name for it.

So “klapouchy” (Eyeore) will be new name for DragonBoard. Maybe not best one but most of the names are already taken:

• krzys (Christopher Robin) is my router (because Chris decides who can enter Hundred Acre Wood which is the name of my WiFi network)
• puchatek (Winnie the Pooh) is main desktop
• lumpek (Lumpy) is conference laptop (it was lucek before because it got Ubuntu Lucid as first system)
• gofer (Gopher) is Efika MX Smartbook
• krolik (Rabbit) is Samsung Chromebook
• malenstwo (Roo) is Pandaboard (there were malenstwo-a1 and malenstwo-ea1 when I had two boards)
• prosiaczek (Piglet) was MX53 Quickstart
• kangurzyca (Kanga) is my wife laptop (she chosen the name)
• sowa (Owl) is another router
• tygrysek (Tigger) is my VPS (at beginning it was up/down/up/down all the time)

So most of the names from books are already taken. There are also Disney movies which adds few new ones (like Gopher and Lumpy) and cartoons (which I am not fan of). In worst case one day I will start re-using names or add names from other story.

What I used before? Desktop was “home” or “hrw”, Dell laptop (now “kangurzyca”) was “maluch” (small) due to 12” size, “lumpek” was “lucek” due to Ubuntu Lucid installed and rest was named by hardware name (which is a default in OpenEmbedded).

How you are naming your machines?

I created a project at Launchpad to have one place to gather hackers playing with ARM based Chromebook support in their distros.

Project is named “Cross distro support for Samsung Chromebook (ARM based)” and is maintained by team named “Samsung Chromebook (ARM) hackers“. If you want to join then you need to have Launchpad account and then join the team.

Why Launchpad instead of (insert any similar place)? Because I know it and it has very good bugtracker which allows to track other bug trackers. And it does not have to have anything related with Ubuntu…

OK, most of bugs now are about Ubuntu but that’s because I added them. But take a look at bug about ALSA UCM support. It affects our project but also affected “alsa-lib” and “alsa-utils” packages in Ubuntu. There is nothing which could stop us from adding links to Debian, Fedora, OpenSUSE or other distros bug reports there.

I added PPA there which will get binary packages for “raring” (unless they got merged) and backports for “quantal” and who knows, maybe one day even for “precise”. Due to policy that repository will not be able to build for “armhf” architecture but one of my personal ones can so I will copy packages.

So, who wants to join us? We already have non-Ubuntu people in the team!