What do I do for living

Tuesday, August 12th, 2008 by Marcin Juszkiewicz

Recently my mother asked me what exactly I do for a living. As she is not type of computer person I had to create definition which would be easy to understand for normal people. And as from time to time people asks me same question here is what I told her.

When hardware vendor builds new hardware and want to sell it to end customers he cames to us to get help on software side. As my part is building whole systems rather then single applications I took her phone as example of device and told:

Your phone is able to do many things:

  • make, receive and reject calls
  • send/receive text/voice/video messages
  • make/show/send photos/videos
  • has addressbook
  • has calendar
  • has menu to choose functions etc…

Each part is handled by separate application and my job is to build them into something what hardware vendor can put on a device before shipping it to end customer.

She was happy with that explanation, even my wife told that it is nice summary of what I do for a living. Of course there are more things which I do at work, but how to tell that I am fixing badly written software or do some testing of new ways to build it…



Using Poky SDK to build software

Thursday, July 17th, 2008 by Marcin Juszkiewicz

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.

Read the rest of this entry »



Packaged staging and what it gives

Tuesday, July 1st, 2008 by Marcin Juszkiewicz

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 :)



LinkedIn and checking email addresses

Friday, May 23rd, 2008 by Marcin Juszkiewicz

Some months ago Ross Burton wrote about checking email authors on LinkedIn:

I generally thought that LinkedIn was pretty useless for people like me. I have a community of like-minded associates available via Planet Gnome and so on, so apart from collecting friends it is pretty useless.

But recently it’s been becoming quite useful. For large companies it generally appears to be company policy that contact with open source projects is done via anonymous email domains, like GMail. This obviously makes it tricky to guess where someone is from when they appear on a mailing list… but LinkedIn to the rescue. Search for a name and hey presto, their CV!

Today I got interesting mail… It was technical question about my blog post “Recent Poky changes” where I wrote about updating QEMU in Poky to handle ARMv6/v7 rootfs. Question like question — but why it came to my OpenedHand email instead of private one? This is private blog…

The interesting part was mail author. As it came from private account which does not tell me anything so I did search on the LinkedIn. Result was nice — one of PDA vendors. I wonder when they will release phone with ARMv6 processor.

Anyway I answered and decided to share answer with other people which want to run ARMv6 Linux under QEMU. So to get it done few things are needed:

  1. recent Subversion snapshot of QEMU
  2. patch for Linux kernel to enable ARMv6 for ARM Integrator PB devboard
  3. ARMv6 rootfs
  4. some time to configure kernel

All those steps can be handled with Poky (or OpenEmbedded) of course. Kernel for “qemuarm” device use properly patched kernel — just kernel config change is needed to enable ARMv6 support. To get ARMv6 rootfs you can adapt “qemuarm” machine config to use proper optimizations (”tune-arm1136jf-s.inc” instead of “tune-arm926ejs.inc”).



Speeding up BitBake builds

Monday, April 7th, 2008 by Marcin Juszkiewicz

OpenEmbedded builds usually take lot of time as not everyone has build machines with multiple CPUs (or multi-core CPUs). But how to make them faster and make better use of multiple CPU cores?

Solution is in two BitBake variables:

  1. PARALLEL_MAKE — this is passed to make so setting it to “-j X” is handy (where value of X depends on number of CPU cores)
  2. BB_NUMBER_THREADS — amount of BitBake threads used to run tasks such as do_fetch, do_configure, do_compile etc. Do not set too big value or machine will melt and you will loose control over it ;)

Which values are sane? On Core2Quad I use “-j 4″ and 16 BitBake threads. On dual core Athlon64 I use less threads (only 4) but this machine is also my desktop so I like to be able to work :) Sometimes I have two builds locally running with those settings and it is still usable.

How to check which one are good for you? Run htop on one console and builds on another. If CPU cores are busy and it does not hit swap too often then it is OK.



Poky Linux 3.1 released

Tuesday, March 4th, 2008 by Marcin Juszkiewicz

Yesterday OpenedHand team (which I am proud to be a part of) released Poky Linux 3.1 ‘pinky`.

What interesting in this version?

  • user manual with lot of things explained
  • conversion to use the sysroot mode of gcc, making cross compiling both easier and more robust.
  • conversion to use pkgconfig in sysroot mode
  • Anjuta integration with Poky’s SDK and QEMU, making cross development of applications simple
  • new machines: Compulab EM-X270, Zylonite, Freescale MX31ADS, Phytec PhyCORE-iMX31, Logic iMX31 Lite and the HTC Universal
  • standalone toolchain and SDK application developers can develop against
  • addition of new tools to the SDK such as QEMU
  • updates to recent versions of almost all packages
  • addition of NetworkManager to standard images
  • addition of a Webkit based browser
  • uClibc support

Go and get it while it is still hot ;)