Home > Community > Blogs > System Design and Verification > exploring the virtual platform part 5
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Exploring the Virtual Platform Part 5

Comments(0)Filed under: System Design and Verification, virtual platform, linux, busy box

Welcome to part 5 of the Exploring the Virtual Platform series. This is probably (hopefully) the last post in the series related to the embedded software aspects of the Virtual Platform before I move to the hardware aspects of the platform and topics that are probably more familiar for Cadence users.

This post covers BusyBox - The Swiss Army Knife of Embedded Linux. Part 4 covered some details of how to cross compile a software program for the ARM Integrator Platform and how to put it in the file system so it could be run after the system booted. Since the program was a simple "hello world" it didn't take much to build it, install it, and run it. The next question relates to all the rest of the programs in the file system that make up a Linux installation. The Unix philosophy has always been to write programs that do one thing well. The result is many small executables that would all need to be cross compiled for the target system just like the simple hello program. BusyBox is the medicine for the pain encountered just thinking about cross compiling all of the needed utilities to build an embedded Linux system.

BusyBox is a single executable that takes the place of hundreds of individual executables. It's a multi-call binary that does the same job as multiple individual binaries. With BusyBox only one program needs to be cross compiled and it can be used for nearly every command needed for an embedded Linux system.

To understand more about BusyBox let's download it, compile it, and replace all of the utility programs in the Virtual Platform file system with newer ones that we compiled ourselves using a single busybox executable and maintaining all of the other links to the common program names.

From the screen shots in previous posts it's clear the version of BusyBox is 1.1.2 from sometime in 2006. Let's update to to version 1.10.1 which is the newest on the BusyBox Downloads page. I downloaded busybox-1.10.1.tar.bz2 and compiled it using the same cross compiler we used to build the Linux kernel and the simple hello program.

jasona-lin:104 % bunzip2 < busybox-1.10.1.tar.bz2 | tar xf -
tar: Read 1536 bytes from -

jasona-lin:106 % cd busybox-1.10.1

jasona-lin:107 % make defconfig ; make CROSS_COMPILE=arm-none-linux-gnueabi-

Just to make sure it's actually compiled for ARM:

jasona-lin:112 % file busybox
busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Now we can replace the busybox in the file system with the new one. If you still have the fs/ directory you are ready, if not extract the file system again as described in Part 4 using gunzip and cpio. The busybox executable is in the bin/ directory. If you cd into the bin/ directory you will see that all of the files there are actually links to busybox. Another thing you notice is that doing ls in the bin/ directory will not work if you have . in your path because ls is a link to busybox and now this means it's for ARM so it cannot be run on the host.

Copy the newly compiled busybox to the bin/ directory of the file system and use the same find and gzip command from Part 4. This time I will name the file system image arm_root3.img

We are ready to try to run with the new BusyBox.

jasona-lin:119% qemu-system-arm -kernel ~/kernel/linux- -initrd arm_root3.img

This first attempt results in a miserable failure - a Kernel panic. Here is the screen shot:



The message indicates something related to the C library. It happens because the libraries used to compile BusyBox from our cross compiler do not match those in /lib in our target file system. To remedy the situation we need to replace all the libraries in /lib with those from the cross compiler. For example, the current libc looks like this:

-rwxr-xr-x 1 jasona users 1372990 Mar  4 13:45 libc-2.3.6.so*
lrwxrwxrwx 1 jasona users      13 Mar  4 13:45 libc.so.6 -> libc-2.3.6.so*

To fix the panic we take libc-2.8.so from <install dir>/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib and put it in /lib in the target file system. Then we fix the link so that libc.so.6 points at the new libc-2.8.so like this.

lrwxrwxrwx 1 jasona users      11 Feb 17 15:57 libc.so.6 -> libc-2.8.so*

The rest is a bit tedious but this needs to be for all the libraries in /lib in the target file system and the links modified to point at the 2.8 versions instead of the old 2.3.6 versions.  Instead of doing it one by one all of the files in <install dir>/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib can just be copied to /lib in the target file system. Make sure to update arm_root3.img using the find and cpio command and try to boot again.

jasona-lin:119% qemu-system-arm -kernel ~/kernel/linux- -initrd arm_root3.img

One other note about the panic. It implies that busybox was being invoked during the boot. Indeed this is true as one of the many programs that BusyBox can provide is init, the first process run during the boot and always process id 1. Since init is started automatically by the kernel this was the source of the panic.

With the new libraries the boot succeeds, well almost. There are a bunch of error messages saying:

mdev: /etc/mdev.conf: No such file or directory

What do these mean?  Here is another chance to learn something about the boot process. The init program uses /etc/inittab to know what else to start. In our case, /etc/inittab starts a script /etc/init.d/rcS

One of the commands in this script is mdev which populates the device nodes in /dev automatically on boot. Again, mdev is provided by busybox and hence the reason for new error messages. This newer implementation of mdev is looking for a file /etc/mdev.conf  You can read the details of mdev on the BusyBox man page. To fix the errors create an empty file in the target file system by going into the etc/ directory and using  touch mdev.conf  This will eliminate the errors.

Recreate the arm_root3.img file system and try again and you will see the successful boot.

The screen shot below shows the output from 

% busybox | less

to confirm the version of BusyBox is the new one we installed.



In the first five posts related to the Virtual Platform many aspects of how to create an embedded system with Linux were explored. There is always more to learn but this information provides a solid background to understand how to construct all of the needed software from scratch.

Thanks for reading.




Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.