Building a Xilinx ML300 Linux Kernel: Building an Open Source Kernel

Next Previous Contents
2. Building an Open Source Kernel
A great deal of the information found in the section comes from a guide to the Xilinx ML300 under V2PDK by Wolfgang Klingauf.

Compiling PowerPC binaries natively may not be an option to most people since most of us work on x86 workstations. The natural choice for producing a PowerPC compatible binary is cross-compilation. This means a compiler is built on the workstation of your choice but configured to produce binaries compatible with the PowerPC.
2.1 Using CrossTool
Building a cross-compiling toolchain is typically regarded as an ugly and error-prone process. Fortunately, Dan Kegel has developed a set of shell scripts to save us all the headache by automating the toolchain build process.

Start by downloading Crosstool and unzipping the tarball in your favorite directory. This should create a crosstool-<version> directory. Inside, you will find a bunch of files named demo-<arch>.sh, each containing the commands to initiate a download/build process for the corresponding architecture.

If you are satisfied with the latest stable versions of gcc and glibc, you can simply use the demo-ppc405.sh script. On the other hand, the demo.sh script contains the following section which includes several configurations of older versions of gcc/glibc (Note: your section may look slightly different). Each entry is verified to work with the build scripts. Simply comment out all the eval lines except the one with the gcc/glibc versions you are interested in building. Then delete/comment out all the other eval lines relevant to other architectures.
# PPC 405
eval `cat powerpc-405.dat gcc-3.2.3-glibc-2.2.5.dat`  sh all.sh --notest
#eval `cat powerpc-405.dat gcc-3.3-glibc-2.2.5.dat`   sh all.sh --notest
#eval `cat powerpc-405.dat gcc-3.3-glibc-2.3.2.dat`   sh all.sh --notest
eval `cat powerpc-405.dat gcc-3.3.2-glibc-2.3.2.dat`  sh all.sh --notest
eval `cat powerpc-405.dat gcc-3.3-20040126-glibc-2.3.2.dat` sh all.sh --notest
# build verified 0.26-pre3
#eval `cat powerpc-405.dat gcc-3.3-20040112-glibc-2.3.2.dat` sh all.sh --notest
Before you kick off the scripts, there are some environment variables that need to be defined. Namely TARGET, which describes the target architecture to the scripts, and PREFIX, which tells which directory to put the final toolchain. In a csh environment, issue the following commands:
$ export TARGET=powerpc-405-linux
$ export PREFIX=/opt/${TARGET}
Now all that's left is to start the build process. Give the following command if you modified the demo.sh file.
$ sh demo.sh
Otherwise, run
$ sh demo-ppc405.sh
A few hours and GB later, you should have a functional cross-compiler in your PREFIX directory. The final step is to add the cross-compiler's bin directory to your search path.
$ export PATH=${PREFIX}/bin:${PATH}
All the cross-compiler's binaries are prefixed with powerpc-405-linux-gnu-. So to compile an object file for the PowerPC architecture, issue the command
$ powerpc-405-linux-gnu-gcc -c some_file.c
2.2 Installing BitKeeper
As I write this document, we are currently using version 2.4.21 of the PowerPC development Linux kernel. As far as the ML300 is concerned, this version should suffice until the inevitable transition to a version 2.6 kernel. The following are steps to obtain a copy of the 2.4.21 kernel source tree. Supplementary instructions for this process can again be found at Wolfgang and Uwe Klingauf's ML300 page.

The simplest way to get your hands on the proper version of the kernel uses a tool called BitKeeper (a source control system - like CVS). With BitKeeper, you download an entire repository and extract the desired version of the source tree from that repository. The first step is naturally to install BitKeeper.

Fill out the software download form and download the latest version of BitKeeper from the BitKeeper Downloads Section. You should end up with a file that looks like bk-<version>-<arch>-<platform>.bin where <arch>-<platform> refer to the architecture and platform of the workstation you are installing BitKeeper to. If execute permissions are not set, give it a
$ chmod +x bk-<version>-<arch>-<platform>.bin
Now run the installer and follow the instructions.
$ ./bk-<version>-<arch>-<platform>.bin
A good place to stick the installation is /opt/bitkeeper, provided you have root access on your workstation. If not, any directory will work as long as you add the bitkeeper directory to your search path.
2.3 Downloading an Open Source Kernel Tree
Once you've successfully installed BitKeeper, you're ready to download the ppc-kernel-2.4 development repository. The following command makes a local clone of the development repository.

For a list of available source trees, visit the PowerPC BitKeeper page. The source we are currently using is linuxppc_2_4_devel, the Linux 2.4 for PowerPC development tree. The following command makes a local clone of the development repository.
$ bk clone bk://ppc.bkbits.net/linuxppc_2_4_devel <directory>
Alternatively, you can download the repository from the MontaVista mirror.
$ bk clone bk://source.mvista.com/linuxppc_2_4_devel <directory>
At this point, you may want to make another local clone of the repository you've just downloaded. If you think you may be playing around with different versions of the tree, this will save time. If not, it's a waste of space. To clone a local repository, type:
$ bk clone <source_dir> <dest_dir>
2.4 Rolling Back the Tree's Version
To view a list of possible roll-back points, go to the linuxppc_2_4_devel tags page. The tag for the version that we have rolled back to is v2.4.21_linuxppc_2_4_devel. To roll the repository back to version 2.4.21, issue the following commands.
$ cd <top_repository_dir>
$ bk undo -a v2.4.21_linuxppc_2_4_devel
Now the repository is in the desired state, but there is no source present. In order to extract the useful source in a BitKeeper repository, you need to check out all the files. To check out the source tree with write permissions set, issue the commands:
$ cd <top_repository_dir>
$ bk -r edit 
At this point, you have a full kernel source tree, and it's time to to build it. If you installed the source as manager in order to have non-user modified code, revert to a normal user and make a private copy of the source tree for working purposes. If you are a user, begin at this point by making a private copy in your workspace. This copy must exist outside of BK version control, or else your work will be overwritten.
$ cd <top_repository_dir>
$ cp -r v2.4.21_linuxppc_2_4_devel <kernel_src_dir>
2.5 Incorporating a BSP
You will need to copy the Board Support Packages into the kernel source directory. The Board Support Packages (BSPs) are definitions and drivers generated by the Xilinx System Platform. For information on building the BSPs, consult the Xilinx tools. Once the BSPs are built, copy them directly into the top kernel source directory.
$ cd <kernel_src_dir>
$ cp -R <BSP_dir>/* .
To verify which files have been changed between hardware definitions, issue a diff command:
$ diff -r <BSP_dir>/arch/ arch/ | grep diff
The output can be something like the following, which means that only xparameters_ml300.h has changed. A similar command can also be used to check differences in the driver files.
diff -r <BSP_dir>/arch/ppc/platforms/xilinx_ocp/xparameters_ml300.h arch/ppc/platforms/xilinx_ocp/xparameters_ml300.h
2.6 Modifying the Makefile
First, you need to make two small changes to the root Makefile in your source tree. Open the Makefile in the top kernel source directory with your favorite editor. To define the build type, change the line beginning with ARCH to
ARCH := ppc
Next, the cross-compiler prefix must be defined. Change the line beginning with CROSS_COMPILE to
CROSS_COMPILE = powerpc-405-linux-gnu-
2.7 Configuring / Building the Kernel
The best base configuration to start with is stored in the file <top_kernel_dir>/arch/ppc/configs/xilinx_ml300_defconfig. Copy this configuration file up to the root source tree directory:
$ cd <top_kernel_dir>
$ cp arch/ppc/configs/xilinx_ml300_defconfig .config
Next, bring up the kernel configuration window.
$ make menuconfig
The Initial kernel command string statically passes arguments to the kernel at boot time. Since there is currently no way for the boot loader to pass additional arguements to the kernel, so specifying options here is our only option. The command string can be found in the General Setup section and should read
console=ttyS0,9600 console=tty1 ip=on root=/dev/xsysace/disc0/part3 rw
by default. console=ttyS0,9600 sends system messages to serial zero, which is our Hyperterm on the first serial port, at 9600 baud (matching the expect baud rate is important). console=tty1 directs a second copy of system messages to the LCD panel, defined as tty1. root=/dev/xsysace/disc0/part3 rw tells the kernel to mount the root filesystem located on partition 3 of the microdrive after boot. ip=on turns on autoconfiguration of IP. Since we set the IP configuaration manually, this setting should be changed to
console=ttyS0,9600 console=tty1 ip=off root=/dev/xsysace/disc0/part3 rw
Aside from the IP switch in the kernel command string, the default configuration works out of the box. Any other changes you would like to make in the configuration should be made now.

After finishing the configuration, click Save and Exit to overwrite the .config with the configuration changes. The next step is to compile. Simply run
$ make dep && make zImage && make modules
and hope nothing dies.
2.8 Installing the Kernel
Once the compile is finished, all that's left is to install the kernel and modules on the ML300. The System.map file contains the symbol information for this kernel, which will be required if you need to report a problem. System.map can be found in the root directory of the kernel source tree.

The kernel itself is named zImage.elf and can be found in
<top_kernel_dir>/arch/ppc/boot/
The modules need to be installed to some directory other than your workstation's /lib directory. To this end, run
$ make modules_install INSTALL_MOD_PATH=<mod_install_dir>
This will place the modules into <mod_install_dir>/lib/modules/x.y.z on the host, which can then be transferred to the target machine. The target directory for the modules on the ML300 should be /lib/modules/x.y.z.

Next Previous Contents