Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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 busyboxbusybox: 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-184.108.40.206/arch/arm/boot/zImage -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.
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.