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.
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.
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.
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
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.
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.
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.
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.
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.
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:
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.
Few days ago Nokia N800 tablet emulation was released into public. Richard integrated it into Poky so now we have “qemu” which can be used not only to test ARM images on ARM Versatile or Sharp Zaurus but also to run on Nokia N800 tablet. Of course it is not limited to Poky images — Maemo boots very nicely on it :)
Booting Poky is easy: “runqemu nokia800″ after building of “poky-image-sato” for “nokia800″ machine. After few minutes (needed to create NAND Flash image and boot into JFFS2 rootfs) Poky desktop appears:
Basic emulation works. There is no networking yet, DSP code is not emulated and few other limitations. But it is work in progress so expect improvements.
With the latest release of Poky, “Pinky 3.1″, we are also announcing the release of our Anjuta plugin that allows integration with a cross-compiler SDK built from Poky. It integrates Anjuta with the QEMU device emulator, cross-gcc and cross-gdb. It allows a rapid hack, build, deploy, test cycle. This work was sponsored by iRex Technologies B.V. Thanks guys.
Anyway, enough talking, see the project page on the OH Laboratories site for more details. Here is a little screencast.
