ARM Community: ARM DS-5: Inside the Virtual File System - ARM Community

Recently, I watched a video covering the ARM DS-5 development tool. The video shows how to use a Virtual File System (VFS) to enable the target machine to mount directories on the host machine. The VFS is one of my favorite features of virtual machines. I use this feature every day when working on my laptop running Windows and using VirtualBox to run Ubuntu Linux in a Virtual Machine. The VirtualBox file system driver is called vboxsf, but the concept is the same. VirtualBox allows me to easily copy files back and forth between Windows and Linux by mounting a Windows drive from Linux. Today, I will provide some details about how the Virtual File System shown the DS-5 video works, and some ideas on how it can be used to improve software testing.



The Real-Time System Model (RTSM) provided with DS-5 is a pre-compiled Virtual Platform which models a Cortex-A8 Versatile Board. The User Guide for the board is also available from ARM. The RTSM closely resembles the actual board and provides a way to run software without using any actual hardware. The RTSM can be started from within the DS-5 eclipse environment as shown in the video or from the command line. As I wanted to dig a little deeper to see what's behind the GUI, I looked in the DS-5 documentation for information on how to start it. I found I could run the RTSM using:

CODE% RTSM_EB_Cortex-A8 -C coretile.core.semihosting-enable=false \
-C baseboard.uart_3.untimed_fifos=true \
-C baseboard.uart_3.unbuffered_output=true \
-C terminal_3.start_telnet=false -C terminal_3.mode=raw \
-C baseboard.vfs2.mount=/tools/DS5/examples \
-a /tools/DS5/examples/DS-5Examples/ARMLinux/distribution/boot/eba8-rtsm _armv5tmtx_
config-2.6.28-arm2-realview-v7-ethDCC-profiler-vmfs.axf

Note, your path to the .axf file in the DS-5 release will be different.

The parameter vfs2.mount specifies the location in the host file system that will be available from inside the target. I specified to share the examples directory of the DS-5 release. After the target starts, I login as root and mount the host file system as shown in the screenshot.



Next, we need to understand a bit about how the Virtual File System works. First, the file system mount command has a file system type of vmfs so there must be a file system driver for vmfs. Some web searches don't turn up much; most results refer to a VMware concept which sounds similar, but not exactly what we are looking for. The next step is to dig into the Linux kernel source. I couldn't find anything in a recent source tree I had downloaded, but luckily I found the source for the kernel that is provided with DS-5 (and is running on the RTSM) in the DS-5 installation at:

CODE/examples/DS-5Examples/ARMLinux/distribution/kernel/source
Interestingly, one of the files in the patches/ directory is called patch-vmfs-2.6.28

Extract the kernel source using:

CODE% bunzip2 < linux-2.6.28.tar.bz2 | tar xf -
All of the patches are already applied to the kernel source tree so there is no need to patch anything.

Go to the file system driver directory:

CODE% cd linux-2.6.28/fs/vmfs
Looking at the driver reveals that is uses something called a MessageBox to pass data to and from the host system. The file messagebox.c reveals the mb_new() function showing there is a memory mapped area for control registers and buffer memory used for communication with the host. This implies a hardware peripheral in the design is included to provide this memory space in the CPU memory map.

Going back to the RTSM launch command it's clear that baseboard.vfs2 is the path to the hardware peripheral used to provide the control registers and memory buffer for the communication between the vmfs driver and the host machine.

Searching the ARM Information Center reveals documentation for the VFS2 component in the Fast Models from ARM 5.2 User Guide. This documentation confirms the mount parameter is the path to the host file system to be mounted from the target. It also confirms that the VFS2 component uses a component called MessageBox to facilitate communication. The MessageBox documentation gives the register set and information about the data buffer that looks just like what the vmfs Linux driver is expecting. This completes the picture of how a Linux device driver communicates with a hardware peripheral, and how this hardware model connects back to the host machine to provide the access to the host machine file system.

This brief overview provides some details of how the Virtual File System works, but why is this so important? After all, copying files between host and target is nice, but there are other protocols that can do the same thing. For example, with a real board like the BeagleBoard, scp or ftp can be used to copy files over the network connection and achieve the same results. If networking is available even nfs can be used to mount a network drive. Of course, some systems don't have a networking connection so things may be more complicated.

Back in 2008, I presented a paper and talk at the Embedded Systems Conference in Boston titled Coverage Driven Verification for Embedded Software. In the talk I outlined some work about creating a verification environment used to verify the Linux usb_storage device driver by using a Virtual Machine running Linux and attaching an actual USB memory stick to the Virtual Machine. The work produced some interesting results by inserting historical bugs back into the usb_storage driver and seeing if it was possible to use constrained random verification techniques normally deployed for hardware verification on a Linux device driver. I encourage you to take a look at the slides and paper for more details if you are interested.

One of the things we learned during the project is that having direct access to the host file system would have been useful (it was not available at the time). This is not only for copying files, but writing directly on the host file system is much better than using a network connection and a utility like scp to copy files because sometimes during verification the target system hangs or crashes and there is no good way to retrieve the important data such as the kernel log file, the gcov information for the driver, or other software monitoring history. This is especially true for a system using a root file system on a ramdisk. Copying files over a network connection also takes time. For a large number of tests where the tests need to be cross compiled on the host and copied to the target we found that the scp setup time was significant. Based on this past experience I'm a big fan of using the Virtual File System as a means to improve automation and make software testing easier, and I'm glad to see it working smoothly in the RTSM provided with DS-5.

Guest Partner Blog:

Jason Andrews is an Architect at Cadence Design Systems, where he is responsible for embedded software and hardware/software co-verification products and methodology. He is the author of the book "Co-Verification of Hardware and Software for ARM SoC Design" and lives in Minneapolis with wife Deborah and six wonderful children.

Shortlink to this post: http://bit.ly/cy0Vzf