【正文】 Dedication to a small number of tasksBootstrapping is one the first areas that has to be addressed when you are first getting an embedded system up and running. What happens first when the hardware is powered up? Users and developers who have only dealt with desktop puter systems rarely, if ever, have to think about this topic but it is of the utmost importance in an embedded system. Most embedded systems boot from some type of diskless media. The media can be something like Flash memory, which is read/write, or read only memory such as an EEPROM. Alternatively, the device may not boot from internal media at all, but instead download the operating system image over a network when it is powered up. RAM can be used to store data while the system is running, but a persistent, nonvolatile media such as Flash needs to be available to store data while the system is powered off. The reason that embedded systems typically don’t use disk based media such as a hard drive is for mostly for power consumption and speed reasons. Hard disks consume a lot more watts that are required to drive Flash memory and are significantly slower. Economically, hard disks certainly beat Flash in a cost per byte parison but embedded systems rarely needs the multigigabyte storage of today’s hard drives and a few hundred kilobytes of Flash is a much better solution.The Basic Input/Output System (BIOS) of a PC is a significant piece of software that goes pletely unnoticed by most people. Its job in life is to initialize the builtin hardware in the PC and provide primitive operations for municating with that hardware. A typical desktop OS, including Linux, is built on top of the BIOS and takes full advantage of it. In an embedded system you don’t have the luxury of BIOS and you must manually initialize your hardware to a workable state before the OS kernel starts running.This isn’t as big a problem as it seems. Very few embedded hardware platforms are as plex as the motherboard architecture of a typical PC and they are usually much easier to configure. Many times the manufacturer of the hardware provides sample code that quickly is adapted to get the system up and running.As we mentioned earlier, embedded systems don’t need the huge amounts of memory and storage that is present on most desktop. Some embedded systems run with only a few hundred bytes of RAM and ROM, and most don’t utilize more than a few megabytes. This is a far cry from the seemingly infinite resources of desktop systems, and is one of the biggest stumbling blocks for desktop programmers transitioning to embedded systems.Memory management is another big area that distinguishes an embedded system. Since storage requirements are tight, there’s no place for the swap file usually required by a virtual memory system. Additionally, embedded systems run on a variety of microprocessors, some of which do not have the memory management unit necessary to implement virtual memory. As a side note, it is interesting to note that embedded Linux meets both these requirements. Any Linux system can eliminate the swap file requirement by setting the size to zero when the operating system image is built. Additionally, Linux has been modified so that it does not require an MMU. uCLinux runs on a variety 32bit microprocessors that do not have an MMU and use only physical memory addressing.Finally, an embedded system typically is tailored to perform a dedicated series of tasks. They may not have any user interface other than a few indicator lights. The user cannot install and run any custom software other than that which the system was originally designed to run. This is in direct contrast to a desktop puter system where users routinely install and run custom software packages and can acplish tasks never considered by the system designers.Conspicuously missing from this list is real time performance. Although it is a hot topic in the world of embedded systems it is not a general requirement. Many embedded systems have no hard or soft realtime requirements and are perfectly satisfied with general, nondeterministic performance of the OS. Embedded Linux does have the option of using a realtime subsystem, as we’ll discuss in a later section.Details of embedded LinuxIn the next few sections we will look at the details of embedded Linux in six specific areas. The areas were chosen specifically to try to cover the endtoend usefulness of Linux in an embedded system. The goal was to address issues that would e up in all stages of the system lifecycle, from specification to maintenance. Some of the issues, such as economics and technical support, are decidedly nontechnical but nonetheless important in the overall development of a system.ConfigurabilityBeing able to tailor the OS image to the particular needs of a device is a very important feature in embedded systems. You don’t want to include megabytes of code that for GUI support if your system doesn’t require it. Whittling the kernel down to the smallest possible size that has all the support you need is one of the first tasks a designer faces after the hardware is up and running, and it can be a very difficult one.Configuring an embedded Linux system is not much different from configuring a desktop Linux system. The OS build process uses a simple text file to select which ponents to include. The installable module support is then used to load the selected subsystems at boot time. It is also possible to dynamically load and unload modules during runtime, which allows you to tailor the system to use optional ponents only when necessary.This configuration ability is very useful in an embedded system. Not only does it allow you to dynamically add and remove support for optional pieces, it also allows you to do partial updates. By splitting your system into several individually loadable modules instead of a single monolithic on