To customise the build you have to get a working knowledge of how the build works. Watch the steps, read the OpenEmbedded documentation. New page seems to be here: OpenEmbedded Getting Started. This page contains specific information about the OpenSlug build - not about bitbake or OE!

Anything else you want to do involves at the very least editing conf/local.conf or adding something (a new .bb file maybe) to the source tree. Some OpenSlug specific examples follow. If you haven't read the OpenEmbedded getting started page now is the time.

If you have built OpenSlug from the source tarball or from the nslu2-linux monotone archive the underlying build process is the same. It is based on bitbake and uses OpenEmbedded.

To customise the build you have to get a working knowledge of how the build works. Watch the steps, read the OpenEmbedded documentation. This page contains specific information about the OpenSlug build - not about bitbake or OE!

Anything else you want to do involves at the very least editing conf/local.conf or adding something (a new .bb file maybe) to the source tree. Some OpenSlug specific examples follow. If you haven't read the OpenEmbedded getting started page now is the time.

Out of date file locations

It appears some filenames have changed between when these instructions were created and the latest (2.7 beta) OpenSlug release. In particular the conf file locations don't quite match up. I'm new here so I'm going to put a mapping here of where I think things are found, and maybe finish things up later once I've got my slug working. -Zhyla

• conf/local.conf -> ???
• conf/bitbake.conf -> openembedded/conf/bitbake.conf or bitbake/conf/bitbake.conf (which gets used?)
• conf/machine/nslu2.conf -> openembedded/conf/machine/nslu2.conf
• packages/distro/openslug.conf -> openembedded/conf/distro/openslug.conf
• packages/meta/openslug-image.bb -> openembedded/packages/meta/openslug-image.bb

1. You set your environment up for the build - setup-env - this sets BBPATH. It is very important that this is correct because it controls the search path for the files bitbake reads.

Customising the OpenSlug build

If you have built OpenSlug from the source tarball or from the nslu2-linux monotone archive the underlying build process is the same. It is based on bitbake and uses OpenEmbedded.

To customise the build you have to get a working knowledge of how the build works. Watch the steps, read the OpenEmbedded documentation. This page contains specific information about the OpenSlug build - not about bitbake or OE!

Places to look, tricks and traps

1. Always source setup-env (watch the build, look at the openslug Makefile).
2. conf/local.conf is your friend. Most customisation can be done in here.
3. packages/distro/openslug.conf has comments. Read them.
4. packages/meta/openslug-image.bb is the route to a customised flash image. Are you absolutely sure you want to do that?

A quick overview

The build steps are roughly as follows:

1. You set your environment up for the build - seup-env - this sets BBPATH. It is very important that this is correct because it controls the search path for the files bitbake reads.
2. You run bitbake to build something (for example bitbake openslug-image).
3. bitbake reads conf/bitbake.conf - the first one it finds on its path! This file pulls in other configuration files - also from the path - including conf/local.conf, conf/distro/openslug.conf and conf/machine/nslu2.conf.
4. bitbake finds a provider for whatever you want built - this is really just a specific .bb file from the packages directory.
5. bitbake evaluates the dependencies and builds each package in the correct order (like make but bitbake stores explicit time stamps in the tmp/stamps directory).

The build of a package executes a number of steps - tasks - as described by bitbake.conf and the .bb file for the package. Typically this means something like:

1. Download the source.
2. Run configure.
3. Compile the configured source.
4. Install the source (by building a package which may later be installed on the NSLU2.)

Changing the build

The simplest change is just to build a new package - bitbake newpackage. This puts the package in deploy/ipk from whence it can be downloaded to the NSLU2 and installed using ipkg. Alternatively you can set up a local feed (e.g. using an ftp server.) In that case you need to rebuild the package index (in deploy/ipk) after building the new package:

Anything else you want to do involves at the very least editing conf/local.conf or adding something (a new .bb file maybe) to the source tree. Some OpenSlug specific examples follow. If you haven't read the OpenEmbedded getting started page now is the time.

Adding a package to the firmware

You can add a small package to the image. If you add too much either the image will not build or it will fail to boot because there is insufficient space on the root file system.

Take a look at conf/local.conf - see the lines:

Add two lines like this for the package (or packages) you want to install. (It's the RDEPENDS line which adds to the firmware - you can add DEPENDS lines without limit, that just builds the package.)

While you are doing this, take a look at the other package additions in there. You probably don't want both the reiserfs tools and the ext3 file system tools - because you probably only use one or the other.

Using uClibc

The default build uses the Free Software Foundation glibc library as the fundamental C library. It is big. uClibc is a smaller implementation with almost as much functionality.

To use uClibc simply add:

to conf/local.conf then rebuild everything - use make clobber or simply remove the tmp directory.

With uClibc you can add a lot more to the root file system. Indeed if you are considering using OpenSlug in a way where it uses the root file system on flash you almost certainly want to use a uClibc build.

Changing the kernel

It's easy to use another kernel. OpenSlug and local.conf provide plenty of rope for this purpose. Look at the lines in conf/distro/openslug.conf which mention openslug-kernel.

packages/linux includes a set of .bb files for testing new kernels. This is nslu2-kernel. Look at packages/linux/nslu2-kernel_2.6.12.bb. This attempts to separate out the NSLU2 specific kernel patches from the bitbake specific boilerplate so that it is easy to add a new kernel.

To use the 2.6.12 kernel (this is known to work) simply add the following two lines to conf/local.conf

Then rebuild the image.

At this time it is not possible to test a new kernel without reflashing the image - in fact it may never be possible because the space on the flash is so limited.

Testing new images

OpenSlug provides a special shell script to update a new image without using UpSlug. This is the script reflash. To use reflash simply download the new image to the NSLU2 disk and run:

This must be done with a root file system which is not the NSLU2 flash. It is advisable to use a disk root system for this, but it is possible to do it with just the NSLU2 by swapping to a ram file system first:

In this case download the image to /tmp - there is insufficient room in the RAM root file system, but /tmp is mounted using tmpfs!

reflash attempts to preserve and restore the system-specific configuration (such as password changes) on the original flash file system.