Linux and BusyBox
Introduction
This page outlines the basics of setting up a Linux kernel image with a RAMdisk containing BusyBox applications.
Compiling the Linux kernel image
The standard OpenRISC Linux kernel port contains enough to boot the kernel and present the user with a console prompt via the serial port. The following guide uses the ORSoC OpenRISC development board as an example target for kernel configuration, compilation and download via GDB.
Configuration using menuconfig
After downloading the Linux kernel sources and applying the appropriate OpenRISC patch, enter the interactive kernel configuration menu, called menuconfig with the following command:
user@host:~/linux-2.6.24$ make menuconfig
You should be presented with the following
From here all the options for the kernel configuration are accessible.
Configuration for the ORSoC development board
The following configuration applies to the ORSoC OpenRISC development board.
Under the section Processor type and features --->
- (25) System clock frequency [MHz]
- (0x2000000) System memory size [hex, bytes]
- (0x100000) Reserved memory size [hex, bytes]
- [ ] Boot from FLASH
- [ ] High memory support
- Timer frequency (100 HZ)
- Preemption Model (No Forced Preemption (Server))
- (1) Memory Controler Version (1 or 2)
- [ ] Initilaze memory controler
- [*] Enable iCACHE
- (8192) iCACHE size [bytes]
- (16) iCACHE line size [bytes]
- [ ] Enable dCACHE
- (64) Number of iTLB entries
- (64) Number of dTLB entries
- [*] use SPR_SR_DSX software emulation
- [*] Enable anonymity
There are also many other options including additional debugging information that can be enabled. The setup here should be enough to boot the kernel on the ORSoC development board.
Once the configuration is set, exit and save the configuration.
Compiling the kernel
Once the configuration is set, the kernel image can be generated with the following:
user@host:~/linux-2.6.24$ ARCH=or32 CROSS_COMPILE=or32-elf- make vmlinux
If the Makefile in the root Linux kernel directory has the following lines set:
ARCH = or32
CROSS_COMPILE = or32-elf-
then the kernel can be compiled with
user@host:~/linux-2.6.24$ make vmlinux
This will generate an ELF and binary image of the kernel. These files are vmlinux and vmlinux.bin respectively.
Downloading the kernel image
These instructions should apply to any OpenRISC system that GDB 6.8 works with.
Follow the guide found on the physical target debugging page here on OpenCores, for instructions on how to setup the proxy and a serial console terminal connection.
Specify the vmlinux file when loading GDB or specifying the file to use with the file command.
Load the image onto the board:
(gdb) file vmlinux
Reading symbols from vmlinux...tdone.
(gdb) target remote localhost:5555
Remote debugging using localhost:5555
0x000005a0 in ?? ()
(gdb) load
Loading section .text, size 0x235b8c lma 0x0
Loading section .text.init.refok, size 0x440 lma 0x235b8c
Loading section .exit.text.refok, size 0x268 lma 0x235fcc
Loading section .rodata, size 0x2ce5c lma 0x237000
Loading section __param, size 0x280 lma 0x263e5c
Loading section __ex_table, size 0xc60 lma 0x265000
Loading section .data, size 0x19328 lma 0x266000
Loading section .data.cacheline_aligned, size 0xe0 lma 0x27f340
Loading section .data.init_task, size 0x2000 lma 0x280000
Loading section .init.text, size 0x183d4 lma 0x282000
Loading section .init.data, size 0x898 lma 0x29a3d4
Loading section .init.setup, size 0x234 lma 0x29ac70
Loading section .initcall.init, size 0x194 lma 0x29aea4
Loading section .con_initcall.init, size 0x8 lma 0x29b038
Loading section .init.ramfs, size 0x2000 lma 0x29c000
Loading section .initrd, size 0x200000 lma 0x29e000
Start address 0xc0000000, load size 4826036
Transfer rate: 120 KB/sec, 4008 bytes/write.
Next, set the PC to the reset vector (the kernel image is linked so the reset code is located at this address, but the entry point was not set automatically meaning we have to do this manually.)
(gdb) spr npc 0x100
SYS.NPC (SPR0_16) set to 256 (0x100), was: 3221225472 (0xc0000000)
Next, simply start execution with the continue (c) command.
(gdb) c
Continuing.
The serial console should be showing the boot messages from the kernel, and finally present the user with the console.
Customising the RAMdisk
The RAMdisk is an EXT2 format image found in the arch/or32/support/ path of the OpenRISC-patched Linux kernel source.
See this guide for information on making your own boot RAMdisk from scratch.
This image can be mounted and explored using the standard mount command on Linux. Unfortunately there is no simple method of mounting and editing EXT2 images under Cygwin Windows.
Mount the RAMdisk like so:
user@host:linux-2.6.24$ cd arch/or32/support
user@host:support$ mkdir rd_mnt
user@host:support$ sudo mount -o loop initrd-fb-03.ext2 rd_mnt
[sudo] password for user:
user@host:support$ ls rd_mnt
bin dev etc home linuxrc proc root sbin tmp usr var
The RAMdisk is now mounted under a directory in the arch/or32/support path called rd_mnt.
The contents of the RAMdisk are now accessible and it can be updated or changed as required. Take note of the size limit on the image. Check the image's space usage with the df command like so:
user@host:support$ df -h rd_mnt
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 2.0M 401K 1.6M 20% rd_mnt
The Makefile in the arch/or32/support path contains the IMAGE variable which specifies the name of the image file that is compiled into the vmlinux kernel image. If you wish to change the name or easily switch RAMdisk images, alter this IMAGE variable in the Makefile.
It is recommended that the RAMdisk is unmounted after changes are made, before recompiling the vmlinux image. Sometimes the intermediate file used by the kernel compilation scripts, initrd.o in the arch/or32/support path is not correctly updated, and it can help to delete the initrd.o file before re-compiling the kernel with make vmlinux from the kernel sources root.
Unmount the RAMdisk image with:
user@host:support$ sudo umount rd_mnt
BusyBox
A version of BusyBox is downloaded and configured by the OpenRISC GNU toolchain port installation script. The following example will use this copy of the BusyBox sources, but versions up to BusyBox 14.1 have been tested and work in the OpenRISC Linux kernel image.
BusyBox configuration using menuconfig
Like the kernel, BusyBox contains a graphical configuration tool. This is started by going to the BusyBox path and typing the following:
user@host:busybox-1.7.5$ ARCH=or32 CROSS_COMPILE=or32-elf- make menuconfig
Like the kernel, it's also possible to change the lines initialising the ARCH and CROSS_COMPILE variables in the Makefile to the following:
ARCH = or32
CROSS_COMPILE = or32-elf-
allowing all make commands to be issued without defining these variables on the command line. For instance, menuconfig can be launched simply with
user@host:busybox-1.7.5$ make menuconfig
This will be addressed in future patches.
Select applications to include in BusyBox
The next step is go through and select the programs which will get compiled into BusyBox. See the BusyBox site for any questions specific to this step.
Compile BusyBox
Once the applications to bundle into BusyBox are selected, issue the compilation command.
user@host:busybox-1.7.5$ make all
This will generate the all important busybox binary in the root directory, but further setup is required for BusyBox to be installed into a standard Linux root tree structure.
If using the BusyBox sourced included with the OpenRISC GNU toolchain port installation script then the default installation location is in ../busy_out.1.7.5 - this option can be changed by reconfiguring BusyBox with the CONFIG_PREFIX variable set to your desired location. For now, this default path will be used.
Install BusyBox
Use the following (assuming the ARCH and CROSS_COMPILE variables are now set in the BusyBox Makefile) to setup BusyBox in our output directory:
user@host:busybox-1.7.5$ make install
Check the directory BusyBox was setup in and you will notice some common paths found at the root of a standard Linux environment; bin, sbin and usr.
Installing BusyBox in the Linux RAMdisk
This is done simply by copying the contents of the BusyBox installation directory into the root of the RAMdisk.
Mount the RAMdisk
Change to the directory containing the RAMdisk and mount it (presuming the mount point rd_mnt already exists):
user@host:$ cd linux-2.6.24/arch/or32/support
user@host:support$ sudo mount -o loop initrd-fb-03.ext2 rd_mnt
[sudo] password for user:
Copy in the new BusyBox output
Copy the contents of BusyBox's installation directory into the root of the RAMdisk:
user@host:support$ sudo cp -r ../../../../busy_out.1.7.5/* mnt_rd/
[sudo] password for user:
Something to take note of here is if an application has been removed from the BusyBox its symbolic link may still be in the RAMdisk. These must be removed manually to avoid confusion about what is actually included in the present build of BusyBox.
It's also a good idea to install any required init scripts or other application data as required at this stage.
We are now finished with updating the RAMdisk.
Unmount the RAMdisk and rebuild the kernel image
In order to update the vmlinux kernel image with the new RAMdisk we need to issue its make command again. It's a good idea to unmount the RAMdisk before doing so. We'll also delete the script-generated binary image of the RAMdisk:
user@host:support$ sudo umount rd_mnt
user@host:support$ rm initrd.o
Now rebuild the kernel.
user@host:support$ cd ../../..
user@host:linux-2.6.24$ make vmlinux
Developer(s)
The team working on Linux port and hardware verification:
Top