Porting Linux to a PowerPC Board

An experiment and experience in using Linux in an embedded application.
Creating the Kernel Image and the Root Image

As discussed previously, the elinux ball needs a statically linked kernel image and a root file image. Their preparation needs some skills.

The Linux source provides the rules to create various kernel images for different platforms. For our system, we need a compressed binary kernel image, vmlinux.bin.gz. The steps to create it are, in order, configuration, compiling and linking, transferring to binary format and compressing. In configuration, make sure the RAM disk support and the initial root file system support are selected, and that all unnecessary options are disabled. Compile and link the kernel for the ELF executable called vmlinux. Then transfer to binary format and compress it by commands such as:

(CROSS_COMPILE)objcopy -S -O binary vmlinux\
gzip -vf9 vmlinux.bin

Because we choose to mount an initial root file system in RAM after the kernel is up, we have to prepare a root image, called ramdisk.gz, and put it into the elinux ball. We do this by creating an EXT2 file system in a 4MB RAM disk on the cross-development platform. Next, create the subdirectories such as /etc, /dev, /bin and /lib. Then, copy scripts, binaries, device nodes, etc. onto the RAM disk. Finally, compress the RAM disk image and get ramdisk.gz. For example, to create a RAM disk in /dev/ram1, type:

rdev -r /dev/ram1 4096
Make a file system and mount it to /tmp by typing:
mke2fs -vm0 /dev/ram1 4096
mount /dev/ram1 tmp
To create a device, use cp -d or mknod in this way:
mknod ttyS0 c 4 64
This creates a device node for the serial console port on elinux, with major number 4 and minor number 64.

After everything in /tmp is ready, compress it by typing:

dd if=/dev/ram1 bs=1k count=4096 |
gzip -v9 > ramdisk.gz

What should be included in the initial root RAM disk will depend on our requirements. We copy a minimum number of shared libraries, plus some programs like bash and vi for tests.

Debugging Support

Bugs are inevitable. “Given enough eyeballs, all bugs are shallow” is only partly true. Most often, we have to debug without outside help. Debugging may be painful, especially for system booting. There is a booting debugging tool supported by special hardware, but we don't want to rely on it. Other debugging mechanisms such as printk and gdb help in many cases, but they need too many system services. For example, the Linux kernel debugging support, printk, works only after the system is ready to write to a console or the file system. If the system crashes before that time, we get nothing from printk, even if printk uses a memory buffer to store information earlier in the process.

Simplicity means efficiency in this case. To help solve the problem, we add rprintf. It is a simple printing function using raw output, which writes characters directly to the console I/O port without any buffering and any other support. rprintf is like printf, but based only on this kind of raw output. It works very soon after the iloader runs, so it can be used to debug kloader and the Linux kernel as well. rprintf helps us solve most problems in the early stages of booting. We did have a few problems before rprintf is initialized, but we are not helpless. Our suggestion is to insert an operation to force a system reboot; in this way, you can locate the problem soon. We assume you know when the board starts rebooting. We provide a function called rreboot to do this job for our board by simply jumping to the system reboot entry point in ROM.

Concluding Remarks

Unlike other projects, this work relies heavily on the Internet. We have learned much about Linux and obtained resources such as the kernel code and Linux-related documentation from the Web. To do something meaningful on Linux, follow proven patterns by utilizing open-source code as much as possible. Reuse pieces of code that run, even if changes are required. Don't be too ambitious in the beginning. Spend plenty of time on investigation before moving on to the next stage. Also, take the time to have a good design at the beginning and choose good debugging support. Always refer to Linux books and web sites first whenever you need help (see Resources). Readers can easily discover a huge amount of related information on the Web.

The same thing can be done in several ways. Our experiments are far from comprehensive, but we are confident in Linux's potential in some embedded systems. We hope our experience will help other people who want to port a Linux kernel to their embedded system. There are many related issues for us to research—much fun is ahead.


He Zhu received his Ph.D. in computer science at the University of Manchester, England and is currently a researcher at Bell Labs. His interests include networking and system software. He can be reached at zhuhe@dnrc.bell-labs.com.

Xiaoqiang Chen received his Ph.D. in computer science from Cambridge University, England. He is currently a technical manager with Bell Laboratories, Lucent Technologies, where he has conducted research and development in high-speed networks. He can be reached at xchen@bell-labs.com.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Porting Linux to a PowerPC Board

Anonymous's picture

can you give the exact files that will be executed incourse of booting the kernel for PowerPC, if we are booting the target through NFS support?

about porting commands...

Anup's picture


well you have explained variou porting steps clearly, though I need some guidance about porting the more than one application in to one powerpc board...

Means...can I make one makefile and proceed ahead to create the compressed image and download in the board or any other method...

Please guide me .

Thank You,