blueDonkey.org

This Web

All Webs

blueDonkey.org

Other Sites

Roll-Your-Own or Distribution?

• What You Need
  • Kernel
  • C Runtime Library
    • uClibc
    • GNU glibc
    • Diet libc
    • Size
  • Userland Binaries
  • Boot Strategy
    • RedBoot
    • U-boot
    • PMON
    • LILO, GRUB, ROLO, LinuxBIOS
  • Host Development Tools
  • Kernel Extensions
• Distributions
  • Commercial
  • Free
    • Debian & emDebian
    • SnapGear
  • Hardware Vendor
• Roll-Your-Own
  • Getting Everything
  • Tracking Updates
  • Configuring & Building

What You Need

Kernel

The kernel, while being at the heart of any Linux system, is far from the whole story. In the VxWorks world, it is hard to see the separation between the kernel, the C runtime library and even the applications in many cases since they are all linked into a single binary that is booted on the target system.

In a Linux system, the kernel is more clearly defined, and can be more easily upgraded as an independent component if need be. Your choice of kernel will depend on a number of factors:

• Whether your chosen CPU has an MMU or not;
• The version that comes with your system board (or reference board if you are designing your own hardware);
• The latest version that supports the CPU you are using (some CPU ports lag behind the current version a little);
• The version your distribution supports.

In any case, for an embedded design at the time of writing you want to be looking for a recent 2.4 series kernel; 2.4.20 woudl be my preference if it is available for your CPU/board, but I've seen distributions using 2.4.17, 2.4.18 and 2.4.19 and all work well (I am using 2.4.19 on my iPAQ for example as that is the latest version supported by the Familiar distribution).

If your chosen CPU does not have an MMU, then look at uClinux, available from http://www.uclinux.org. This is not so much a different operating system as it is additional platform support for Linux to allow it to run on MMU-less hardware. Indeed it is available as a patch to apply to a standard Linux kernel source tree (although getting it pre-patched would be my recommended approach). There are ports of uClinux to many families of MMU-less CPU, including Motorola's DragonBall and ColdFire CPUs, ARM's 7TDMI cores, Intel i960 and Hitachi's H8 series to name a few.

C Runtime Library

With VxWorks you did not have much choice of C (and C++) runtime library. In the Linux world things are not so rigid: you have a choice of C runtime library.

uClibc

For most embedded designs I would recommend uClibc, available from http://uclibc.org/, simply because of the wide platform support and clear focus on embedded system usage. In particular, it attempts to keep the library as small as possible while maintaining compatibility with the GNU glibc.

At the time of writing, uClibc supports Alpha, ARM, i386, i960, h8300, m68k, MIPS, PowerPC, SH, SPARC, and v850 processors, as well as both Linux and uClinux kernels.

uClibc uses the same LGPL license that GNU's glibc uses. This means that it can be freely linked with your proprietary application code without rendering that code subject to GPL (of course, if anything else in your application is subject to the full GPL, then that will still apply).

GNU glibc

Since you are using Linux, the full GNU glibc is available for use. This will ensure the best possible compatibility with open-source applications since it is the most widely used C runtime library in the open-source community. It is also a very complete and standards-compliant library. The problem from an embedded perspective is that it is also a very large library, and difficult, if not impossible, to trim down.

Diet libc

Diet libc is another C runtime library with an embedded design goal. Unfortunately, it is licensed under the full GPL which makes it unsuitable for commercial use. While the author does mention the availability of other licenses, given the availability and platform support of uClibc, it seems unnecessary to go to the trouble of negotiating alternative terms.

Size

The table below shows a comparison of the sizes of the libraries with typical configurations. It is important to note that neither uClibc nor Diet libc achieve any kind of miracle: a big part of the reason that they are smaller is because they contain less code. That said, much of the code in glibc is probably not going to be used by your system, so this is not such a compromise.

Insert table with size comparisons here

One other important consideration when looking at the size of the C runtime library is whether or not your CPU has an MMU. If it does not, then sharing libraries is not possible. That usually means two things:

1. All applications are statically linked with the libraries they need;
2. When running, code is not shared

For this reason, MMU-less systems tend to have larger flash and RAM requirements than those with an MMU. Something to consider when making hardware decisions.

Userland Binaries

When it comes to userland (i.e. the components of a Linux system that do not run within the address space of the kernel), most VxWorks users are going to be breaking new ground. Only those with experience of VxWorks AE will have encountered user-level binaries for VxWorks.

That said, there are some tools for VxWorks that could be logically considered to be the equivalents of the Linux userland binaries I am discussing in this section: the target resident shell and loader being two good examples. Linux systems will also tend to have a shell and a loader, though the usage of the latter will be hidden in most cases. Linus systems also tend to have a number of other userland binaries, e.g. cp, init, insmod, ifconfig, ls, mount, ps, rm.

As with the C runtime library, pretty much any of the standard implementations of these tools could be used, but as with the full GNU C library they were designed foe desktop and server systems, not embedded systems. Instead, a single application called BusyBox, available from http://www.busybox.net, can provide all of these functions, and more.

Here is a comparison of some commonly used VxWorks shell functions, and the tools provided as part of BusyBox. One other thing to remember, each BusyBox tool can be added or removed individually (some even have internal scaling features too). This is not usually the case with VxWorks, where shell functions tend to be configured in relatively large groups.

VxWorks Function	BusyBox Command	Description
cd	cd	Change default directory.
checkStack	-	Show stack usage for each task.
copy	cat	Copy from file/stdin to file/stdout.
cp	cp	Copy a file.
d	-	Dump physical memory.
devs	ls /dev cat /proc/devices	List known devices.
h	history	Show shell history.
i	ps	Generate a list of running tasks/processes.
ld	insmod	Load a .o file into memory. insmod serves this purpose for the kernel space in Linux; there is no user level equivalent from a shell.
lkup	grep sym /proc/ksyms nm /proc/pid/exe	Lookup a symbol address by name. /proc/ksyms contains a list of kernel symbols. For user space, nm provides symbol information from the executable.
ls/ll/lsr/llr/dirList	ls [opts]	Generate directory listing.
m	-	Edit physical memory.
mkdir	mkdir	Create a new directory.
mv	mv	Rename/move a file or directory.
pwd	pwd	Print current default directory.
rm	rm	Remove a file.
rmdir	rmdir	Remove a directory.
sp	executable name	In VxWorks, sp spawns a new task. The nearest equivalent for a Linux system is starting a new process.
spy	top	Display CPU usage statistics.
td	kill	Kill a task/process.
ti	cat /proc/pid/*	Show more information about a running task/process.
tr	kill -CONT	Resume a stopped task/process.
ts	kill -STOP	Stop a running task/process.
unld	rmmod	Unload a .o file from memory. As with ld/insmod, rmmod unloads a kernel module, but there is no user level equivalent from a shell.
version	uname -a	Print operating system version information.

In addition to those shown in the table, BusyBox offers many more tools that VxWorks has no shell equivalents of. These include such operations as mounting file systems on devices, file transfer protocols, network configuration and management tools, and a number of shells with varing size/feature tradeoffs. All told, there are 133 possible comands that may be included in the BusyBox executable.

Boot Strategy

With most VxWorks systems, booting is either handled by the VxWorks bootrom image, or the kernel itself is linked with a small routine to initialise the CPU and memory controller, then copy the kernel from ROM to RAM, optionally decompressing it on the way.

For Linux the steps are pretty much the same, but there is not a single tool that performs the task. For many commercial boards, including semiconductor manufacturer's reference boards, a simple boot loader is provided. Increasingly these include the special features to simplify the booting of Linux systems, but even if they don't they will normally be able to boot at least one configuration Linux.

In addition to these loaders, there are some loaders that are available in source form, making them ideal choices for custom hardware (although if your custom hardware is based on a semiconductor company's reference design, they will often provide source for their boot monitor as well, in which case using that would be recommended).

RedBoot

Based on the GPL'd eCos operating system, RedBoot is the boot loader that supports the most architectures. It is able to handle booting from networks (useful during development) as well as from flash partitions. In fact, it has a relatively advanced flash management system which is also supported by the Linux kernel (making for very simple flash partition management).

RedBoot may be obtained from http://sources.redhat.com/redboot.

U-boot

The only real competitor to RedBoot in the open source loader arena, U-boot supports most of the architectures & CPUs likely to be in found in mainstream embedded devices (PowerPC, ARM, MIPS and i86), and over 100 commercial boards.

U-boot can be obtained from http://sourceforge.net/projects/u-boot. Earlier versions for PowerPC (PPCboot) and ARM (ARMboot) may be obtained from http://ppcboot.sourceforge.net and http://armboot.sourceforge.net respectively, but all new work is on the U-boot project.

PMON

PMON is a very simple loader and monitor for MIPS that can be found on a number of MIPS reference boards. The PMON code base is rather old now, supports relatively few boards and is not being actively worked on by a single project team. The source code is still available from http://www.carmel.com/pmon/, but unless your board manufacturer provides PMON (and the source for their port of it), using it for new designs does not seem to be the way to go.

LILO, GRUB, ROLO, LinuxBIOS

For the x86 world, there are numerous loaders. LILO and GRUB are both BIOS loaders (i.e. they need to be booted into memory by a standard PC BIOS). ROLO and LinuxBIOS are both BIOS replacement loaders (i.e. they go directly in flash, replacing the PC BIOS).

The choice of BIOS loader or BIOS replacement will depend on your hardware. If you are using conventional PC's either in the final system, or simply as convenient hardware platforms for development, LILO or GRUB would probably be the best choice. The others are more suited to custom designed boards (where no BIOS exists), or to boards designed for embedded use where the necessary documentation about the board will be made available.

LILO and GRUB can be obtained from http://brun.dyndns.org/pub/linux/lilo/ and http://www.gnu.org/software/grub/ respectively. ROLO and LinuxBIOS from ftp://ftp.elinos.com/pub/elinos/rolo/ and http://www.linuxbios.org/ respectively.

Host Development Tools

TBD

Kernel Extensions

TBD

Distributions

Commercial

There are several companies in the marketplace that specialise in embedded Linux distributions, including all the tools, so that they are much like the environment provided with VxWorks. When evaluating these products (which you should defintely do), remember that you will be paying significant sums of money for them. They might be based on Linux, but they are not free software, so judge them as you would any other commercial offering. In particular, consider the following:

• Availability and quality of technical support (try to find existing customers to ask about this);

• Quality and range of tools included (are they just bundling open-source tools, or have they done some work to integrate them together seamlessly);

• Availability of kernel extensions (e.g. patches to add closer to real-time performance to the kernel);

• Financial stability of the company (you want to be sure that they are still in business as you prepare to ship your product, and preferably beyond that).

Most have evaluation copies of their products available, though you may need to call to obtain it. Any that do not have an evaluation license should be crossed off the list immediately.

Free

For desktop and server systems there are numerous freely available Linux distributions, or distros. The same is not true of embedded distributions.

Debian & emDebian

The Debian project, one of the better known desktop Linux distros, also has the beginnings of an embedded distro called emDebian. While it is far from complete today, the project does make available pre-compiled cross-development toolchains (for x86/ARM and x86/PowerPC at the time of writing) and cross-development tools in both Debian package and RPM formats.

emDebian packages can be downloaded from the project's web site at http://www.emdebian.org/.

SnapGear

SnapGear provides both Linux and uClinux for a number of boards, complete with cross-development tools and a selection of applications. The CD image, downloadable from their website at http://www.snapgear.org, contains binary toolchains for x86 hosted cross-development, as well as sources for Linux & uClinux. All of these are combined with a simple to use graphical configuration system based on the Linux kernel configuration tool.

As free embedded linux distributions go, this is the most complete I have seen. The only notable thing missing from the SnapGear distro is support for any PowerPC devices.

Hardware Vendor

Many CPU silicon vendors and reference board vendors now include a Linux distribution. Some are simply including evaluation copies of a commercial distribution with support for their board; others have put together their own distribution.

If your board came with an evaluation copy of a commercial distribution, check carefully what licenses are required to use that software for your development work. As with an evaluation copy of a commercial RTOS, use of these for anything other than evaluation usually requires a paid-for license.

If a board/CPU vendor has their own distribution, check whether there are any special licenses associated with software they have provided. While anything linked with the kernel must be covered by the GPL, user-level applications, shared libraries, loadable kernel modules and boot loaders may have alternate licenses.

Roll-Your-Own

Getting Everything

Tracking Updates

Configuring & Building

-- JohnGordon - 16 Aug 2003