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. New page seems to be here: OpenEmbedded Getting Started. This page contains specific information about the OpenSlug build - not about bitbake or OE!
Places to look, tricks and traps
- Always source setup-env (watch the build, look at the openslug Makefile).
- conf/local.conf is your friend. Most customisation can be done in here.
- packages/distro/openslug.conf has comments. Read them.
- packages/meta/openslug-image.bb is the route to a customised flash image. Are you absolutely sure you want to do that?
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
A quick overview
The build steps are roughly as follows:
- 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
- You run
bitbake to build something (for example
conf/bitbake.conf - the first one it finds on its path! This file pulls in other configuration files - also from the path - including
bitbake finds a provider for whatever you want built - this is really just a specific
.bb file from the
bitbake evaluates the dependencies and builds each package in the correct order (like
bitbake stores explicit time stamps in the
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:
- Download the source.
- Compile the configured source.
- 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 -
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:
OPENSLUG_EXTRA_DEPENDS += "lrzsz"
OPENSLUG_EXTRA_RDEPENDS += "lrzsz"
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.
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
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
PREFERRED_PROVIDER_virtual/kernel = nslu2-kernel
PREFERRED_VERSION_nslu2-kernel = 2.6.12
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:
reflash -i my-new-image.img
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:
shutdown -r now
In this case download the image to
/tmp - there is insufficient room in the RAM root file system, but
/tmp is mounted using
reflash attempts to preserve and restore the system-specific configuration (such as password changes) on the original flash file system.