Month: November 2012

I hate CVS based repositories

During last days I spent some time in binutils, gcc, gdb, glibc, libffi repositories. All of them have GIT mirrors but most (if not all) are kept in CVS by default.

I used CVS in previous millenium just because I did not know good alternative. But I also know that move from it to other SCM can be painful.

But digging though commits because shortlog view is useless hurts… Exported patches need to be edited to drop all changes to many Changelog files. For libffi it is even better to grab patches from mailing list than from repository…

Life sucks, then you die^Whave to deal with CVS git repos.

Let’s compare some cpu ;)

When I bought Samsung Chromebook friend started “nbench” on it. So I did same on my conference laptop. None of devices won…

Idea of testing cpu power was sitting somewhere at back of my head and finally I decided to just run one simple command available on nearly every GNU/Linux based system: “openssl speed”. Sure, on some systems it will use hardware accelerators, on others (or not) some options enabled to get more speed (like ARM assembly version which is not enabled in Debian/Ubuntu systems). But it is something what anyone can run at home.

Table may be hard to decipher so I also give it as Google Docs. It also has few more devices listed and whole tables (one below is for 8192 size samples).

Devices in table are:

  • my Intel Core i7-2600K desktop
  • my Intel U7300 (ultra low voltage) conference laptop
  • Exynos5 Dual powered Samsung ARM Chromebook
  • Exynos4 Dual powered Tizen development platform (got rid of it today)
  • i.mx515 powered Efika MX Smartbook
  • Beaglebone with AM335x cpu
  • Sheevaplug (as only armv5te device which can compare with other entries)

Devices were running different versions of OpenSSL under different systems. It is listed in Google Docs document.

CPU Core i7 U7300 Exynos 5250 Exynos 4210 i.mx515 AM335x Feroceon 88FR131
Architecture x86-64 x86-64 armv7a (a15) armv7a (a9) armv7a (a8) armv7a (a8) armv5te
MHz 3400 1300 1700 1000 800 720 1200
OpenSSL version 1.0.1c 1.0.1c 1.0.1c 1.0.0f 1.0.1a 1.0.0i 1.0.0d
 
md4 1111896 393198 328471 205906 143746 103068 119367
md5 693969 249301 224040 148089 85401 53365 86518
hmac(md5) 686511 248859 225839 149153 86728 54981 87651
sha1 721528 222770 147739 71233 49525 35446 38123
rmd160 247453 93500 106935 57790 40188 26318 30803
rc4 894615 225660 153949 86829 63770 29364 45036
des cbc 73703 27191 37811 21299 14966 8601 8829
des ede3 28091 10578 14183 7806 5526 3005 3130
seed cbc 78204 31181 39002 24361 17650 11671 13087
rc2 cbc 44327 13839 23691 15494 10897 7393 10699
blowfish cbc 133455 52004 49471 37540 23536 15654 20584
cast cbc 118852 49162 55326 31738 22848 15298 20590
aes-128 cbc 127378 95955 65360 22386 16477 10876 11697
aes-192 cbc 106141 81002 55973 18653 13912 9221 9968
aes-256 cbc 90487 69148 48564 16419 12091 7981 8677
camellia-128 187958 44403 58698 15447 23325 15507 14197
camellia-192 141346 33180 45867 12090 18300 12261 11138
camellia-256 141422 33272 45927 12050 18383 12247 11131
sha256 216766 86791 64334 23427 18148 12022 13040
sha512 336729 135935 31126 8877 5321 2484 3221
whirlpool 121211 47920 27820 4602 3840 2262 3085
aes-128 ige 122085 43018 63218 22126 15590 10469 11219
aes-192 ige 102133 36107 54269 18696 13355 8904 9647
aes-256 ige 87514 31001 47636 16307 11635 7735 8433
ghash 1938609 168034 35479 12136

Most interesting columns are U7300 and Exynos 5250 ones — 3 years old laptop which I bought for conferences compared to Chromebook. Looks like for next conferences/events I will rather go with Chromebook not UL30A. This will give me one or two hours of battery life less but it is much lighter device at same time. But have to test it first for few days to check is it comfortable enough for daily use.

Does someone wants Tizen development platform device?

Half year ago I got Tizen development platform device. Played a bit with it and then put in a drawer due to other things to do.

Today I looked again at Tizen. Nothing changed. Git repositories still scream “****@#$!$ *** *** you developers!” due to lack of any commits other than code drop bombs.

So if someone (from Europe) wants this device — be first to comment. Sending with DHL and you pay for posting.

Chromebook support for Ubuntu

Today I added some Chromebook related packages into my PPA. What is there?

  • xserver-xorg-video-armsoc == accelerated Xorg video driver.
  • chromium-mali-opengles == OpenGL ES support — works as long as you have ROOT-A partition with Chromium OS cause I mount it to get Mali library.
  • libasound2 == ALSA packages with UCM profiles for Chromebook. Say “no more” to fried speakers.

No support from me as usual. I provide packages for just released Ubuntu “quantal” and for development version (“raring”).

Kernel will probably be next. There are instructions from Olof Johansson for it. Not hard task but requires some time. Also requires packaging of vboot tools (for signing kernels) and cgpt (for manipulating GPT).

Another part is touchpad snippet for X11:

Section "InputClass"
        Identifier "touchpad"
        MatchIsTouchpad "on"
EndSection

Any idea how to package it in friendly way? I thought about “meta-chromebook” package for such tweaks but it does not sound nice to me.

Video acceleration would be great. But this part is beyond me so far.

So, if you have Ubuntu running on your Chromebook (nevermind is it on internal storage or side SD or USB stick) as long as it is at least “quantal” go and grab my packages. They will make use of device much more pleasant. Share any tweaks and tips in comments.

UPDATE: There is a new project related to Chromebook support in distributions. More about it in my blog post about it.

Samsung will have big.LITTLE. So what?

Lot of services followed article on EETimes where it was announced that Samsung will present 8-core ARM cpu. What was skipped on some of them is that this is big.LITTLE design so it is made as 4xCortex-A7 + 4xCortex-A15 setup.

Good to know that there will be silicon from other vendors than ARM Ltd. Current development platform is Versatile Express TC2 (Test Chip 2) which shows that amount of A7 cores does not have to match A15 ones (it has 3xA7 + 2xA15).

But amount of cores is one thing. People usually complain about battery life and guess that such setup will suck power like crazy… when it is especially designed to save power.

Take a look at current “war” at mobile market. 2 years ago single core 1GHz Cortex-A8 cpu wit 512MB ram was high end. Then we got dual core cpu (usually Cortex-A9 based like Exynos4, OMAP4, Tegra2) and 512-1024MB of memory. Battery usually had similar capacity and lived similar time. During 2012 we saw move to quad core processors in mobile devices (Exynos4412, Tegra3) with 1-2GB ram. Space for battery was same or smaller. Next year will bring Cortex-A15 cpu (Exynos5, OMAP5, Tegra4) but this eats power…

So phones will probably get big.LITTLE processors to give users with lot of cpu power when needed and battery life otherwise. Cortex-A5/8/9/15 will not disappear from market — will land in normal and cheap devices.

I have dual core Cortex-A15 netbook now (Chromebook) and it works fast. Who knows, maybe in 2014 I will be able to replace it with something powered by 4xA7 + 4xA15 processor (unless ARMv8 will land at same time). And there is a work on getting ALL of cores running at same time…

Ubuntu cross compilers situation for 13.04 ‘raring’

As you know I am responsible for building cross compilers for Ubuntu. They targeted “armel” and “armhf”. But this will change.

During last few weeks I was slowly updating cross compiler source packages for ‘raring’ (current Ubuntu development version). Most of time was taken by conferences so it had to wait until previous week when I got first two parts (binutils/cross and arm{el,hf,64}-cross-toolchain-base) working. I found some issues in binutils, eglibc, linux, gcc-4.7 but make workarounds for them — will report bugs and work on fixes of course.

But situation is not nice. Armel was dropped from ‘raring’ which made building a bit harder (had to find a way to get “linux-libc-dev” package from “linux-source-3.7.0”). But I am more and more convinced that I should just drop “armel” cross compiler. It will make my life easier but of course patches are welcome.

Multilib support will get dropped as well. “armhf” cross compiler will not build for “armel” cause there will be no eglibc packages.

But there will be a bonus — I work also on “arm64” cross compiler.

Complaining

People told me many times that I complain a lot (maybe even too much sometimes). But this is who I am and you have to live with it.

When I get new device I usually blog about it — like I told during recent conferences: “give me a device and I will find something to complain about, but also will usually tell something positive as well”. Sometimes those posts even got presented by other people at management meetings as an example of what is good/wrong in described products.

But so far I never got an email with ask to remove any blog post — there were comments outside of blog sometimes but never request to take my opinion down. I edited two posts — first one was before publication because I sent it for review (it was not requested by company), second time when I got some information about product in public space but device had to be announced week later at big event during one of trade shows.

What do you think? Should I write more about devices or rather not?

Staying at Linaro

Week ago I got message that someone higher in chain decided that Canonical will not get me this year. Took me few days to get it fully confirmed so I can now write about it.

So for another few months I will stay at Linaro. What will be after that time? Will see — Linaro got new members, there is enterprise group now so many interesting things can happen.

Used Chromebook for few days

Some days ago I got Chromebook and have to say that device is amazing. Light, small and fast enough for conference laptop. During Linaro Connect I did some hacking on it with help from Olof Johansson and Andrew Wafaa (he brought Chromebook for me from Cambridge). I also used script from Jay Lee to get all information required to resize STATE partition and fit Ubuntu on internal storage.

Now I am running Ubuntu ‘raring’ on my Chromebook with XFCE as a desktop — all running from internal storage (16GB eMMC from SanDisk). So far I did not remove original Chromium from device as I keep it as a reference system to be able to compare what I got with how it works with system from Google.

So what works? Most of things — suspend/resume, wifi, bluetooth, sound, touchpad, usb ports, sd storage, camera. But why they should not work when I am using same kernel binary as Chromium OS does 😉 So far did not yet came to rebuilding kernel — there were more important things to do first.

During Wednesday hacking evening I updated xf86-video-armsoc driver to X11 ABI 13 used by packages in ‘raring’ so I got 2D accelerated environment. Tried to find all sources required to build xf86-input-cmt driver but then got hint from Olof that “evdev” driver is enough — all it needs is small snippet of X11 configuration. And yes — it works but is not precise. Andrew told that he will try to build “cmt” driver for OpenSUSE so we will know how better it is.

What next? I have to create package for “cgpt” (GPT manipulation tool with support for Chromium OS extensions), tools and keys needed to sign kernel and kernel itself. Then some work would be needed for OpenGLES stuff but this can wait. I plan to upload everything needed into Debian and then request syncs to Ubuntu. From yesterday’s discussions I know which mailing lists I should go.

But I do not plan to cover everything. There will be no installation support from me. Users have to do it on their own cause there are several ways of getting other operating systems on Chromebook:

  • boot from SD card
  • boot from USB storage
  • resizing STATE partition to put system on internal eMMC (I did that)
  • removing Chromium OS completely to get more space for own system

Then there are also systems when user has developer firmware installed (that’s different that developer mode) or even setup where normal U-Boot is used as bootloader.

It is hard to write job description when you are leaving

Time to do hard task — write job description for my replacement at Linaro. Or maybe not replacement but for someone who will take some or most of my duties there.

I did so many things at Linaro during last 2.5 years that it is hard to decide what such person should know. I learnt Bazaar (not hard once you know Subversion), improved Git skills and tried few projects which tried to bridge both. Learnt more about Launchpad than wanted — people at #launchpad channel are really helpful (same with #bzr ones).

There was lot of building involved. From fixing packages in Ubuntu and Debian to building with OpenEmbedded. I even did some build automation with use of Launchpad. Then there was Jenkins where we moved most of our builds.

I became MOTU in Ubuntu and got Debian Maintainer status in Debian. Have to clean some things and take “android tools” package more into shape as there are co-maintainers waiting in queue with patches. Also updated my OpenEmbedded skills to current state as last time I was using it there was no layers 😉

But how to summarise it in short job description? You will see soon at Linaro’s jobs page soon.