(Created page with " == Prerequisites == === ARM Cross Compiler === To compile the linux kernel for the Guruplug, you must have an ARM cross compiler installed. I use the [http://www.codesource...")
 
Line 60: Line 60:
 
make ARCH=arm CROSS_COMPILE=arm-none-eabi INSTALL_MOD_PATH=/home/cpeacock/export/rootfs-f12 modules_install
 
make ARCH=arm CROSS_COMPILE=arm-none-eabi INSTALL_MOD_PATH=/home/cpeacock/export/rootfs-f12 modules_install
 
</PRE>
 
</PRE>
 
  
 
== Testing ==
 
== Testing ==

Revision as of 11:48, 3 February 2012

Prerequisites

ARM Cross Compiler

To compile the linux kernel for the Guruplug, you must have an ARM cross compiler installed. I use the CodeSourcery G++ Lite 2011.03-42 for ARM EABI. It is assumed the cross compiler has been added to your path.

uBoot mkimage

The bootloader used on the GuruPlug is u-boot. u-boot has a special image format called uImage. It includes parameters such as descriptions, the machine/architecture type, compression type, load address, checksums etc. To make these images, you need to have a mkimage tool that comes part of the u-Boot distribution. Download u-boot, make and install the u-boot tools:

wget ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2
tar -xjf u-boot-latest.tar.bz2
cd into u-boot directory
make tools
sudo install tools/mkimage /usr/local/bin

rootfs

After the kernel modules have been built, you will want to install them to your root filesystem. To speed up development, it is also a good idea to test the kernel via TFTP with a root NFS filesystem prior to committing the image to flash. Fedora has a pre-built ARM port which is ideal for this task. It can be downloaded from http://ftp.linux.org.uk/pub/linux/arm/fedora/rootfs/rootfs-f12.tar.bz2

Compiling the GuruPlug Kernel

# wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.1.10.tar.bz2
# tar -xjf linux-3.1.10.tar.bz2
# cd linux-3.1.10

Make and run the configuration menu:

# make ARCH=arm kirkwood_defconfig
# make ARCH=arm menuconfig
Device Drivers --> Graphics Support --> Support for Frame Buffer Devices --> DisplayLink USB Framebuffer Support. 
Device Drivers --> Graphics Support --> Console display driver support --> Framebuffer Console support.
Device Drivers --> Memory Technology Devices (MTD) --> Enable UBI - Unsorted Block Images
File Systems --> Miscellaneous Filesystems --> UBIFS file system support
File Systems --> Miscellaneous Filesystems --> LZO compression support
File Systems --> Miscellaneous Filesystems --> ZLIB compression support

Networking support -> Networking options -->The IPv6 protocol

Device Drivers -> Network device support -> Turn off Wireless LAN
# make ARCH=arm CROSS_COMPILE=arm-none-eabi- uImage

Now build the modules and install them to a suitable path:

make ARCH=arm CROSS_COMPILE=arm-none-eabi- modules
make ARCH=arm CROSS_COMPILE=arm-none-eabi INSTALL_MOD_PATH=/home/cpeacock/export/rootfs-f12 modules_install

Testing

TFTP Server

Rather than flashing your newly created kernel to find out it doesn't work or it is not quite configured correctly, a better way to load the kernel into RAM and boot it from there. u-boot allows kernel images to be loaded via TFTP.

To speed up development, I create an 'export' directory. A TFTP server is then configured to use this directory as the TFTP root.

From the export directory, add symbolic links to the kernel images. This way, you can recompile the kernel and the new image is instantly available without having to move it.

ln -s /path to linux/arch/arm/boot/uImage uImage-GuruPlug-3.1.10

u-boot tftpboot

To test your kernel, bring up a serial console to the GuruPlug. First we will need to configure the IP addresses. The ipaddr variable contains the IP address for the GuruPlug, while the serverip variable is the address of the TFTP server containing the kernel image.

setenv ipaddr 192.168.0.250
setenv serverip 192.168.0.251

These variables can be saved to non-volatile memory to speed up development.

Next load the image into memory at 0x800000:

tftpboot 0x800000 uImage-GuruPlug-3.1.10
<PRE>

And boot from the memory location:
<PRE>
bootm 0x800000

You may also require a root filesystem for debugging. One option is to use the filesystem already in place (i.e. UBIFS on mtd2). The perferred option is to export a root NFS filesystem. This has the added advantage as you can compile userland binaries on your development box, install them to the NFS export and have instant access to them on your target system.