Create An Embedded Development EnvironmentDavid finishes describing his coLinux cross-development platform
that runs on Windows.You can create an embedded development
environment with him on coLinux or other versions of Linux.
In the first part of this series， I focused on creating a virtual
Linux environment on a Windows system using coLinux. coLinx is real
Linux running under Windows as a process. It uses Linux device
drivers communicating with Windows services to map access to
Windows resources （e.g.，disk， network， and memory） to Linux. In
this article， I‘ll concentrate on the process of creating an
embedded development environment. Although I'll describe how to
build that environment under coLinux and I‘ll assume the Debian
coLinux install from the previous article， little of this process
is specific to coLinux.
GUI TOOLS
Linux developers， particularly embedded Linux and kernel
developers，are still primarily， if not exclusively，a
command-line-driven edit，build， and debug cohort. GUI development
tools such as Eclipse are a major force dominating Java development
and making steady inroads into most other areas of application
development（including Windows） but still have only a toehold in
kernel and embedded development. There are few GUI tools for
embedded Linux or kernel development， and few kernel developers
could name （or care to） any GUI tools for Linux kernel development.
It is also worth noting that even under Windows most GUI
development tools are layers on top of commandline tools. Under
Linux， this is even more true. While there are a few other
compilers capable of digesting the Linux kernel， virtually all
Linux kernels are built using the GNU tools（e.g.， GNU Make and the
GNU compiler collection （GCC））。 Autoconf/AutoLib show up on complex
projects outside of kernel development. GIT， CVS， and subversion
are the primary source/version control managers. While advanced
skills with any or all of these might be useful， only a basic
understanding of some of them is critical to most embedded
development work.
My top 10 Linux commands for embedded developers are： cd，
mv（rename）， cp （copy）， ls （dir）， rm （delete），find， grep， vi， make，
and man. Embedded Linux kernel development requires an
understanding of programming for hardware， basic competence in C，
and possibly the assembler for the target embedded system， the text
editor of your choice， the presence of a GNU GCC cross-compiler for
the target，and a very basic understanding of Make. More complex
tasks， such as board bring up， require slightly more than a cursory
understanding of the configuration/ build environment unique to the
Linux kernel. Embedded， Linux， and open-source software development
is as chaotic a reflection of different programming styles as might
be found in any other area of software development. The Linux
kernel has a set of programming style guidelines that are mostly
adhered to. But programming style is irrelevant unless you are
hoping to include your board support/drivers in the distribution
kernel. I am fortunate that the Linu kernel coding style guidelines
so closely resemble my personal style that I could have written the
standard. But I have had to adapt to numerous and often radically
different programming styles for client projects.
Source/version control managers（SCMs） are incredibly valuable
tools. Any developer who does not use an SCM should drop everything
and learn one-any one， immediately. SCMs are useful outside
software development. I am trying to encourage my wife （a lawyer）
to make use of Tortoise SVN（the Windows Explorer integration of
subversion） for all of her writing. I have never regretted putting
anything into an SCM. I have frequently found myself wishing I had.
GIT is the SCM used for Linux kernel development. It has an
approach and style uniquely suited to the requirements and
preferences of Linux kernel developers. If you are intent on
participating in Linux kernel development and contributing to the
public kernel source repository， a minimal understanding of GIT
would be close to indispensable （http://linux.yyz.us/
git-howto.html）。
CVS and subversion are the dominant choices elsewhere. Subversion
is slowly supplanting CVS because it is primarily a kinder，
gentler， and more powerful version of CVS， but numerous other
choices exist. Competence with an SCM， while valuable， is not
essential for embedded Linux development. The same is true of the
plethora of open-source Linux/Unix tools. I use GIT for Linux
kernel work and subversion for most everything else. Both have
dozens of commands and options. Daily work with either requires the
use of at most a handful of commands. I rarely need to create a new
repository， a project within a repository， or a new branch or tag
within. Every day I need to add new files， remove existing files，
and commit my recent work. On rare， but critical，occasions I need
to revert to an older version. Specific to participating in Linux
kernel and other open-source projects， I need to produce diffs or
patches reflecting changes since a branch or tag. When I need to
perform infrequent tasks， I look them up-Google is your friend. The
commands for the daily tasks in most SCMs tend to be simple and
friendly.
Unless your target CPU is an x86， it is highly likely that you will
need crossplatform development tools. Many software consultants are
in the business of providing pre-compiled GCC cross tools as well
as support for various targets and platforms. Still， the most
frequent approach is to build your own.
Crosstool is a commonly used set of scripts for building
cross-platform versions of the GNU compiler collection tools.
Crosstool is available at http://kegel.com/crosstool. It also makes
sense to create the /opt/crosstool directory that Crosstool will
install into. Regardless， I need a small collection of Linux
software development tools，which can be retrieved using apt-get or
dselect. I recommend dselect because it is a friendlier textbased
GUI wrapper around apt，but the apt commands are scriptable and more
concise and suitable for print. wget is a command-line web file
retrieval tool. lynx is a text HTML browser.
The remainder are standard Linux x86 development tools required by
Crosstool to build a cross-platform version of GNU tools：
apt-get install wget
apt-get install lynx
apt-get install patch
apt-get install bison
apt-get install flex
apt-get install gcc
apt-get install libc-dev
apt-get update
apt-get upgrade
mkdir /opt/crosstool
COMMANDS
Linux best practices advocate performing tasks in a user account
with the minimum privileges needed for the task. Crosstool enforces
this practice by failing to build under as the root user. To create
a new user execute，the adduser command will prompt for required
information （see Photo 1）。 The only critical elements are a user ID
and a password.
The Linux su command switches users. "su test" will prompt for the
password for the user test and logon as test. "exit" will return to
the previous logon. Change to the new user‘s home directory. "~" is
a very handy shortcut that always refers to the current users home
directory，while "~user" is a shortcut referring to the "user" home
directory. Unix/Linux home directories are the rough equivalent of
the Windows \Documents and Settings\username directories. Under
Linux， home directories are typically in /home/user， but the home
directory for an account can be set by editing /etc/password.
You can add lines to /etc/passwd such as：
src：x：32767：32767：/usr/src：/bin/false
This creates a user src that cannot log on with a home directory of
/usr/src. Now ~src can be substituted almost anywhere for /usr/src.
It is frequently useful to create similar shortcuts for frequently
used long and difficult paths.
Alternatively， you can create symbolic links in your home directory
to common targets：
cd ~
ln -s /usr/src src
Now ~/src can be used anywhere instead of /usr/src.
LINKS
Hard links， symbolic links， aliases，and home directory shortcuts
are used liberally in Linux. Once you get the hang of them， you
will wish you had them in Windows. Windows has both hard links and
a limited implementation of symbolic links but they are rarely used
because applications and a few Windows tools are confused by them
and behave unpredictably. Windows .lnk files have a vague
resemblance to symbolic links. I use them for several similar
purposes. They do not have the same potential for bad， unintended
consequences under Windows， but they also have less power.
Linux has tools supporting most compressed archives. The ubiquitous
Linux/Unix archive is the tar file. Tar is a Unix archive file that
predates zip files. A .gz （or tgz） extension indicates that the
archive was compressed using gzip. A .bz2 extension indicates bzip2
compression.
Change to the test user's home directory， download， and unarchive
Crosstool. Then， change to the Crosstool directory being extremely
careful about exact syntax：
cd ~
wget http://kegel.com/crosstool/cross tool-0.43.tar.gz
tar -xzvf crosstool-0.43.tar.gz cd crosstool-0.43
The Crosstool readme refers to documentation that can be viewed
with：
lynx doc/crostool-howto.html
CROSS-PLATFORM TOOLSI am building PowerPC 405 cross-platform tools， and there is
already a suitable Crosstool script. There is a matrix on the
Crosstool site that cross-references versions of the GNU tools
against platforms and indicates which combinations can be built
successfully， but not all failures are fatal. Cross-compiling a
Linux kernel is not necessary if you are just developing embedded
Linux applications. If you are porting Linux， or if you are
developing standalone applications for a target， you may not care
about glibc. There are rare instances where it may be critical to
use a specific version of the GNU tools，glibc， and the Linux
kernel， but in most instances， the most recent working combination
for a target is acceptable. Building the most recent ppc405
crossplatform tools can be done with：
./demo-powerpc-405.sh
This will take a large amount of disk space and a long， long time
（hours）
even on a fast processor. Once Crosstool has finished building，
everything is in place to begin embedded cross-platform
development.
The logical first program is HelloWorld. Photo 2 is a minimal
standalone Hello World for the Pico Computing E1x cards using the
Xilinx UartLite UART.
If coLinux is installed with cofs1 assigned to C：\ and mounted as
/windows under coLinux， you can easily copy files between Windows
and Linux. If you have the coLinux network set up you can install
samba under coLinux and map the coLinux disk to a Windows drive
letter. Either way， where possible， you can use your favorite
Windows tools to a large extent while doing embedded Linux software
development. Conversely， I frequently use an open coLinux
ssh（putty） session to use Linux tools-such as grep， sed， find，
sort， and uniq-as well as the excellent scripting afforded by Bash
to perform and automate tasks that are more difficult under
Windows.
A note of caution： under Windows，lines in text files are typically
delimited with carriage return/line feeds. In Linux， the newline
（line feed） is used. A large number of Linux tools and a smaller
subset of Windows tools are either aware of this and make
appropriate adjustments or are oblivious to this in a way that
enables them to work regardless. But there are cases in both
Windows and Linux where a text file in the wrong format will cause
unusual errors that are not readily traceable to a text file
format. In general （with exceptions），programming languages and
compilers-particularly those such as GCC that are
cross-platform-are oblivious to text file format， while OS-specific
tools， such as Notepad or scripting languages， tend to get
confused. The vim text editor-available under Linux，apt-get vim， as
well as for Windows（www.vim.org）-reads files in either format
normally and preserves the original format， but it can optionally
convert to either （see Photo 2）。 There are also numerous small
utilities for both Windows and Linux. Listing 1 is an example GNU
Makefile to build the UartLite HelloWorld example using Crosstools.
Eliminating the -DSTANDALONE from the Makefile would create an
ordinary Linux ppc405 executable. Commenting out the definition of
CROSS_COMPILE would result in an x86 version.
Many Makefiles are simpler than this. More information on GNU Make
can be found at www.gnu.org/software/make/. Like almost everything
else I‘ve described， a limited understanding of a few simple Make
commands is sufficient for most ordinary work.
Linux kernel source can be downloaded from the Debian archives
with：
apt-get install linux-source-2.6.18
Alternatively， git can be installed：
apt-get install git-core
And the git repository of Linus Torvald's current development
kernel source can be pulled with：
git clone git：：/git.kernel.org/pub /scm/linux/kernel/git/torvalds/
linux-2.6.git linux-2.6
CROSS-COMPILECross-compiling a Linux kernel only differs in that the target ARCH
and CROSS_COMPILE path need to be specified much like the
HelloWorld Makefile.
I use the shell script in Listing 2 to wrap the kernel Make process
so I do not have to repeatedly type the long paths needed to
cross-compile a kernel. Note that typing ./cross menuconfig will
set up Make for cross-compiling and invoke the standard linux
kernel configuration tool.
A starting point for creating Linux kernel board support for a new
target would be to copy the board support from the most similar
existing target. There are many for each architecture to choose
from.
Adding drivers to an existing target is a significantly simpler
project. The third edition of Linux Device Drivers by Jonathan
Corbet， Alessandro Rubini，and Greg Kroah-Hartman is the"bible" for
developing Linux drivers. Again， using the most similar existing
driver for your hardware as a template can be an effective
shortcut. Linux kernel software and drivers are a moving target：
even LDD3 contains numerous references that are now obsolete. In
addition to using drivers for similar hardware as a template， it
often makes sense to take a careful look at the code for popular
drivers because bug fixes and changes usually show up there first.
Recent Linux kernels provide UIO-user space I/O template driver.
This requires adding the PCI card ID to the template driver，and
then allows a user space program to access the device directly.
This is a fast way to prototype and debug a Linux driver with very
minimal kernel programming.
Building coLinux and the cross-platform development environment has
involved complex commands and options that are not the norm for
embedded Linux development. But the end results are critical to the
objective of supporting embedded Linux development. The coLinux
project does not come with prebuilt coLinux images for embedded
development but it provides the opportunity to do so.
UPGRADES
At Pico Computing， I created a custom coLinux installer that
automates the creation of a minimal cross-platform development
environment similar to the one described in this article with the
ppc405 and MicroBlaze Crosstool， Linux source including Pico E1X
Platform support，as well as other sources and tools needed to start
right into embedded Linux development on the Pico E1X Platforms.
While researching this article， I discovered that this approach is
not unique and several other embedded platforms provide
coLinux-based development environments.
The coLinux development platform I‘ve described provides a workable
base that can be expanded in many directions. All embedded
development tasks can be accomplished on the minimal virtual Linux.
After building the cross-platform tools， the Debian Linux running
under coLinux could be substantially pared down and fit into a
single virtual disk image. Alternately， a Windows XServer， such as
XMing， could be installed and Linux Xwindows clients could run
under coLinux to provide a complete Linux desktop system running
concurrently on Windows （see Photo 3）。
At least one developer at Pico would like to use coLinux primarily
as a black box build service for Windows development tools-using
MSDEV to inject build commands and retrieve results.
I am working to integrate some of the features of coLinux with
hosted embedded development on my target platforms， so my Linux
target has drivers like conet， cofs， and cobd， which enable it to
access resources on the Windows host during development.
David Lynch （dhlii@dlasys.net） is a partner at Pico Computing
（www.pico computing.com）， the owner of DLA Systems（www.dlasys.net）
software consulting，and an architect， with projects ranging from
automated warehouses to embedded OS ports. When he is not working
（playing） with computers， he is busy attempting to automate his
home and coerce his two children away from screens and into the
outdoors to help build their home.
RESOURCEScoLinux, www.colinux.org.
J. Corbet, A. Rubini, and G. Kroah-Hartman,Linux Device Drivers,
O'Reilly Media, Inc., Sebastopol, CA, 2005.
Jeff Garzik's Linux Pages, "Kernel Hackers'Guide to git,"
http://linux.yyz.us/git-howto.html.
GNU Make,
www.gnu.org/software/make/.
Linux Kernel Archives, www.kernel.org.
Linux Kernel Installation,
http://97k.eu/howto/kernel.htm.
Linux Kernel Mailing List FAQ,
www.tux.org/lkml/.
D. Lynch, "How to Port Linux When the Hardware Turns Soft," Linux
Journal,2007www.linuxjournal.com/article/9362.
PuTTY: A Free Telnet/SSH Client,
www.chiark.greenend.org.uk/~sgtatham/putty/.
Vim the Editor, www.vim.org.
Xming Info,
www.straightrunning.com/XmingNotes/.
SOURCECrosstool
Dan Kegel
http://kegel.com/crosstool
;){kind=link}