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_
Note, your path to the .axf file in the DS-5 release will be different.
vfs2.mountspecifies 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:
Interestingly, one of the files in the
patches/directory is called
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
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.vfs2is 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:
Shortlink to this post: http://bit.ly/cy0Vzf
0 Comments On This Entry
Please log in above to add a comment or register for an account
Search My Blog
Coding Using NEON Technology
on May 21 2013 08:57 AM
on May 08 2013 06:15 PM
New Platform Bring-Up with ARM® Development Studio 5 (DS-5™)
on Apr 30 2013 09:55 AM
如何利用全志安卓4.0 HDMI Dongle进行ARM DS-5 Streamline性能分析
on Apr 26 2013 10:50 AM
DS-5 Streamline Performance Analyzer on Allwinner Android 4.0 HDMI Dongle
on Apr 25 2013 04:58 PM