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:
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:
When you’ve gathered the components, open VirtualBox and run the New Machine Wizard by clicking the New icon.
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:
You can make these changes through the machine’s Settings panel. Follow these steps:
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.
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:
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:
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 nfsserver.yourdoman.com: /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:
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:
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.
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:
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.
Linux Embedded systems Related Tutorials
Linux Embedded systems Related Interview Questions
|Linux Embedded systems Interview Questions||Red Hat Linux Essentials Interview Questions|
|Red Hat Linux System Administration Interview Questions||Ubuntu Certified Professional Interview Questions|
|IBM AIX Interview Questions||Solaris Interview Questions|
|HP-ux 11iv3 system administration Interview Questions||Red Hat cluster Interview Questions|
|Embedded C Interview Questions||Unix/Linux Interview Questions|
|Unix Shell Scripting Interview Questions||Solaris Administrator Interview Questions|
Linux Embedded systems Related Practice Tests
|Linux Embedded systems Practice Tests||Red Hat Linux Essentials Practice Tests|
|Red Hat Linux System Administration Practice Tests||Ubuntu Certified Professional Practice Tests|
|IBM AIX Practice Tests||Solaris Practice Tests|
|HP-ux 11iv3 system administration Practice Tests|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.