Windows file sharing has always felt a bit magical to me. I
use it all the time, certainly, but I never quite understood how it worked;
it was just this big chunk of Microsoft protocol that felt like it really did not want to talk to
other types of operating systems. Sure, I have used the open-source "samba"
server for a long time with great success… but it always seemed to suffer from
issues with access rights (probably the fault of me and server setup and mixing Unix and Windows accounts, not a
fault in the server itself).
With this background, I was really delighted and surprised when I managed
to almost effortlessly get a Simics target to share and serve files to my
Windows host. A big-endian Power Architecture QSP target at that,
running VxWorks, how cool isn’t that? The key to the puzzle was the Visuality NQ Server from Visuality Systems Ltd. in Israel. It
just worked, and let me try some interesting and educational setups.
The setup I used is shown in the picture below. I have a
Simics QSP for PPC (Power), running VxWorks 6.9.2. On top if this, I run the Visuality
CIFS NQ version 7.00 Server
software. The QSP target is on a virtual network, and this network is also
connected to the host (otherwise, talking to it from the host would have been
kind of hard). In some development work, we also used Wind River Workbench
talking to a debug agent in the target VxWorks to debug the setup and load the
server as a loadable kernel module. Basically, Simics provides the equivalent
of a generic Power Architecture development board. The communication between
the targets and the host is done using CIFS/SMB/SMB2
protocol. This protocol is natively supported in Windows while NQ Server delivers it to the embedded/mobile
When I opened up a Windows Explorer and directed it to
\\10.10.0.2\, the view below results. We can see the default demo files
included on the tffs-formatted flash disk image used with the QSP VxWorks setup
(mounted as /tffs0 in VxWorks). The file listing from the VxWorks serial
console is the same as the file listing seen in Windows explorer. My biggest
issue here was just to convince Windows that the new network that showed up at
10.10.0.x was a friendly one that should be allowed to connect over CIFS to the
host machine. For very good reasons, Windows does not necessarily consider an
unknown network friendly, so I had tell it my Simics virtual network was really
my home network.
This setup also lets us modify the files on the target. We
can drag in new files, open files for editing and save the changes, and delete
files. Once the target file system was changed, we saved the contents of the
changed file system as a diff file which was added to the base image during the
system setup. This was used in the next step to provide multiple target machines
with individual persistent disk contents.
Indeed, the next step was to try to run a network of
machines inside of Simics. This was very easy to setup. Once the targets were
booted and up, and we tried starting the Visuality NQ servers, we hit a snag.
If the server was started simultaneously on all the machines (using target
serial-port scripted input it is trivial to type the same command at the same
exact time on all target machines), all server instances immediately shut down.
Strange. If we started first one, and then a second server, the first one
stayed up and the second shut down. The reason turned out to be that all CIFS
nodes need to have (actually the guilty protocols are NetBIOS and DNS but let’s
call this CIFS for a sake of simplicity) a unique name, and the VxWorks
instances we had here did not have any name set at all. Thus, a name collision
ensued. The solution was simple enough: provide each target with a unique name
from the scripted command-line setup.
What this demonstrates is that a virtual platform and virtual
network lets you discover properties of the software that you might not have
discovered until much later on hardware. Had we been working with hardware
boards, it is quite unlikely that we would have tried a multiple-machine test,
as that is a bit more work to do in hardware (scrounge a second board from some
other developer, get it configured, hook into your little local test network,
and try to bring it up). In Simics, we just made the script loop setting up
target machines run until 2 instead of 1 (and we could just as well have made
it run to 10 or 100).
Once this was sorted, we could mount multiple servers from
Windows, each with their own individualized disk contents, as shown in this
You can see the scripting of the startup setting the IP
addresses and names of the boards, before starting the server with the nqStart
command. This command starts both of the NQ daemon processes: NetBIOS and SMB. The
setup looks like this in Simics:
Apart from testing and demonstrating the nice software from
Visuality, this exercise provides excellent proof of some classic Simics
- A Simics QSP synthetic platform is a perfect
tool to test and run applications and middleware that need the OS API and a particular
- A Simics QSP provided a stable proven VxWorks on
top of which the Visuality software could be run immediately with network
access and a disk with a file system, with no need to worry about choosing and
configuring a particular target BSP and loading software and formatting a disk.
- You can build virtual networks of machines, and
connect these to the real world either individually or as a whole group.
- The contents of target file systems are easy to
customize, and the changes can be saved permanently as disk images (but you do not have to save them in case you badly messed up the data, like I did in my first attempts).
- Target scripting that automates the boot and setup of the target systems, including individual scripts
for each target machine that makes each machine different from the common baseline.
Finally, for Visuality Systems, Simics provides simple
access to a big-endian cross-target platform to test their software and its
portability. It makes access to arbitrary architectures as easy as running a
software program, rather than having to procure, configure, and maintain hardware