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\
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 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.

Resources

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.

______________________

Comments

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

Hi,

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,
Anup.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState