By Jakob Engblom
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 world.
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 screenshot:
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 values:
- A Simics QSP synthetic platform is a perfect tool to test and run applications and middleware that need the OS API and a particular architecture.
- 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 development boards.
For additional information from Wind River, visit us on Facebook.