Welcome to the "Exploring the Virtual Platform" Series

Today I'm starting a series of articles related to what is commonly called the Virtual Platform or Virtual Prototype. There are probably many definitions of what it means, but I'm going to discuss the Virtual Platform as an abstract software model of a hardware system or subsystem created for the primary purpose of running embedded software and verifying the hardware/software interaction. A secondary purpose of the Virtual Platform is architectural analysis of the hardware/software interactions. Here are some general characteristics to help clarify what the Virtual Platform is:

• Runs unmodified target code
• Uses instruction accurate models of processors 
• Provides a full programmers view
• Runs very fast (may be faster than real time)
• Has excellent visibility and control (compared to physical hardware)
• Is easy to distribute to many users

Virtual Platforms have been around for a long time, ever since somebody got the bright idea to make a software model of the hardware so they didn't need to wait for boards and sit in a lab all of the time. There is a wealth of information available about Virtual Platforms from companies that have been creating and selling them for 10+ years, but instead of another press release or success story about Virtual Platform usage I will provide hands-on information about the Virtual Platform and especially the embedded software part of it. I suspect that many software engineers already understand the details about how to select operating systems, write device drivers, create and populate file systems, cross compile software, program flash memory, etc., but sometimes software engineers are not familiar with it since somebody else sets up all the infrastructure and they just "add code" in the right place. I'm also pretty sure that much of this information is now becoming critical to verification engineers and people who are in companies that have worked primarily with RTL simulation in the past and are making the transition to the next level of abstraction and see the Virtual Platform as playing a key role in system verification and delivery of high quality software sooner in the process. Refer to my first post on cadence.com

The hardware system I will use is the ARM Integrator CP board. It's is an older board that was supplied by ARM and according to the ARM website is no longer promoted because newer hardware platforms have been developed. Not being a state of the art board that means there is a lot of public information available as well as software available. One of the benefits of the Virtual Platform becomes apparent immediately. First, Cadence is a software company and probably wouldn't understand why I need to buy a board to develop embedded software. Next, if a physical board was needed I doubt any readers would buy the board to learn about how embedded software development and verification works.Since we have Virtual Platform technology nobody needs to buy any hardware and everybody can contribute. All that is needed is a Linux machine (sorry, I don't do Windows).

Instead of actually reading the User Guide, we can start with a quick overview of the Integrator board and its memory map:

ARM926EJ-S CPU

Peripherals                                        Base Address

Primary Interrupt Controller                    0x14000000
Secondary Interrupt Controller                0xca000000
Counter / Timer                                     0x13000000
Real time Clock                                    0x15000000
UART 0                                                0x16000000
UART 1                                                0x17000000
Control Registers                                  0xcb000000
Keyboard Controller                               0x18000000
Mouse Controller                                   0x19000000
Multimedia Card                                    0x1c000000
Ethernet Controller                                0xc8000000
LCD Controller                                      0xc0000000

There are many uses for the Virtual Platform. A common one we can start with is to boot the operating system and run applications. Another one is to write device drivers and debug them. To make life easy I'm going to use Linux as the operating system. Again, there is a wealth of information available and Linux is becoming popular as an embedded operating system. Let's get started.

To start with let's download QEMU to use a Virtual Platform for the Integrator board and boot Linux. 

First, get QEMU, an open source processor emulator. It might be on your Linux machine already or can be installed using your package manager. I'm currently typing on an openSuse 10.3 machine and it found qemu 0.9.0 (0.9.1 is the latest) in the YaST2 package manager. If you compile qemu from source there is one gotcha, it cannot be compiled with gcc4 so you need a version of gcc such as gcc 3.3 or 3.4. Even if your machine has a version of gcc 4 you can also install gcc 3. I installed gcc 3.4.6 to compile qemu. After installation, it can be invoked using gcc346 instead of the normal gcc command. The configure script for qemu looks for common names for gcc3, refer to the variable gcc3_list and add your invocation of gcc3 there and then run configure.

Now that you have qemu installed it's time to get a Linux kernel and file system and boot it. As an easy starting point download the ARM Linux 2.6 kernel and ram disk file system image from the qemu website. Extract this file and go to the arm-test directory.

As the README shows you can boot doing:

% qemu-system-arm -kernel zImage.integrator -initrd arm_root.img

If all goes well you will see a new window:

You can login as root with no password and you have a Linux system running on the ARM Integrator CP Board with the ARM926EJ-S processor. You can use Ctrl-Alt-2 to get to the qemu command prompt, type help to see the commands or type quit to exit. Ctrl-Alt-1 will get back to the console (this is actually the LCD controller). Ctrl-Alt-3 will get to UART 0 and allows another login window. Ctrl-Alt is the key to release the keyboard and mouse.

Now try some networking:

% wget http://www.google.com

This will download index.html This is a ramdisk so next time you boot the file will be gone.

To browse the web use the lynx browser:

% lynx google.com

Other than being pretty cool, this exercise raises many questions:

• How is the Integrator Board modeled?
• How does qemu know I want to run the Integrator board?  There was no configuration or arguments.
• What's in the file zImage.integrator?
• What's in the file arm_root.img
• How is the Ethernet controller on the Integrator board able to access the Internet?
• Can I debug code running on the Integrator board?
• This is a minimalist system, how can I compile and add more programs to it?

Stay tuned to future posts and find out all these answers and more.

Thanks for reading.