Get email delivery of the Cadence blog featured here
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:
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:
Peripherals Base Address
Primary Interrupt Controller 0x14000000Secondary Interrupt Controller 0xca000000Counter / Timer 0x13000000Real time Clock 0x15000000UART 0 0x16000000UART 1 0x17000000 Control Registers 0xcb000000Keyboard Controller 0x18000000Mouse Controller 0x19000000Multimedia Card 0x1c000000Ethernet Controller 0xc8000000LCD 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:
Stay tuned to future posts and find out all these answers and more.
Thanks for reading.
* How is the Integrator Board modeled?
Ans: It needs to model every devices that you need and map those physical address of each device by cpu_register_physical_memory(base,offset,type); and write all these information in the integrator virtual board c file qemu/hw/integrator.c
* How does qemu know I want to run the Integrator board? There was no configuration or arguments.
Ans:In vl.c you can see function register_machines(); which function will register all the machines that are supported in its architecture. The first default machine is integrator for ARM architecture. I think that's why it doesn't need configuration or arguments.
* What's in the file zImage.integrator?
Ans: It's the Linux kernel image of integrator and the .config is in it too.
* What's in the file arm_root.img
Ans: It is the root file system.
* How is the Ethernet controller on the Integrator board able to access the Internet?
Ans: Qemu uses slirp to accomplish the network ability. It is NAT that you used in this case. It provides real network connection too by tun/tap which need host Linux support
* Can I debug code running on the Integrator board?
Ans: Yes, you can. If you want to debug kernel, you can type "-s -S -p port_number" in the Qemu execution commandline then you can use a target remote gdb to debug the kernel. If you want to debug programs running in target Linux kernel, you can use gdbserver to debug it.
* This is a minimalist system, how can I compile and add more programs to it?
Ans:Yes, you can.