Marcin Juszkiewicz

My previous post about Nokia N800 tablet emulation became one of popular ones. On LinuxTag I shown Maemo booting in QEmu and it was met with nice response from community. But the problem remained — how to boot it when config.mtd which I used was not distributable…

Yesterday I solved that part. After studying how Maemo boots and why does QEmu restarts with wrong config.mtd I grabbed that partition from my N810 and tried again. This time OS2008/Chinook booted fine :)

What is needed? Tablet needs to have “no-lifeguard-reset” flag set. IT can be done by using flasher as this is one of R&D flags. I had it set on my N810 because I did experiments with booting from internal SD card in past.

Thanks to Faheem Pervez (more widely known as) from his N800 I was able to confirm that this is all what is needed.

Next step will be updating qemu to more recent revision to get N810 emulation (which is present in HEAD) and getting Diablo booted.

UPDATE: Diablo booted on emulated N800 and N810:

Nokia N810 emulation is more useful as there is a keyboard attached so no need for use of onscreen input methods. There are some things to remember anyway:

• Alt(Gr) behave like Fn (with sticky status)
• no CapsLock (but Shift works like on N810 so no big loss)
• no numeric row — to get “5” press “Alt+t” like on N810
• some of other keys are also in weird places
• Right Shift does not work (N810 has 2 Left Shifts)

NOTE: This is QEmu HEAD — no extra patches were needed to boot Chinook on emulated N800. To boot Diablo “hw/nseries.c” file needs to be edited to change partition info (initfs is twice as big compared to Chinook).

Since Saturday I am 0x20 years old. We had small meeting with birthday cake etc. There was no candles on it because it is hard to put so many of them on small area. One friend had idea of putting 6 candles (with only one lit) but rest of company was non-IT so would not catch (there was already problem with “0x20” text on cake)…

The most of fun was with one present which I got week before by post… It had “Open 26th July” sign on it so had to wait. Inside was puzzle made from C code — really hard to solve because source looked like one of contributions to IOCCC (and later I got information from friend that it indeed was based on one of them: gavare/2004). It took some time and 3 persons to solve puzzle.

Next part was entering source into C file… As I do not know any good OCR software for Debian GNU/Linux I had to type all 35 lines by my own hands. Good that with puzzles there was a sheet of paper with md5sum for each line (I had 5 typos). Resulting source compiled out-of-box with GCC 4.3.1 (but lot of warnings). Output of application does not had any sense to me anyway… But after redirecting to file and leaving for time longer then 2 minutes it finally ended work (after 12,5 minutes). Result was PPM picture with birthday wishes :)

Some presents are really great :D Thx, Ury!

Poky Linux distribution provides SDK for quite long time. From time to time I hear persons which complain about lack of libX or libY in toolchain tarballs. But there is a solution for them — Poky SDK can be expanded with packages.

Installation

This is described in Poky Handbook already:

The meta-toolchain and meta-toolchain-sdk targets (see the images section) build tarballs which contain toolchains and libraries suitable for application development outside Poky. These unpack into the /usr/local/poky directory and contain a setup script, e.g. /usr/local/poky/eabi-glibc/arm/environment-setup which can be sourced to initialise a suitable environment. After sourcing this, the compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other useful utilities are added to the PATH. Variables to assist pkgconfig and autotools are also set so that, for example, configure can find pre-generated test results for tests which need target hardware to run.

Using the toolchain with autotool enabled packages is straightforward, just pass the appropriate host option to configure e.g. “./configure —host=arm-poky-linux-gnueabi”. For other projects it is usually a case of ensuring the cross tools are used e.g. CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld.

Extending SDK

So you want to build GTK+ based application but “configure” tells you that you miss GTK+ headers? In normal systems you would install development packages. Same is with Poky SDK, but due to fact that there are no repositories for Poky a bit more work is needed.

You will need contents of “tmp/deploy/ipk/” from other developer or from local Poky build. I have them from local build and they are stored in “/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk” directory.

Next step is editing opkg configuration file (stored in /usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/etc/opkg.conf) to add feeds locations. With my packages it looks like this:

arch all 1
arch any 6
arch noarch 11
arch arm 16
arch armv4 21
arch armv4t 26
arch armv5te 31
arch qemuarm 36
src oe-all file:/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk/all
src oe-armv5te file:/home/hrw/devel/OH/poky/trunk/build/tmp/deploy/ipk/armv5te

Now it is time to install those missing headers: opkg-target update will update list of available packages and opkg-target install gtk+-dev install required headers.

Building software

Hello world

First something really simple: helloworld.c. Run arm-poky-linux-gnueabi-gcc hello.c -o hello. Result will be ARM binary:

14:14 hrw@home:$ file hello hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped

Autoconf based application

I took Tasks 0.13 as an example as it use some libraries not present in standard toolchain. After unpacking and starting ./configure --host=arm-poky-linux-gnueabi I got message that GTK+ headers are missing so I installed them with opkg-target install gtk+-dev (like it is described).

After next “configure” call there was message about missing “libecal” which is part of “eds-dbus” so opkg-target install eds-dbus-dev solved problem.

Finally “configure” does not give any errors and make call built application:

14:19 hrw@home:tasks-0.13$ file src/gtk/tasks
src/gtk/tasks: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped

Summary

As you see Poky SDK is not limited to default set of packages but can be extended with additional ones. OK, someone needs to build them first but imagine situation when company has 10 developers — one has Poky build tree which he use to generate packages which can be used by rest of team without spending precious time on building.

BTW — It is not limited to Poky SDK. Other OpenEmbedded based systems should be more or less capable of doing such things.

Mira’s reaction — priceless…

GUADEC is going to end for me today — I am going back home tomorrow. Was it worth going here? Yes, it was. I met interesting guys, spoke about nice projects which I will probably work on soon etc.

Talks

There was lot of interesting talks during this year GUADEC:

• “Bob the Builder: How can he fix it?” by Rob Bradfort from OpenedHand — it was about Poky, developing for embedded targets, which tools are available and how to use them.
• “Clutter guts” by Tomas Frydrych, Emmanuele Bassi and Øyvind Kolås from OpenedHand. This was was about Clutter — what it is, how to use, what it gives. For me it was interesting as I did not knew what exactly it is.
• “Location-aware applications with GeoClue and Gypsy” by Henri Bergius (Nemein), Iain Holmes (OpenedHand), Jussi Kukkonen (also OH) — from clock applet which automatically change your timezone for shopping lists which reminds you about milk when you are near store. I wonder how those projects will change the way of writing applications. For those who does not know what Gypsy is — it is GPS multiplex daemon which does not have gpsd bugs.
• “Breaking the Silence: Making Applications Talk with Telepathy” by Robert McQueen from Collabora. I think it was a bit too technical but otherwise it shown what Telepathy is and how cool can it be.

I see that some of Lighting Talks can be also interesting.

Parties

O yes… parties… Monday and Tuesday were easy days — we got some Turkish coffee somewhere (it was really good) and Turkish beer (was not good) but next days were different.

On Wednesday evening there was roof party at the University. Lot of people and red wine in plastic/paper cups. Get to sleep at ~02:00…

Thursday… Collabora boat party with “unlimited” beer… That was great event. At 21 we get on board and the party started. Carlsberg is quite good beer and after 3rd can you do not notice taste :) There were few places with stronger alcohols — 15 years old whiskey for example. We went under Europe<>Asia bridges — the first one has animated lights which looks very nice. I spoke a lot with Ken Gilmer from Bug Labs company and it was good spent time. Later from party to came to “bar” near the Golden Horn hotel and from there I walked to our hotel. Final bed time: 03:30…

Today there will be Google sponsored party but I do not plan to go there. I prefer to have some time for packing and rest before traveling home (Istanbul -> Berlin -> Szczecin) and going to the party would makes me look like zombie on Saturday… And I have family event on Sunday so I should look like normal person rather :)

BTW — after boat party I thought that conference could be named GUADEP as sometimes it looks like parties takes more time and attention then conferences :D

Summary

I will not write that it was worth going to GUADEC because it is widely known fact. I met interesting people (also few not interesting ones), discussed some projects with their managers (as talking is always better then exchanging emails).

Next year should be even more interesting as it will be merged with Akademy which is KDE conference (and I use KDE3/4 rather then GNOME on my machines).

I am at GUADEC now and typing from my Dell D400 laptop. The fun part is in battery — it is more or less dead but in interesting way…

For last few minutes it say that I have 3% of battery left which will give me 1 second of work. It is quite long second :)

After all the battery has enough juice to give me about 30-40 minutes of usage (with removed everything not needed like USB, Ethernet) with WiFi enabled (on Broadcom 4306 chipset). And to avoid data loss I have all partitions mounted read-only now.

UPDATE: some more facts:

11:08 — 3% battery left, 00:00:01 remaining

11:31 — 0% battery left

12:02 — still working…

12:08 — started dd if=/dev/urandom of=/dev/null to give some work for CPU. Machine stopped working

1 hour with unknown status of battery… It was enough for reading Google Reader over WiFi.

Tickets bought, insurance bought, maps of Istanbul loaded into Maemo Mapper on N810 so I am nearly ready for GUADEC 2008. This year it will take place in Istanbul, Turkey but it is still European conference :)

Trip starts on Monday morning — bus from Szczecin to Berlin Texel, then flight (Turkish Airlines) to Istanbul. Short trip to hotel Senator and I will be ready to wait for rest of OH gang to arrive. I do not plan to get lost like I did year ago :)

List of talks to attend is generated and stored in GPE Calendar (when Maemo will get good PIM…) and this year I plan to attend most of this list. Too bad that Quim Gil talk is on Monday — I will not attend his talk. I hope that some familiar people from Maemo community will attend so we will be able to talk a bit.

But conference is not everything — I plan to take a walk though city to show something as I do not know when I will be there next time.

Ah — and I have to remember about N810 headset — GSM calls to/from Turkey are expensive so VoIP calls will be my only way to contact rather.

Many people do not realize that Poky (and OpenEmbedded .dev) have so called “packaged staging” support.

What it is?

Let me try to describe it a bit. During normal builds “tmp/staging” directory is populated during do_stage tasks and there is no way to remove staged files in other way then by hand. With “packaged staging” this area is under package management — each built recipe has those files packaged along with resulting packages, stamps and cross tools.

OK, but what it gives? Why to bother with this at all?

Those are good questions… With fast machines (like my Core2Quad for example) build of “poky-image-sato” can be done in less then 2 hours so it looks like there is no need for any speedups… But not every one has such beasts. With packaged staging developer is able to do repeatable builds in nearly no time (compared to first build) as most of recipes are not built but unpacked from previous builds.

How to use it

To make use of packaged staging “conf/local.conf” needs some editing. Basically one line (inheriting packaged staging class) is important:

INHERIT += "packaged-staging"

To be able to make builds from scratch one more change (moving directory with staging packages outside of “tmp”) is needed:

DEPLOY_DIR_PSTAGE = "${OEROOT}/build/pstage/"

After those edits we need to make first build. I suggest “poky-image-sato” target as this will give all important libraries built and packaged. Everything behave like in normal build — software is built, staged, packaged and final image is created. Bonus is in “${OEROOT}/build/pstage/” subdirectories — extra packages which will be used in any of next builds.

Lets test it

Now when we have first built done (which took few hours) we can test how much will “packaged staging” improve our build time (I assume that both edits listed above were done).

So now comes interesting part — we will remove “tmp” directory and do build from scratch. Please notice what happens — nearly nothing is built (except “stagemanager-native” which handle “packaged staging” functionality) because everything is unpacked from packages done on previous build. If any recipe got updated since last time it will be built and packaged.

End notes

As you see packaged staging can be really useful for making builds — less time is needed, results of following builds are same. And in the end developer has more time for developing :)