Virtual Linux Machines on Windows - Linux Embedded systems

Another approach you can take when working on a Windows host is to use virtualization software. Using this approach means that a virtual machine runs Linux on the Windows host. With today’s commonplace multicore processor, multi-gigabyte machines, this is a reasonable approach. One of the advantages of running a virtual machine is that you don’t need to compensate for Cygwin idiosyncrasies, because the virtual machine is running Linux.

When you run a virtual machine, a window opens on the desktop that looks like the monitor of the running machine. You can adjust this virtual monitor so that it occupies the entire screen area, which gives the applications running on the virtual machine more screen real estate. The virtual machine can also be minimized, and you can then use a terminal emulation program to connect via ssh (this is my preference.)

Several virtualization software packages exist:

  • Sun VirtualBox: This is the recommended solution. VirtualBox is easy to install and lets you easily create new machines.
  • VMware: VMware has been in the virtualization market for years and offers a very mature product. It’s harder to configure than VirtualBox and requires registration.
  • QEMU: This is an open source tool for system emulation that runs best on Linux. There are distributions for Windows that are precompiled.

Using VirtualBox

VirtualBox is by far the easiest software to install and get running and is the recommended solution. It does a great job with the basics and also offers features like emulation of the serial and USB ports. This is important because the primary way to communicate with a board during startup is through the serial ports. To create a development environment, you need the following:

  • VirtualBox software from Sun: Obtain this from the VirtualBox site, and run the installer. VirtualBox is a dual-licensed product, meaning that Sun can offer it as open source software and license its use under other circumstances. Commercial VirtualBox users can download and evaluate VirtualBox at no cost. If you’re a commercial user, the VirtualBox terms of use require you to obtain a license.
  • An Ubuntu bootable CD image: The Ubuntu project publishes CDs that are ready to boot a running Linux system (what’s called a LiveCD) and can be used for installation as well. The page asks for your location to find a close mirror. The download is a file that is a bit-image of a CD. Of course, any LiveCD distribution will do; there are plenty to choose from, and new ones appear on a regular basis. Ubuntu is used as an example because of its trouble-free installation and wide hardware support.

When you’ve gathered the components, open VirtualBox and run the New Machine Wizard by clicking the New icon.

Using VirtualBox

The wizard asks for a machine name and the operating system type and version. Any text supplied can be the name, but the best thing to do is to select a name that relates to the type of machine, like “ubuntu-version”. The next panel asks for the base memory size. The default is an acceptable value; click Next. In the Virtual Hard Disk Panel, click New under Boot Hard Disk. This lets you create a new “disk” for the virtual machine.


Create a disk with dynamically expanding storage. This type of disk grows until it reaches its size limit, taking up only the space it needs as it grows. When you create this type of disk, feel free to create a large disk in case you need the space later in the project. The next panel suggests a disk size, usually 8GB; increase this value to at least twice the suggested size. In this panel, you also give the drive’s file a name; use the name of the virtual machine, to make associating one with the other easier. Then, finish the Virtual Hard Disk Wizard. This is the last step in creating the virtual machine.

Before you boot the virtual machine, you must make two important changes:

  • Boot the machine from the virtual CD ROM drive: The virtual machine that’s been created has nothing on its hard drive. So, boot the machine with the Ubuntu CDROM image you downloaded earlier.
  • Change the network settings: The default networking uses the machine where the virtual machine is running like a router. To make accessing the network easier, change the network configuration so that the virtual machine shares the network adapter.

You can make these changes through the machine’s Settings panel. Follow these steps:


  • In the CD/DVD-ROM section, click Mount CD/DVD ROM Drive, and then select ISO Image file. Using the control next to the drop-down, use the Virtual Media Manager dialog to add the Ubuntu ISO file you downloaded earlier. Doing so makes the virtual machine think that ISO image is in the virtual CD/DVD ROM drive.
  • Change the networking so that the virtual machine shares the network adapters on the host machine. To do so, select Network at the left in the Settings panel, and change Attached To to Host Interface. The bottom part of the dialog shows a list that lets you select which host interface should be used by the virtual machine. If the computer where VirtualBox is located has only one adapter, no action is necessary. Click OK to save the settings.


  • To start the machine, double-click it in the list of virtual machines. A booting message appears. The CD-ROM ISO image is mounted, and the Ubuntu bootup message appears, asking if the distribution should be run from the CD ROM or installed on the machine. Click Install, and follow the instructions.
  • The biggest leap of faith occurs when Ubuntu asks if you want to reformat the current hard drive and use all of it for the Ubuntu installation. Click Yes. The drive being reformatted is the virtual drive, not the physical one on your system. In about 10 minutes, your Ubuntu machine is ready for use.

Host Services

After the software is installed, some additional configuration steps are necessary to get the packages in running order. This section goes through configuring each of the services and how to perform some testing and trouble shooting. The time you devote to making sure the services work as expected is well spent, because the boot loader provides little feedback in the event of failure. Knowing that software is in a working state removes one thing from the list when you’re troubleshooting.

Turn Off Your Firewall

Some systems run a firewall by default; this should be turned off. The system used for booting an embedded board shouldn’t be on the public side of the firewall, subject to attack from the general Internet.

Turn Off Your Firewall


TFTP, a lightweight file transfer protocol, uses other software to get running: xinetd. The xinetd program performs a neat job: it waits for network connections on ports (as specified in the /etc/services file) and, when a connection occurs, remaps the standard in and out to the read and write of the network connection. This trick means that the program run by xinetd has code that uses file semantics (like scanf() and printf()) and reads and writes over a network connection. Not all distributions have xinetd installed by default, so you may need to install it using your distribution’s package-management system.


The lines of interest in this file are server_args, which indicates the directory where TFTP stores and looks for files. The kernel that is downloaded to the board needs to be placed in this directory. Change the default value /tftpboot to something more convenient for you.



Some boards request an IP address during initialization. If the board is using an NFS-mounted file system, it certainly needs the network stack up and running. The DCHP protocol works by having a host send a broadcast packet requesting an address from a DHCP server and waiting for a reply. If an answer comes back before the timeout ends, the board uses the information in the reply to configure the network adapter. Take care when starting a DHCP server, because a typo in the configuration can result in the server merrily assigning addresses to computers other than the target board.

The following configuration only assigns addresses based on Media Access Control (MAC) addresses. The MAC address is a unique number assigned to the board by the manufacturer, so the chance of two machines on the network having the same MAC address is close to zero. It’s not exactly zero, because sometimes MAC address are duplicated across vendors (that is, Vendor B issues MAC addresses that only Vendor A should issue); more commonly, the board is given a MAC address during configuration that matches an existing address on the network. Duplicate IP addresses result in general network mayhem, result in at least three all-hands IT meetings; it's not the type of attention you want.

The software providing the reply is called the DHCP server and gets its settings from a file stored in /etc/dhcpd.conf. This file is read when the DHCP service starts, so this server must be restarted in order for changes to take effect.

A typical /etc/dhcpd.conf file looks like this:

typical /etc/dhcpd.conf file looks

Configuring a DHCP service for an enterprise is a complex business; however, for the case of booting a board, the configuration is as minimal as possible. In this example, the file has been configured so that it replies only to hosts with a MAC address of 02:03:04:f5:d6:07. You need to change this value for the board being booted. There are several ways to get the IP address for the board:

  • Look at the board: The MAC address is occasionally printed on a sticker. This is the low-tech solution.
  • When the board boots, the boot loader may show you the MAC address: Or, at the boot loader prompt, you can ask for the state of the environment. The exact method varies per boot loader; however, many boards use U-Boot, and the bdi command shows the following output along with some other information:ethaddr = :02:03:04:f5:d6:07;If you’re new to embedded systems, U-Boot is boot-loader software that runs after the board boots but before the operating system as started.
  • If all else fails, you can attach the board to the network, start the board, and have it attempt to find an address while running a packet sniffer on your desktop. This is the most hackerish way of getting the address; for some boards with primitive boot loaders, it’s sometimes the fastest way.
  • To sniff the network, use a tool called tcpdump to print out all broadcast packets on the network, and wait for the output. The tcpdump utility reports the MAC address of the machines broadcasting for a DHCP reply. For example:# tcpdump ip broadcasttcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes22:30:39.791184 IP localhost.bootpc > BOOTP/DHCP, Requestfrom :02:03:04:f5:d6:07 (oui Unknown), length 300After obtaining the MAC address, the next interesting line is fixed-address;

This is the address that is assigned to the host. The address should be one that is acceptable on your network and shouldn’t clash with other addresses. Specifying fixed-address means that when the DHCP server sees a request for an address from the MAC address in this section, it always returns the same IP address. Experimentation shows that a DHCP server frequently assigns the same IP address to a computer; this isn’t guaranteed by the specification but is an implementation artifact. By associating a MAC address with a fixed IP address, the board always gets the same IP address assignment.


The Network File System (NFS) protocol is a way for a machine to make a storage location (the so-called export in NFS parlance) available to other hosts on the network. NFS isn’t a requirement for embedded development, although it does make development easier because the root file system used by the target board can be easily updated when it’s stored as a directory somewhere on the development host.

Embedded boards that use flash memory (the same technology as USB drives) must have their file systems built and then placed on the board, and that process can be time consuming early in the development process when changes are frequent.

NFS exports are mounted like any other device in Linux, via mount: # mount –t nfs /some /path a-directory /that- exists After mounting, you can read or write to /mnt/nfs according to the permissions granted to you.Informing the NFS server of a mount is done through the /etc/exports file. The format of this file is very simple; for example, to export a directory containing a root file system to be mounted by a board, the file contains the following line: /var/rfs *(rw,no_root_squash).

This line says, “export /var/rfs, allow anyone to connect, allow reads and writes, and if a user with UID=0 connects, don’t attempt to remap the UID to something less dangerous.” The * means to allow connections from any host. Reading the man page for this file reveals that the user has great control over what hosts can mount an export: the user can enter host names, IP addresses, and IP address masks. All this is necessary for NSF servers deployed in an enterprise or public network, but is overkill for the purposes of booting a board, and is a generator of problems.

Restart the NFS server by doing the following:

Of course, replace nfs-server-host-name with the host name or IP address of the NFS server. After you’ve connected, test the connection by writing a file and printing the contents:

The most common problem with NFS is not having permissions to write files on the NFS server or misspelling name of the export in the /etc/exports file or the mount command. When you make changes, remember to restart the NFS server after changing the /etc/exports file.

NFS with Cygwin

Configuring the NFS server included with Cygwin requires some extra finessing. The NFS server must run as a Windows service, and you must do some mapping between the Windows and Unix security models. Fortunately, a script has been written that does this configuration work: nfs-config-server.

You must run this script in order for NFS to function under Cygwin. For this script to work, the account logged in to the Windows computer must have local administrator rights. You probably have local administrator rights, unless your IT department is more draconian than most.

Open a Cygwin bash shell, and do the following:

bash-3.2$ ./nfs-server-config

This script sets up a default configuration for running an NFS server under Cygwin. As part of this setup, the script will do the following:

  1. Create a user account to run the services under. [OPTIONAL]
  2. Install portmap, mountd, and nfsd as Windows services.
  3. Create a sample exports file.
  4. Create a sample uid/gid mapping file.

After installing, please read the nfs-server README for Cygwin:


This document contains notes on installation and documents known problems and workarounds with the NFS server; ex:

Do you want to continue? (yes/no)

Reassuring, huh? Answer Yes. The script fishes around to make sure there isn’t another Cygwin-like program that could cause problems. If all goes well, the following appears:

Checking for other Unix environments on this system ... Good! There doesn't seem to be any other Unix environments installed.

NFS with Cygwin

The services are installed and ready for use. The /etc/exports file also contains a parameter so that the NFS server can map the User and Group ID (UID/GID) of the mounting NFS server into a user and group that have read/write permissions in the Cygwin directory. This is an example file:

NFS with Cygwin

NFS with Cygwin


Preboot Execution Environment (PXE) is a specification for booting a system over a network. This technology was spearheaded by Intel as part of its management framework for networked computers. I’ll spare you the gory details behind the protocol; PXE works by adding additional information to the DCHP broadcast packet and behaving differently if it gets back a DHCP packet from a server supporting the PXE protocol.



All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Linux Embedded systems Topics