Porting Linux to a PowerPC Board
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\ vmlinux.bin 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 4096Make a file system and mount it to /tmp by typing:
mke2fs -vm0 /dev/ram1 4096 mount /dev/ram1 tmpTo create a device, use cp -d or mknod in this way:
mknod ttyS0 c 4 64This 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.
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.
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.
- Android Candy: Google Keep
- Handling the workloads of the Future
- Readers' Choice Awards 2014
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Days Between Dates?
- Synchronize Your Life with ownCloud
- diff -u: What's New in Kernel Development
- Computing without a Computer
- December 2014 Issue of Linux Journal: Readers' Choice
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane