Poky Handbook

If you want to try Poky, you can do so in a few commands. The example below checks out the Poky source code, sets up a build environment, builds an image and then runs that image under the QEMU emulator in ARM system emulation mode:

$ wget http://pokylinux.org/releases/pinky-3.1.tar.gz
$ tar zxvf pinky-3.1.tar.gz
$ cd pinky-3.1/
$ source poky-init-build-env
$ bitbake poky-image-sato
$ runqemu qemuarm

To build for other machines see the MACHINE variable in build/conf/local.conf which also contains other configuration information. The images/kernels built by Poky are placed in the tmp/deploy/images directory.

You could also run "poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2" within the images directory if you have the poky-scripts Debian package installed from debian.o-hand.com. This allows the QEMU images to be used standalone outside the Poky build environment.

To setup networking within QEMU see the QEMU/USB networking with IP masquerading section.

Prebuilt images from Poky are also available if you just want to run the system under QEMU. To use these you need to:

Periodically, we make releases of Poky and these are available at http://pokylinux.org/releases/. These are more stable and tested than the nightly development images.

We make nightly builds of Poky for testing purposes and to make the latest developments available. The output from these builds is available at http://pokylinux.org/autobuild/ where the numbers represent the svn revision the builds were made from.

Automated builds are available for "standard" Poky and for Poky SDKs and toolchains as well as any testing versions we might have such as poky-bleeding. The toolchains can be used either as external standalone toolchains or can be combined with Poky as a prebuilt toolchain to reduce build time. Using the external toolchains is simply a case of untarring the tarball into the root of your system (it only creates files in /usr/local/poky) and then enabling the option in local.conf.

Poky is available from our SVN repository located at http://svn.o-hand.com/repos/poky/trunk; a web interface to the repository can be accessed at http://svn.o-hand.com/view/poky/.

'trunk' is where the deveopment work takes place and you should use this if you're after to work with the latest cutting edge developments. It is possible trunk can suffer temporary periods of instability while new features are developed and if this is undesireable we recommend using one of the release branches.

Bitbake is the tool at the heart of Poky and is responsible for parsing the metadata, generating a list of tasks from it and then executing them. To see a list of the options it supports look at bitbake --help.

The most common usage is bitbake packagename where packagename is the name of the package you wish to build (from now on called the target). This often equates to the first part of a .bb filename, so to run the matchbox-desktop_1.2.3.bb file, you might type bitbake matchbox-desktop. Several different versions of matchbox-desktop might exist and bitbake will choose the one selected by the distribution configuration (more details about how bitbake chooses between different versions and providers is available in the 'Preferences and Providers' section). Bitbake will also try to execute any dependent tasks first so before building matchbox-desktop it would build a cross compiler and glibc if not already built.

The .bb files are usually referred to as 'recipes'. In general, a recipe contains information about a single piece of software such as where to download the source, any patches that are needed, any special configuration options, how to compile the source files and how to package the compiled output.

'package' can also used to describe recipes but since the same word is used for the packaged output from Poky (i.e. .ipk or .deb files), this document will avoid it.

Class (.bbclass) files contain information which is useful to share between metadata files. An example is the autotools class which contains the common settings that any application using autotools would use. The classes reference section gives details on common classes and how to use them.

The configuration (.conf) files define various configuration variables which govern what Poky does. These are split into several areas, such as machine configuration options, distribution configuration options, compiler tuning options, general common configuration and user configuration (local.conf).

Devices commonly have USB connectivity. To connect to the usbnet interface, on the host machine run:

modprobe usbnet
ifconfig usb0 192.168.0.200
route add 192.168.0.202 usb0 

On Ubuntu, Debian or similar distributions you can have the network automatically configured. You can also enable masquerading between the QEMU system and the rest of your network. To do this you need to edit /etc/network/interfaces to include:

allow-hotplug tap0
iface tap0 inet static
        address 192.168.7.200
        netmask 255.255.255.0
        network 192.168.7.0
        post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -P FORWARD ACCEPT

This ensures the tap0 interface will be up everytime you run QEMU and it will have network/internet access.

Under emulation there are two steps to configure for internet access via tap0. The first step is to configure routing:

route add default gw 192.168.7.200 tap0

The second is to configure name resolution which is configured in the /etc/resolv.conf file. The simplest solution is to copy it's content from the host machine.

USB connections to devices can be setup and automated in a similar way. First add the following to /etc/network/interfaces:

allow-hotplug usb0
iface usb0 inet static
        address 192.168.0.200
        netmask 255.255.255.0
        network 192.168.0.0
        post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -P FORWARD ACCEPT

and then to configure routing on the device you would use:

route add default gw 192.168.0.202 usb0

The log file for shell tasks is available in ${WORKDIR}/temp/log.do_taskname.pid. For the compile task of busybox 1.01 on the ARM spitz machine, this might be tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234 for example. To see what bitbake ran to generate that log, look at the run.do_taskname.pid file in the same directory.

The output from python tasks is sent directly to the console at present.

Any given package consists of a set of tasks, in most cases the series is fetch, unpack, patch, configure, compile, install, package, package_write and build. The default task is "build" and any tasks this depends on are built first hence the standard bitbake behaviour. There are some tasks such as devshell which are not part of the default build chain. If you wish to run such a task you can use the "-c" option to bitbake e.g. bitbake matchbox-desktop -c devshell.

If you wish to rerun a task you can use the force option "-f". A typical usage session might look like:

% bitbake matchbox-desktop
[change some source in the WORKDIR for example]
% bitbake matchbox-desktop -c compile -f
% bitbake matchbox-desktop

which would build matchbox-desktop, then recompile it. The final command reruns all tasks after the compile (basically the packaging tasks) since bitbake will notice the the compile has been rerun and hence the other tasks also need to run again.

You can view a list of tasks in a given package by running the listtasks task e.g. bitbake matchbox-desktop -c listtasks.

Sometimes it can be hard to see why bitbake wants to build some other packages before a given package you've specified. bitbake -g targetname will create depends.dot and task-depends.dot files in the current directory. They show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

Debug output from bitbake can be seen with the "-D" option. The debug output gives more information about what bitbake is doing and/or why. Each -D option increases the logging level, the most common usage being "-DDD".

The output from bitbake -DDD -v targetname can reveal why a certain version of a package might be chosen, why bitbake picked a certain provider or help in other situations where bitbake does something you're not expecting.

If you really want to build a specific .bb file, you can use the form bitbake -b somepath/somefile.bb. Note that this will not check the dependencies so this option should only be used when you know its dependencies already exist. You can specify fragments of the filename and bitbake will see if it can find a unique match.

The "-e" option will dump the resulting environment for either the configuration (no package specified) or for a specific package when specified with the "-b" option.

To build an application from a single file stored locally requires a recipe which has the file listed in the SRC_URI variable. In addition the do_compile and do_install tasks need to be manually written. The S variable defines the directory containing the source code which in this case is set equal to WORKDIR, the directory BitBake uses for the build.

DESCRIPTION = "Simple helloworld application"
SECTION = "examples"
LICENSE = "MIT"

SRC_URI = "file://helloworld.c"

S = "${WORKDIR}"

do_compile() {
	${CC} helloworld.c -o helloworld
}

do_install() {
	install -d ${D}${bindir}
	install -m 0755 helloworld ${D}${bindir}
}
            

As a result of the build process "helloworld" and "helloworld-dbg" packages will be built.

Applications which use autotools (autoconf, automake) require a recipe which has a source archive listed in SRC_URI and inherit autotools to instruct BitBake to use the autotools.bbclass which has definitions of all the steps needed to build an autotooled application. The result of the build will be automatically packaged and if the application uses NLS to localise then packages with locale information will be generated (one package per language).

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv2"

SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2"

inherit autotools
            

Applications which use GNU make require a recipe which has the source archive listed in SRC_URI. Adding a do_compile step is not needed as by default BitBake will start the "make" command to compile the application. If there is a need for additional options to make then they should be stored in the EXTRA_OEMAKE variable - BitBake will pass them into the GNU make invocation. A do_install task is required - otherwise BitBake will run an empty do_install task by default.

Some applications may require extra parameters to be passed to the compiler, for example an additional header path. This can be done buy adding to the CFLAGS variable, as in the example below.

DESCRIPTION = "Tools for managing memory technology devices."
SECTION = "base"
DEPENDS = "zlib"
HOMEPAGE = "http://www.linux-mtd.infradead.org/"
LICENSE = "GPLv2"

SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz"

CFLAGS_prepend = "-I ${S}/include "

do_install() {
	oe_runmake install DESTDIR=${D}
}
            

The variables PACKAGES and FILES are used to split an application into multiple packages.

Below the "libXpm" recipe is used as an example. By default the "libXpm" recipe generates one package which contains the library and also a few binaries. The recipe can be adapted to split the binaries into separate packages.

require xorg-lib-common.inc

DESCRIPTION = "X11 Pixmap library"
LICENSE = "X-BSD"
DEPENDS += "libxext"
PE = "1"

XORG_PN = "libXpm"

PACKAGES =+ "sxpm cxpm"
FILES_cxpm = "${bindir}/cxpm"
FILES_sxpm = "${bindir}/sxpm"
            

In this example we want to ship the "sxpm" and "cxpm" binaries in separate packages. Since "bindir" would be packaged into the main PN package as standard we prepend the PACKAGES variable so additional package names are added to the start of list. The extra FILES_* variables then contain information to specify which files and directories goes into which package.

To add a post-installation script to a package, add a pkg_postinst_PACKAGENAME() function to the .bb file where PACKAGENAME is the name of the package to attach the postinst script to. A post-installation function has the following structure:

pkg_postinst_PACKAGENAME () {
#!/bin/sh -e
# Commands to carry out
}
            

The script defined in the post installation function gets called when the rootfs is made. If the script succeeds, the package is marked as installed. If the script fails, the package is marked as unpacked and the script will be executed again on the first boot of the image.

Sometimes it is necessary that the execution of a post-installation script is delayed until the first boot, because the script needs to be executed the device itself. To delay script execution until boot time, the post-installation function should have the following structure:

pkg_postinst_PACKAGENAME () {
#!/bin/sh -e
if [ x"$D" = "x" ]; then
# Actions to carry out on the device go here
else
exit 1
fi
}
            

The structure above delays execution until first boot because the D variable points to the 'image' directory when the rootfs is being made at build time but is unset when executed on the first boot.

One way to get additional software into an image is by creating a custom image. The recipe will contain two lines:

IMAGE_INSTALL = "task-poky-x11-base package1 package2"

inherit poky-image
            

By creating a custom image, a developer has total control over the contents of the image. It is important use the correct names of packages in the IMAGE_INSTALL variable. The names must be in the OpenEmbedded notation instead of Debian notation, for example "glibc-dev" instead of "libc6-dev" etc.

The other method of creating a new image is by modifying an existing image. For example if a developer wants to add "strace" into "poky-image-sato" the following recipe can be used:

require poky-image-sato.bb

IMAGE_INSTALL += "strace"
            

For for complex custom images, the best approach is to create a custom task package which is them used to build the image (or images). A good example of a tasks package is meta/packages/tasks/task-poky.bb . The PACKAGES variable lists the task packages to build (along with the complimentary -dbg and -dev packages). For each package added, RDEPENDS and RRECOMMENDS entries can then be added each containing a list of packages the parent task package should contain. An example would be:

DESCRIPTION = "My Custom Tasks"

PACKAGES = "\
    task-custom-apps \
    task-custom-apps-dbg \
    task-custom-apps-dev \
    task-custom-tools \
    task-custom-tools-dbg \
    task-custom-tools-dev \
    "

RDEPENDS_task-custom-apps = "\
    dropbear \
    portmap \
    psplash"

RDEPENDS_task-custom-tools = "\
    oprofile \
    oprofileui-server \
    lttng-control \
    lttng-viewer"

RRECOMMENDS_task-custom-tools = "\
    kernel-module-oprofile"

In this example, two tasks packages are created, task-custom-apps and task-custom-tools with the dependencies and recommended package dependencies listed. To build an image using these task packages, you would then add "task-custom-apps" and/or "task-custom-tools" to IMAGE_INSTALL or other forms of image dependencies as described in other areas of this section.

Ultimately users may want to add extra image "features" as used by Poky with the IMAGE_FEATURES variable. To create these, the best reference is meta/classes/poky-image.bbclass which illustrates how poky achieves this. In summary, the file looks at the contents of the IMAGE_FEATURES variable and based on this generates the IMAGE_INSTALL variable automatically. Extra features can be added by extending the class or creating a custom class for use with specialised image .bb files.

It is possible to customise image contents by abusing variables used by distribution maintainers in local.conf. This method only allows the addition of packages and is not recommended.

To add an "strace" package into the image the following is added to local.conf:

DISTRO_EXTRA_RDEPENDS += "strace"
            

However, since the DISTRO_EXTRA_RDEPENDS variable is for distribution maintainers this method does not make adding packages as simple as a custom .bb file. Using this method, a few packages will need to be recreated and the the image built.

bitbake -cclean task-boot task-base task-poky
bitbake poky-image-sato
            

Cleaning task-* packages is required because they use the DISTRO_EXTRA_RDEPENDS variable. There is no need to build them by hand as Poky images depend on the packages they contain so dependencies will be built automatically. For this reason we don't use the "rebuild" task in this case since "rebuild" does not care about dependencies - it only rebuilds the specified package.

A .conf file needs to be added to conf/machine/ with details of the device being added. The name of the file determines the name Poky will use to reference this machine.

The most important variables to set in this file are TARGET_ARCH (e.g. "arm"), PREFERRED_PROVIDER_virtual/kernel (see below) and MACHINE_FEATURES (e.g. "kernel26 apm screen wifi"). Other variables like SERIAL_CONSOLE (e.g. "115200 ttyS0"), KERNEL_IMAGETYPE (e.g. "zImage") and IMAGE_FSTYPES (e.g. "tar.gz jffs2") might also be needed. Full details on what these variables do and the meaning of their contents is available through the links.

Poky needs to be able to build a kernel for the machine. You need to either create a new kernel recipe for this machine or extend an existing recipe. There are plenty of kernel examples in the packages/linux directory which can be used as references.

If creating a new recipe the "normal" recipe writing rules apply for setting up a SRC_URI including any patches and setting S to point at the source code. You will need to create a configure task which configures the unpacked kernel with a defconfig be that through a "make defconfig" command or more usually though copying in a suitable defconfig and running "make oldconfig". By making use of "inherit kernel" and also maybe some of the linux-*.inc files, most other functionality is centralised and the the defaults of the class normally work well.

If extending an existing kernel it is usually a case of adding a suitable defconfig file in a location similar to that used by other machine's defconfig files in a given kernel, possibly listing it in the SRC_URI and adding the machine to the expression in COMPATIBLE_MACHINES .

A formfactor configuration file provides information about the target hardware on which Poky is running, and that Poky cannot obtain from other sources such as the kernel. Some examples of information contained in a formfactor configuration file include framebuffer orientation, whether or not the system has a keyboard, the positioning of the keyboard in relation to the screen, and screen resolution.

Sane defaults should be used in most cases, but if customisation is necessary you need to create a machconfig file under meta/packages/formfactor/files/MACHINENAME/ where MACHINENAME is the name for which this infomation applies. For information about the settings available and the defaults, please see meta/packages/formfactor/files/config.

Often, people want to extend Poky either through adding packages or overriding files contained within Poky to add their own functionality. Bitbake has a powerful mechanism called collections which provide a way to handle this which is fully supported and actively encouraged within Poky.

In the standard tree, meta-extras is an example of how you can do this. As standard the data in meta-extras is not used on a Poky build but local.conf.sample shows how to enable it:

BBFILES := "${OEROOT}/meta/packages/*/*.bb ${OEROOT}/meta-extras/packages/*/*.bb"
BBFILE_COLLECTIONS = "normal extras"
BBFILE_PATTERN_normal = "^${OEROOT}/meta/"
BBFILE_PATTERN_extras = "^${OEROOT}/meta-extras/"
BBFILE_PRIORITY_normal = "5"
BBFILE_PRIORITY_extras = "5"

As can be seen, the extra recipes are added to BBFILES. The BBFILE_COLLECTIONS variable is then set to contain a list of collection names. The BBFILE_PATTERN variables are regular expressions used to match files from BBFILES into a particular collection in this case by using the base pathname. The BBFILE_PRIORITY variable then assigns the different priorities to the files in different collections. This is useful in situations where the same package might appear in both repositories and allows you to choose which collection should 'win'.

This works well for recipes. For bbclasses and configuration files, you can use the BBPATH environment variable. In this case, the first file with the matching name found in BBPATH is the one that is used, just like the PATH variable for binaries.

Modifications to Poky are often managed under some kind of source revision control system. The policy for committing to such systems is important as some simple policy can significantly improve usability. The tips below are based on the policy that OpenedHand uses for commits to Poky.

It helps to use a consistent style for commit messages when committing changes. We've found a style where the first line of a commit message summarises the change and starts with the name of any package affected work well. Not all changes are to specific packages so the prefix could also be a machine name or class name instead. If a change needs a longer description this should follow the summary.

Any commit should be self contained in that it should leave the metadata in a consistent state, buildable before and after the commit. This helps ensure the autobuilder test results are valid but is good practice regardless.

If a committed change will result in changing the package output then the value of the PR variable needs to be increased (commonly referred to as 'bumped') as part of that commit. Only integer values are used and PR = "r0" should not be added into new recipes as this is default value. When upgrading the version of a package (PV), the PR variable should be removed.

The aim is that the package version will only ever increase. If for some reason PV will change and but not increase, the PE (Package Epoch) can be increased (it defaults to '0'). The version numbers aim to follow the Debian Version Field Policy Guidelines which define how versions are compared and hence what "increasing" means.

There are two reasons for doing this, the first is to ensure that when a developer updates and rebuilds, they get all the changes to the repository and don't have to remember to rebuild any sections. The second is to ensure that target users are able to upgrade their devices via their package manager such as with the ipkg update;ipkg upgrade commands (or similar for dpkg/apt or rpm based systems). The aim is to ensure Poky has upgradable packages in all cases.

By default Poky uses quilt to manage patches in do_patch task. It is a powerful tool which can be used to track all modifications done to package sources.

Before modifying source code it is important to notify quilt so it will track changes into new patch file:

quilt new NAME-OF-PATCH.patch
                

Then add all files which will be modified into that patch:

quilt add file1 file2 file3
                

Now start editing. At the end quilt needs to be used to generate final patch which will contain all modifications:

quilt refresh
                

The resulting patch file can be found in the patches/ subdirectory of the source (S) directory. For future builds it should be copied into Poky metadata and added into SRC_URI of a recipe:

SRC_URI += "file://NAME-OF-PATCH.patch;patch=1"
                

This also requires a bump of PR value in the same recipe as we changed resulting packages.

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.

An Anjuta IDE plugin exists to make developing software within the Poky framework easier for the application developer. It presents a graphical IDE from which the developer can cross compile an application then deploy and execute the output in a QEMU emulation session. It also supports cross debugging and profiling.

To use the plugin, a toolchain and SDK built by Poky is required along with Anjuta and the Anjuta plugin. The Poky Anjuta plugin is available from the OpenedHand SVN repository located at http://svn.o-hand.com/repos/anjuta-poky/trunk/anjuta-plugin-sdk/; a web interface to the repository can be accessed at http://svn.o-hand.com/view/anjuta-poky/. See the README file contained in the project for more information about the dependencies and how to get them along with details of the prebuilt packages.

Running Poky QEMU images is covered in the Running an Image section.

Poky's QEMU images contain a complete native toolchain. This means that applications can be developed within QEMU in the same was as a normal system. Using qemux86 on an x86 machine is fast since the guest and host architectures match, qemuarm is slower but gives faithful emulation of ARM specific issues. To speed things up these images support using distcc to call a cross-compiler outside the emulated system too. If runqemu was used to start QEMU, and distccd is present on the host system, any bitbake cross compiling toolchain available from the build system will automatically be used from within qemu simply by calling distcc (export CC="distcc" can be set in the enviroment). Alterntatively, if a suitable SDK/toolchain is present in /usr/local/poky it will also automatically be used.

There are several options for connecting into the emulated system. QEMU provides a framebuffer interface which has standard consoles available. There is also a serial connection available which has a console to the system running on it and IP networking as standard. The images have a dropbear ssh server running with the root password disabled allowing standard ssh and scp commands to work. The images also contain an NFS server exporting the guest's root filesystem allowing that to be made available to the host.

If you have a system that matches the architecture of the Poky machine you're using, such as qemux86, you can run binaries directly from the image on the host system using a chroot combined with tools like Xephyr.

Poky has some scripts to make using its qemux86 images within a chroot easier. To use these you need to install the poky-scripts package or otherwise obtain the poky-chroot-setup and poky-chroot-run scripts. You also need Xephyr and chrootuid binaries available. To initialize a system use the setup script:

# poky-chroot-setup <qemux86-rootfs.tgz> <target-directory>

which will unpack the specified qemux86 rootfs tarball into the target-directory. You can then start the system with:

# poky-chroot-run <target-directory> <command>

where the target-directory is the place the rootfs was unpacked to and command is an optional command to run. If no command is specified, the system will drop you within a bash shell. A Xephyr window will be displayed containing the emulated system and you may be asked for a password since some of the commands used for bind mounting directories need to be run using sudo.

There are limits as to how far the the realism of the chroot environment extends. It is useful for simple development work or quick tests but full system emulation with QEMU offers a much more realistic environment for more complex development tasks. Note that chroot support within Poky is still experimental.

Working directly in Poky is a fast and effective development technique. The idea is that you can directly edit files in WORKDIR or the source directory S and then force specific tasks to rerun in order to test the changes. An example session working on the matchbox-desktop package might look like this:

$ bitbake matchbox-desktop
$ sh
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
$ cd matchbox-desktop-2
$ vi src/main.c
$ exit
$ bitbake matchbox-desktop -c compile -f
$ bitbake matchbox-desktop

Here, we build the package, change into the work directory for the package, change a file, then recompile the package. Instead of using sh like this, you can also use two different terminals. The risk with working like this is that a command like unpack could wipe out the changes you've made to the work directory so you need to work carefully.

It is useful when making changes directly to the work directory files to do so using quilt as detailed in the modifying packages with quilt section. The resulting patches can be copied into the recipe directory and used directly in the SRC_URI.

For a review of the skills used in this section see Sections 2.1.1 and 2.4.2.

When debugging certain commands or even to just edit packages, the 'devshell' can be a useful tool. To start it you run a command like:

$ bitbake matchbox-desktop -c devshell

which will open a terminal with a shell prompt within the Poky environment. This means PATH is setup to include the cross toolchain, the pkgconfig variables are setup to find the right .pc files, configure will be able to find the Poky site files etc. Within this environment, you can run configure or compile command as if they were being run by Poky itself. You are also changed into the source (S) directory automatically. When finished with the shell just exit it or close the terminal window.

The default shell used by devshell is the gnome-terminal. Other forms of terminal can also be used by setting the TERMCMD and TERMCMDRUN variables in local.conf. For examples of the other options available, see meta/conf/bitbake.conf. An external shell is launched rather than opening directly into the original terminal window to make interaction with bitbakes multiple threads easier and also allow a client/server split of bitbake in the future (devshell will still work over X11 forwarding or similar).

It is worth remembering that inside devshell you need to use the full compiler name such as arm-poky-linux-gnueabi-gcc instead of just gcc and the same applies to other applications from gcc, bintuils, libtool etc. Poky will have setup environmental variables such as CC to assist applications, such as make, find the correct tools.

If you're working on a recipe which pulls from an external SCM it is possible to have Poky notice new changes added to the SCM and then build the latest version. This only works for SCMs where its possible to get a sensible revision number for changes. Currently it works for svn, git and bzr repositories.

To enable this behaviour it is simply a case of adding SRCREV_pn- PN = "${AUTOREV}" to local.conf where PN is the name of the package for which you want to enable automatic source revision updating.

First, make sure gdbserver is installed on the target. If not, install the gdbserver package (which needs the libthread-db1 package).

To launch GDBSERVER on the target and make it ready to "debug" a program located at /path/to/inferior, connect to the target and launch:

$ gdbserver localhost:2345 /path/to/inferior

After that, gdbserver should be listening on port 2345 for debugging commands coming from a remote GDB process running on the host computer. Communication between the GDBSERVER and the host GDB will be done using TCP. To use other communication protocols please refer to the GDBSERVER documentation.

Running GDB on the host computer takes a number of stages, described in the following sections.

bitbake gdb-cross

tmp/cross/bin/<target-abi>-gdb 

tmp/staging/i686-linux/usr/bin/ipkg-cl -f \
tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/ipkg.conf -o \
tmp/rootfs/ update

tmp/staging/i686-linux/usr/bin/ipkg-cl -f \
tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/ipkg.conf \
-o tmp/rootfs install foo

tmp/staging/i686-linux/usr/bin/ipkg-cl -f \
tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/ipkg.conf \
-o tmp/rootfs install foo-dbg

<target-abi>-gdb rootfs/usr/bin/foo

set solib-absolute-prefix /path/to/tmp/rootfs

target remote remote-target-ip-address:2345

break main

continue

All the profiling work can be performed on the target device. A simple OProfile session might look like:

# opcontrol --reset
# opcontrol --start --separate=lib --no-vmlinux -c 5
[do whatever is being profiled]
# opcontrol --stop
$ opreport -cl

Here, the reset command clears any previously profiled data, OProfile is then started. The options used to start OProfile mean dynamic library data is kept separately per application, kernel profiling is disabled and callgraphing is enabled up to 5 levels deep. To profile the kernel, you would specify the --vmlinux=/path/to/vmlinux option (the vmlinux file is usually in /boot/ in Poky and must match the running kernel). The profile is then stopped and the results viewed with opreport with options to see the separate library symbols and callgraph information.

Callgraphing means OProfile not only logs infomation about which functions time is being spent in but also which functions called those functions (their parents) and which functions that function calls (its children). The higher the callgraphing depth, the more accurate the results but this also increased the loging overhead so it should be used with caution. On ARM, binaries need to have the frame pointer enabled for callgraphing to work (compile with the gcc option -fno-omit-framepointer).

For more information on using OProfile please see the OProfile online documentation at http://oprofile.sourceforge.net/docs/.

A graphical user interface for OProfile is also available. You can either use prebuilt Debian packages from the OpenedHand repository or download and build from svn at http://svn.o-hand.com/repos/oprofileui/trunk/. If the "tools-profile" image feature is selected, all necessary binaries are installed onto the target device for OProfileUI interaction.

In order to convert the data in the sample format from the target to the host the opimport program is needed. This is not included in standard Debian OProfile packages but an OProfile package with this addition is also available from the OpenedHand repository. We recommend using OProfile 0.9.3 or greater. Other patches to OProfile may be needed for recent OProfileUI features, but Poky usually includes all needed patches on the target device. Please see the OProfileUI README for up to date information, and the OProfileUI website for more information on the OProfileUI project.

# opcontrol --reset
# opcontrol --start --separate=lib --no-vmlinux -c 5
[do whatever is being profiled]
# opcontrol --stop
# oparchive -o my_archive