The recent Moblin beta release brings a new environment to developers
and there are many people in the community who want to experiment with
this. The official way of building Moblin is targeted along the
traditional desktop distribution approach which fits the needs of
vendors who make up a large share of the user base, but especially in
more embedded environments in the past OpenEmbedded style systems such
as Poky are popular.

With this in mind we’re pleased to announce the availability of metadata
to build Moblin compliant images using the Poky build system and
platform development tool.

The metadata has been checked into Poky and is available for people to
start experimenting with as they wish. This allows developers the
potential to create and customise their images in a controlled and
sustainable way suited to community members and the embedded space.
Users can also benefit from Poky’s continually integration development
model.

The following commands are all that is needed to make a checkout and
build a Poky Linux image that is Moblin compliant:

 $ git clone git://git.pokylinux.org/poky.git
  $ cd poky
  $ source poky-init-build-env

conf/local.conf will be created with default settings, please check
these and adjust as needed. You will need to set DISTRO=moblin and
MACHINE=netbook. You can then run

 $ bitbake moblin-image-netbook-live

and after the build completes an image will be generated in
tmp/deploy/images/moblin-image-netbook-live-netbook.hddimg which can be
transfered onto a USB memory card using dd and then live booted on a
netbook class machine.

This assumes the needed prerequisites are installed but if not, Poky
will tell you which packages are missing. More information about Poky is
available on its website, http://www.pokylinux.org/. There is this
mailing list for further discussion and the Poky bugzilla where problems
can be reported. Bug reports on Poky derived packages should initially
go to the Poky bugzilla, not the Moblin one.

Note that Poky is *not* a replacement for the main Moblin distribution,
it is a complement to it. Its intended there will be differences which
currently include:

• Use of the light weight package manager opkg instead of yum+rpm. This underlines packages from one system are not intended to work with the other at least at this time. apt+deb can also be selected.
• Uses latest git revisions of the Moblin UI packages - these are under
  active development so some issues can arise due to normal development
  flux. There is a known to be reasonable set of locked down versions
  and the option of letting the system use the changes direct from the
  SCM.
• Single user with no traditional display manager
• busybox style filesystem utilities for efficient disk footprint
  (although traditional utilities can be swapped in if desired)
• the system is built using a cross compiler in sysroot mode. This
  means root privileges are not required to run builds, normal user
  development tools are available and a 64 bit host system can build
  for the 32 bit netbook targets.

It is intended for Poky to be a more experimental platform with
innovation and experimentation being encouraged.

For more information please see the Poky webpage about this at
http://pokylinux.org/moblin/ and the rest of the Poky website and
manual.

We’re pleased to announce that Poky will be using GIT as its SCM from now on.

The advantages of GIT for a project like Poky are large due to its powerful branch handling capabilities and distributed nature meaning access to one central repository is no longer needed. The SVN history has been imported and retained and the svn server will mirror the git server for at least the short term whilst people transition.

You can browse the repository at http://git.pokylinux.org and checkout Poky using git with the command “git clone git://git.pokylinux.org/poky.git”.

Although there was no official Poky talk at OSCON, Poky featured in Jenny Minor’s talk ‘Handwave to Hardware: A Product Story Bit by Bit’ about the Vernier LabQuest, and also on the BUG that Ken Gilmer was showing off. In the video below Ken is being interviewed by Shaun Powers of Linux Journal about the BUG and Poky.

Great to see Poky pop up and generate interest at such a large event!

Having evaluated various options the people at Bug Labs, makers of the BUG have decided to switch to using Poky as their build system and development tool. You can read more on their blog.

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

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

I took Tasks 0.13 as an example of autoconf based application 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.

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

Poky 3.1.1 has been released. This version is a maintenance release which fixes:

• a problem with the source mirror URL and certain URLs
• some upstream source URLs which changed
• a missing recipe dependency
• a problem when cdaudio was installed on the build system

You can download a tarball of this release from here.

Ross has made a new release of the Anjuta Poky integration. In his blog post he also includes an excellent short tutorial on using the plugin.

As usual packages are available from debian.o-hand.com or you can grab the source.

This release includes numerous fixes as well as some new features including support for using an external device (rather than QEMU) for deployment and also using a full Poky tree rather than the just an SDK toolchain.

With the “Blinky” 3.1 release we included support for several i.MX31 platforms, notably the LogicPD LiteKit and the full-blown, consume all your desk space, Freescale ADS platform. We also included ‘experimental’ support for the Phytec phyCore-i.MX31 board, unfortunately due to problems with the kernel port the touchscreen driver did not function correctly. This has since been resolved and updated kernels and root filesystems are being included in the nightly builds.

OpenedHand (the commercial developer and supporter of Poky) have an open position for a fulltime OpenEmbedded / Poky developer, as well as other open positions for developers and designers. Check it all out at the OpenedHand employment page.