Learning Center
Plans & pricing Sign in
Sign Out



									Embedded Systems Programming                                                  Practical 6

Title:                         Downloading and patching the Linux ARM kernel
Author:                        Craig Duffy 8/11/04.
Module:                        Embedded Systems Programming
Awards:                        CRTS 2, BSc Computing (part-time)
Prerequisites:                 Some Linux knowledge

This worksheet starts the process of porting the Linux kernel to the Puppeteer boards.
The kernel is downloaded, the ARM patches applied. We then look at the relevant
parts of the source tree from a porting point of view. We also look at the use that we
can make of the pre-existing configuration files.

Getting the kernel source

The kernel source can be found at a number of mirror sites or at We
need to download the correct version of the kernel. The version we shall use is
2.4.18. The sources can be download using cvs or as a compressed tape archive (tar)
file, sometimes called a tarball. The UWE Linux/Unix machines don’t support CVS,
so we will use ftp to get the tar file.

The kernel numbering is important. The kernel versions are all of the form x.y.zz. The
2nd number tells us whether we are using a production kernel, which should be pretty
stable or a development kernel, which is used for testing and developing new features.
If the number is odd then it is a development kernel or a production one if even. We
are using the 2nd major revision, the 4th release and the 18th minor revision. The
kernel development in the 2.4 series goes beyond 18, and we may upgrade later on.
The latest series of production kernels is the 2.6 series, but as our hardware is not
particularly up to date, we don’t really need to be at the bleeding edge! However,
eventually it is worth considering upgrading to the latest series, as any later fixes will
be available and all development queries that are not 2.6 based are likely to be

To download the kernel simply ftp, through your browser, to either or one
of its mirrors and download linux-2.4.18.tgz (or .tar.gz) file. You can ignore most of
the checksum files and diff files – as we are downloading a complete source tree we
won’t require them. Place the kernel somewhere with enough space – a few
megabytes and away from your main system tree. It is important if you are doing this
on your own machine to be careful on this point – the machine you a running may not
be using the 2.4.18 kernel and almost certainly won’t be running on an ARM
processor. Therefore if you unpack from your root directory you are likely to
overwrite some important system header and assembly files.

Once in a safe and large enough place, we can list the contents of the file, type

       tar –zvtf linux-2.4.18.tgz | more

The z option is for the compression (you could use gunzip or zcat as well), t gives a
table of contents, v is for verbose and f tells tar that it is reading from the file name.
The contents of the file should look something like.

Craig Duffy                            Page 1 of 5                            07-Dec-11
Embedded Systems Programming                                                   Practical 6

drwxr-xr-x   marcelo/marcelo     0 2003-06-13 15:51:39 linux-2.4.21/
-rw-rw-r--   marcelo/marcelo   18815 2003-06-13 15:51:39 linux-2.4.21/Makefile
-rw-r--r--   marcelo/marcelo    2818 2003-06-13 15:51:29 linux-2.4.21/REPORTING-BUGS
-rw-r--r--   marcelo/marcelo   44989 2003-06-13 15:51:29 linux-2.4.21/MAINTAINERS
-rw-r--r--   marcelo/marcelo   80612 2003-06-13 15:51:29 linux-2.4.21/CREDITS
-rw-r--r--   marcelo/marcelo    9291 2002-08-03 01:39:42 linux-2.4.21/Rules.make
-rw-r--r--   marcelo/marcelo   14239 2002-08-03 01:39:42 linux-2.4.21/README
-rw-r--r--   marcelo/marcelo   18691 2002-08-03 01:39:42 linux-2.4.21/COPYING
drwxr-xr-x   marcelo/marcelo       0 2003-06-13 15:51:37 linux-2.4.21/fs/
-rw-r--r--   marcelo/marcelo   21310 2003-06-13 15:51:37 linux-2.4.21/fs/super.c
-rw-r--r--   marcelo/marcelo    6259 2003-06-13 15:51:37 linux-2.4.21/fs/seq_file.c
-rw-r--r--   marcelo/marcelo   11910 2003-06-13 15:51:37 linux-2.4.21/fs/select.c
-rw-r--r--   marcelo/marcelo    9918 2003-06-13 15:51:37 linux-2.4.21/fs/read_write.c
-rw-r--r--   marcelo/marcelo   25828 2003-06-13 15:51:37 linux-2.4.21/fs/namespace.c
-rw-r--r--   marcelo/marcelo   49177 2003-06-13 15:51:37 linux-2.4.21/fs/namei.c
-rw-r--r--   marcelo/marcelo   51216 2003-06-13 15:51:37 linux-2.4.21/fs/locks.c
-rw-r--r--   marcelo/marcelo   30623 2003-06-13 15:51:37 linux-2.4.21/fs/inode.c
-rw-r--r--   marcelo/marcelo   25855 2003-06-13 15:51:37 linux-2.4.21/fs/exec.c
-rw-r--r--   marcelo/marcelo   32552 2003-06-13 15:51:37 linux-2.4.21/fs/dcache.c
-rw-r--r--   marcelo/marcelo   75322 2003-06-13 15:51:37 linux-2.4.21/fs/buffer.c
-rw-r--r--   marcelo/marcelo   16448 2003-06-13 15:51:37 linux-2.4.21/fs/block_dev.c
-rw-rw-r--   marcelo/marcelo    7301 2002-11-28 23:53:15 linux-2.4.21/fs/xattr.c
-rw-r--r--   marcelo/marcelo   13964 2002-11-28 23:53:15 linux-2.4.21/fs/pipe.c
-rw-r--r--   marcelo/marcelo   19763 2002-11-28 23:53:15 linux-2.4.21/fs/open.c
drwxrwxr-x   marcelo/marcelo       0 2003-06-13 15:51:37 linux-2.4.21/fs/jfs/
-rw-rw-r--   marcelo/marcelo   12602 2003-06-13 15:51:37 linux-2.4.21/fs/jfs/super.c
-rw-rw-r--   marcelo/marcelo   15077 2003-06-13 15:51:37 linux-2.4.21/fs/jfs/resize.c
-rw-rw-r--   marcelo/marcelo   33259 2003-06-13 15:51:37 linux-2.4.21/fs/jfs/namei.c
-rw-rw-r--   marcelo/marcelo   105210 2003-06-13 15:51:37 linux-2.4.21/fs/jfs/jfs_xtree.c
-rw-rw-r--   marcelo/marcelo    2594 2003-06-13 15:51:37 linux-2.4.21/fs/jfs/jfs_unicode.c

In order to extract the files you can use the –x option.

       tar –zvxf linux-2.4.18.tgz

This creates a sub-directory called linux into which the source files are placed.

You could extract the README file, only, from the tarball. This file contains a lot
of important information about the kernel build process. Type:

       tar –zxvf linux-2.4.18.tgz linux-2.4.18/README

Patching the kernel

Although the Linux kernel is meant for a large number of CPUs the main
development is done on Pentiums and the source tree is mainly targeted at PCs. In
order to use other versions of the kernel, as well as other major developments, such as
new memory management schemes, patches need to be applied. The standard patches
for ARM systems are found at, follow the developer links and
then go to the patches section - you should find all the patches you require. The
patches are named in line with the kernel they support, so for 2.4.18 you should look
for patch-2.4.18-rmk7.gz – the rmk extension means the Russell King patch, the
main ARM Linux developer. Beware of the pre-patches as these are experimental and
best left alone, unless you really need something in them.

The patch can be applied to the kernel source tree – must make sure that it is a pristine
copy of the source tree, as that is what the patch is expecting. If you are unsure type

       make distclean

Craig Duffy                              Page 2 of 5                           07-Dec-11
        Embedded Systems Programming                                                 Practical 6

        This should sort out problems left from any previous attempts. Apply the patch, type

               gzip -cd patch-2.4.18-rmk7.gz | patch -p0

        This must be done in the directory with linux sources as a sub-directory. There is a
        script for automatically applying patches in linux/scripts/.

               linux/scripts/patch-kernel linux

        Both these methods assume that you are running from the root of the kernel sources
        with the patch file in that directory too, i.e. the source files are in a sub-directory
        called linux. You should get lots of success/passed messages – if anything goes
        wrong you should see messages – you could try running script to capture the output to
        analyse it later on. The general problem is a mismatch between the kernel version and
        the patch. The patch is created by doing a diff on the original and updated kernel
        source, or a non-pristine source tree.

        If the patch has been successful the file linux/Makefile should have a new constant,
        EXTRAVERSION = -rmkN, where N is the patch revision number, e.g. rmk7, – if
        you can’t find this do a grep -i extraversion * at the source root.

        The organisation of the kernel source

        There are a number of areas that we need to know about in the kernel source. The
        overall organisation is as follows


Documentation config         mm             net    kernel    init   ipc             lib   fs scripts

                      arch        include                                 drivers

        The highlighted sub-directories are the ones that we need to modify in order to port.
        The subdirectory arch contains all the architecture sub-directories – arm, Alpha,
        m68k etc. Further family members are included as sub-directories. In each
        architecture sub-directory there are architecture specific implementations for the
        kernel, mmu, and library code – for example ARM has no floating-point hardware
        and must supply all of the code for these operations. There are also directories for
        booting and decompressing the kernel under the architecture directory.

        Craig Duffy                               Page 3 of 5                        07-Dec-11
Embedded Systems Programming                                                 Practical 6

As we are only porting a board rather than an architecture we will eventually need to
go into the arch/arm/mach-sa1100 sub directory – the SA1110 is included under this
heading. This includes details for generic StrongARM and board specific set-up code.

An important part to port is the boot (arch/arm/boot) and decompression
(arch/arm/boot/compressed) code. This generally requires locating in the correct
place for your board’s memory map and the serial port code correctly setting up.

The include directory also has an architecture sub-tree – the directory include/asm is
linked to asm-arm when building for ARM processors. There is a further sub-dir for
StrongARM, arch-sa1100.

The drivers sub-dir is the largest in the source tree, we will only be concerned with
the sections that deal with our devices – ethers and i2c, and we will only worry about
this once we have got a basic Linux system up and running.

The config directory contains all of the configuration files for the various boards and
architectures. At first we will simply high-jack an existing config that is close to our
board, but later on we will want to create our own, board specific configuration.

Finding a close configuration

Rather than start from scratch, and building our own configuration files and working
out all the settings we require, a sensible way to start is to find an already working
(we hope!) system which is close to ours. We can find out what is around by editing
the Makefile to indicate that we want the ARM architectures. Use emacs to edit the
linux/Makefile. Comment out (by putting a # at the beginning!) the line starting with

     ARCH := ‘uname ----------‘

and add the line

     ARCH := arm

Now type

     make menuconfig

to enable us to look at the current configuration. Under the menu System type select
the ARM processor type SA1100. This will then allow you to use the SA1100
implementations option to see a series of choices for StrongARM boards. You can
then browse through the settings to see which ones appear close to the Puppeteer.
Once you have looked through just quit and don’t save your setting.

Further information about the boards can be found in a number of places. The
Documentation/arm/SA1100 sub-directory contains descriptions and details about
various boards on the system. The details are fairly limited – but they often give a
lead for further information – a company name or web address. Secondly you can go
to the arch/arm/mach-sa1100/ include/asm/arch-sa1100 directory and look in the
various machine.c and machine.h files, which will give you information about the

Craig Duffy                           Page 4 of 5                            07-Dec-11
Embedded Systems Programming                                            Practical 6

various settings. Finally you can always go to Google and try to find more details
about the board.


Try to find the configuration that is closest to the Puppeteer board. You will need
the information gathered from the first worksheet. You should create a small tick-
list/spreadsheet of features on the Puppeteer and then cross-reference it with the
other boards that seem likely. You may find that the matches are not exact. Discuss
your results with your practical tutor, giving the reasons for your choice.

Craig Duffy                         Page 5 of 5                         07-Dec-11

To top