EEPW论坛

The Embedded Linux OS Bill Weinberg of MontaVista Software reviews Linux’ ability to meet the needs of real-time embedded systems. Today, a number of vendors, including MontaVIsta Software, are enhancing Linux by adding capabilities designed to address the requirements of embedded systems. Such core enhancements include: Scaling the Linux kernel footprint memory down to 0.5 megabytes Supplying cross development and kernel configuration tools Supporting high-integration CPUs and associated peripherals Augmenting Linux performance with options for real-time response Linux also addresses an Internet Appliance's demanding hardware support requirements with support for a wide range of devices found in and required by wired embedded applications, including: Serial Interfaces (single and multi-channel) for local connection, debug consoles, and PPP modem-based networking Magnetic and solid-state storage (SCSI, IDE and proprietary interfaces) 10/100 megabit Ethernet network interfaces Multimedia/streaming interfaces, for sound, video, etc. USB, Firewire, and I2C connectivity Linux also offers developers well-understood, standard user interfaces, promoting both the porting of existing software to Linux and the development of more general applicable software on Linux, regardless of underlying CPUs. The pragmatic, open, portable approach to Linux programming, and the anti-forking philosophy of the open source movement (as well as excellent performance) make Linux the favored candidate for the "universal" platform for next-generation applications. Flash Memory Many classes of embedded device today employ so-called "flash" memory - in-place reprogrammable ROM, to afford their application more options for booting and saving data. OEMs also choose flash over mask ROM when post-deployment upgrades may be required. Flash technology comes in a variety of types and outward form factors. Flash devices themselves can be divided into several categories, describing essentially the resolution of programmability and erasure (memory cell vs. block). Some look like pure clones of their EEPROM predecessors, and some present disklike interfaces for programming. An important reminder - when code is programming a flash device in-place, that device typically cannot also deliver up read data, even from another block, so self-modification while executing inplace is not possible. The most basic flash form factor is the chip, available from vendors like Intel,AMD, Motorola, Philips, and others. The most basic devices appear as linear contiguous memory, while some specialized devices have a block interface more reminiscent of a disk drive. Some devices fit neatly into older byte-wide EPROM sockets, while newer devices present their own unique pin-outs and packages. Flash devices also find their way into the peripheral sets built into high-integration micro-controllers, like Motorola's PowerQUICC devices, IBM PPC 40x family, and various MIPS, StrongARM derivatives. Flash chips are often collocated into a subsystem, sold as an add-on boards or modules, from vendors like M-Systems, Sandisk, and others. These subsystems can appear as ISA or PCI cards, PCMCIA cards, or more conveniently, can take the form of a solid-state version of an IDE or SCSI disk, even down to the outward form factor. The term "flash file system" usually appears on developers Internet appliance checklist, yet actually can refer to five distinct types of technology and support: 1. Boot from Flash With linear memory flash devices, the resident mechanism for booting from mask ROM (SysLinux or LILO) can roll an executable image from the device into RAM and execute without recourse to special drivers or disk-emulation algorithms. Programming the (compressed) boot image into the device on the production line or work-bench may impose a slightly greater challenge, since many flash vendors do not handle Linux ELF files, with extreme cases requiring the embedded Linux developer to leverage WindowCE or DOS tools just to program an ornery flash device! If the device only presents a disk emulation interface, the embedded Linux developer has two choices: if the interface fully emulates IDE or SCSI, simply use off-the-shelf LILO to boot as though from magnetic media. If, however, the block-oriented device does not comply to a standard disk interface, then a tailored read driver will have to be embedded into the boot loader. 2. Flash-based parameter storage Many applications require only a small amount of local non-volatile storage for saving key parameter information, such user preferences, localization settings, or network configuration information. In such cases, a full-blown file system is usually not needed, and system and/or user application code can access linear flash for reading as though it were any other type of shared memory or memory mapped device - with mmap() calls. Writes to flashbased parameter blocks would have to go through a driver (or be performed in-line : bad style!) in order to conform to the particulars of the device's write cycle. As above in "Booting from Flash", if the device presents a non-linear interface, then either a special driver will be needed, or it's time to implement rotating media emulation. 3. Rotating Media Emulation The most common interpretation of "flash file system" equates with use of these solid state devices in lieu of traditional SCSI and ATA/IDE hard disks. The emphasis here is not upon physical form factor, but on how the system software views the device. With embedded Linux, a flash file system appears identical to a conventional rotating media file system: a block driver in the /dev directory facilitates the initialization (mkfs), mounting (mount), checking (fsck) and creation of directories and files via inodes. Even non-Linux file systems, like FAT and MacHFS, can be mounted and utilized in flash. All detail is hidden from the OS and from applications by the flash driver, which must either "slice" a linear device up into sector-size blocks and implement superblock(s), or must make a flashnative block interface conform to the block sizes and infrastructure of the Linux or VFS file system being emulated. The fact that disk reads merely copy from memory mapped locations, while writes require a particular access sequence or protocol is not really so very different from working with magnetic media. In fact, a flash disk driver will be simpler, not having to worry about DMA, chip set issues, master/slave architectures, or disk topology issues like platter number and interleave counts. If the flash device presents a 100% SCSI or IDE compatible interface, then even existing /dev/hd* and /dev/sd* drivers can suffice. 4. Wear Leveling Unlike RAM and magnetic rotating disk drives, flash devices have relatively short, finite writecycle lives. Five years ago, when these devices first appeared on the market, total write cycle lifetimes ranges from 1,000 to 10,000 writes per address cell or erasures per block, making it easy for a run-away program or a pernicious programmer to burn out the flash, sometimes in a matter of seconds. While flash technology has advanced significantly, augmenting these programming cycles by one or two orders of magnitude, flash memory still suffers from this same basic limitation, especially when compared to magnetic disks. To compensate, a layer of "wear leveling" software can be injected at the file system level, into the driver, or even into the device itself, whereby address blocks are carefully recycled. The de facto proprietary standard for wearleveling technology comes from M-System, suppliers of Disk-on-Chip.A wealth of open source technology for flash file systems and write-cycle enhancement at http://www.linuxmtd. infradead.org/ on David Woodhouse's "Memory Technology Device (MTD) Subsystem for Linux" project web page. 5. Field Upgrading The use of flash also facilitates the upgrade of both application and system-level software inplace. For application code upgrades, the Linux process model and file system make fielded upgrades a snap: just replace the executable images of program code and restart. The same is true for dynamic libraries, but new code will not be loaded until the last referencing program terminates and the old shared image is unloaded. Upgrading system-level code in place presents slightly different challenges: while a userlevel upgrade utility can induce the unloading, replacement, and reloading of Linux kernel modules, replacing statically linked drivers and modules, and the kernel itself, is substantially more difficult, and cannot be accomplished without rebooting the system in question. In general, a boot-ready statically linked kernel must be downloaded and installed in a bootable location, and a shutdown issued. As with hosted systems, the previous, presumed stable kernel must be kept in place as a fallback if the new installation fails to boot or otherwise malfunctions. Many developers employing flash design in this type of functionality into their boot firmware and their embedded Linux system configuration. Off-the-shelf tools for building field upgrade capability are available from a few vendors - GoHead software, for one. TCP/IP Networking Probably the first Internet Appliance was the now-famous (or infamous) MIT Coke machine. wherein ingenious (or lazy) grad students used their local network to check on the supply of soft drinks in the vending machines in another part of the building. The MIT story echoes the fact that the Internet Protocol (IP) family grew up around UNIX-type systems and became the mainstay of the Internet that we have today. Given the level of support and the excellent performance of the Linux TCP/IP stack, it is no surprise that scores of developers are choosing to embed Linux and Linux networking in the next generation of Internet appliances. The Internet Protocol builds up a series of abstractions that hide the need for understanding the physical and transport mechanisms at the application level, and the need for individual network client nodes to have knowledge of the location of the other nodes (systems) with which they communicate. Internet Protocol data can ride over serial and phone lines (SLIP and PPP) or over network media (e.g., Ethernet). Applications can count on the protocol infrastructure to monitor delivery (TCP/IP) or implement their own guarantees (UPD/IP). Internet Protocol also supports a series of higher-level protocols for specific operations: moving files over an IP network - FTP (File Transfer Protocol); packaging e-mail messaging for network transmission - SMTP (Simple Mail Transfer Protocol); downloading text, graphics, and resources for graphical rendering from a remote server - http (HyperText Transfer Protocol); and even monitoring the health of networking and system resources - SNMP (Simple Network Management Protocol). The BSD/BSD-Lite sockets interface present in Linux, along with scores of IP networking components and utilities offer the shortest path to "embedding the web" in post-PC devices. Linux includes standard client and server configurations for popular networking functions like telnet/telnetd, ftp/ftpd, httpd, routed, inetd, NFS, Samba, PPP/SLIP, etc. Open source project and commercial third parties extend this set with offerings for VPNet, IOOP (CORBA),VoIP, and emerging protocols. Other Networking Many Internet appliances can be characterized as "tiny servers" for data storage, printing, web access, and other functions. While IP networking dominates, other data networking protocols are readily available for Linux, including IPX and AppleTalk, and specific routing protocols for when Linux is used as a "housekeeping" OS for routing devices. Putting aside the convergence of voice and data over IP networks, there are still a huge number designs that need to implement "traditional" telephony protocols like ATM, SS7, X.25, etc. These protocols and their implementations have most often been developed by communications systems manufacturers, and for the last few years by third parties like Trillium, Harris and Jeffries, and Spider Software, who are now making versions available for desktop and embedded Linux. While most identifiable Internet appliances do not require these infrastructure technologies, convergence and the redistribution of functionality moving out from the edges of the Internet and the voice telephone network are driving new and old protocols into unexpected places. Embedded GUI Web Paradigm The flexibility and potential cost savings of web-enabled devices running Linux presents a very attractive proposition for cost-sensitive developers of consumer products. Cost saving come from both removing the need for physical switch panels on the device itself for traditional appliances and machines, and from providing generic web-based interfaces in place of proprietary, client-specific computer interfaces (e.g., for Windows or UNIX-based X/Motif systems) that are notoriously expensive to develop and maintain. Rather than building device-specific local control panels, and application-specific client interfaces for multiple computing hosts, "headless" web appliances can serve up web pages and Java applets with the needed data displays and control inputs into platform-independent Netscape and Internet Explorer browser windows. Whereas embedding a local user interface, video controller and drivers, and other interface components like embedded browsers and Java virtual machines can eat up in excess of 16 megabytes of memory, an embedded web server-based interface can fit into under 200 Kbytes of RAM. This eighty-fold savings in memory space results either in lower cost of goods sold or more room for feature-rich applications code. Embedded Display Support Embedded graphical user interfaces seldom present the high resolution, rich color palette, and fine detail found on most any desktop system today running X.11 (or even Windows!). A different set of economies influences the choice of output device on most embedded devices and Internet appliances: physical size constrains total resolution, unit price limits color depth of LCDs and available memory for complex display software (X can add 8-16 MB to an application footprint), and not all applications need more than simple monochrome graphical output. Various options now exist for Linux-based embedded GUI technology. Long-time proprietary vendors like Mojo Designs and Swell Software now offer Linux versions of the Eyelet and PEG interfaces as binary products. The most promising open source embedded GUI is Microwindows, from the Microwindows Project (http://www.microwindows.org). Microwindows is easily adaptable to different video chips and display types, and offers support for a variety of input paradigms, such as touch screen and pen-based input. Interestingly, Microwindows offers two distinct APIs to its underlying Nano-GUI core: Linux developers are likely to use its Nano-X interface, an X.11 work-alike, while developers with legacy Win32 / WindowsCE code will benefit from Microwindows' large subset of those APIs. Microwindows already boast a number of highly visible ports of applications to its interface, most notably the Opera browser, and even KDE! Status of and Sources for Key Technologies Each of the design domains in the application table above demands a particular mix of technologies and components to complement and augment the embedded Linux platform itself. BlueTooth Wireless Interface Yes Yes Axis Communications. See also http://www.bluetooth. com/ Browser Embedded HTTP client Yes Yes / No Netscape/Mozilla is very large. Others include Opera, Espial, and SpyGlass Device Mosaic DSL Digital Subscriber Line client s/w Yes No Silicon Automation Systems FireWire IEEE1394 Serial Interface Yes No Multiple sources; currently available from InToto GUIs Embedded Graphical Interfaces Yes Yes / No Microwindows open source project; Trolltech QT; MoJo Designs Eyelet; Swell Software PEG HTTP Web Server Yes Yes / No Apache standard. Others include GoAhead, Magma IrDA Infra Red Yes Yes See the Linux IrDA project at http://www.cs.uit.no/linux-irda/ Java Embedded and Personal Java interpreters and JITs Yes Yes / No At least a dozen options MPEG Video Encoder/Decoder Yes Yes / No Open source encoders and decoders exists, with premium binary products from vendors like PacketVideo Power Management Disk, display, CPU, and motherboard quiesce and sleep Partial Partly New power management options exist in the 2.3 kernel, mostly to address notebooks Real Audio Streaming Audio standard Yes No Real Networks Telephony Protocols ATM family, SS7, etc.Yes Varies Premium proprietary stacks available from Trillium. H&J, and Spider Software; new "Open IP" coming TWAIN Scanner interface s/w Yes Yes Various open source drivers USB Peripheral Interface Yes Yes / No Open source USB exists for basic peripherals like mouse/keyboard. See the Linux USB project at http://www.linux-usb.org/. In depth support from InToto, Phoenix Technologies. VPN Virtual Private Network Yes Yes / No Several open source VPN clients and gateways exist for enterprise Linux.Vendors like Intoto offer embedded VPN. Embedding Java in Internet Appliances Many embedded Linux developers feel that the promised WORA (Write Once, Run Anywhere) functionality in Java is actually better realized by Linux with its standard APIs and portability. However, while Java might not yet be reaching its full potential, it often finds itself spec'd into the designs for Internet appliances. Rationale for using Embedded and Personal Java in this context include: Using Java as the graphical user interface (with AWT or Swing) Supporting a Java-enabled browser Leveraging Java for OEM and after-market add-ons Serving up Java applets as part of an HTTPbased web server GUI Caveats: First, versions of AWT and Swing already exist to run under various versions of X.11.When Java is used as the sole GUI platform in an embedded system, a special AWT frame buffer driver controls the graphical output, and X.11 is out of the picture; it is nearly impossible to attempt to use the two in tandem (X and Java direct video output drivers). Second, a Java enabled browser will still rely on a resident GUI, be it X.11 or Microwindows, or what have you. Some designs I have seen call for both the execution of Java classes (applications) with their own GUI as well as the use of a Java-enabled browser. However, unless that browser is written in Java, the GUI upon which the browser relies and Java's own output will be in conflict. Better that both the Java run-time and the browser in question be ported to an embedded GUI, and both use its display facilities. Third, some designs, e.g., automotive feature boxes, strive to provide an extensible platform using either Personal Java or Embedded Java in a wired appliance, with an eye towards a downstream integrator adding applets/classes to customize the product (in this case for a particular car or local market). The challenge to providing such platform functionality is that the downstream Java programmers may attempt to implement enterprise level functionality not available in a strippeddown VM. Lastly, when Java is used to implement a GUI on a client machine (i.e., the appliance is an applet server and a client workstation uses a browser to display its HTML/Java output), no particular Java functionality is really needed on the embedded server side: applets end up being amorphous documents served up by the embedded web server, without regard to their internal type or workings. Java Availability for Linux Embedded Linux, sharing APIs and most overall functionality with the desktop and server versions of Linux, is blessed with a wealth of available Java resources for use in Internet appliances. Be aware, however, that a great variety of specification conformance (Personal Java v.s Embedded Java vs. enterprise dialects) are supported by interpretive and compiling virtual machines that implement JDK specifications as old as 1.0.2 and as new as 1.2. Some implementations are open source, some not. Some offer graphical output, some anticipate delivering soon, and some just leverage de facto AWT and Swing from Sun. Some virtual machines continue the "green threads" philosophy of providing their own schedulers, while others bind Java threads to native Linux threads. If you decide to use Java in a Linux-based Internet appliance, be sure to outline ALL the entailments of how it will fit into your system and application before starting your shopping exercise.