Embedded system designs that employ the x86 architecture gain access to the powerful yet low cost technology, tools, and software of the PC market. But the PC’s requirement for legacy support creates a software burden for embedded designers that is rooted deep in the BIOS startup firmware.
A BIOS designed with embedded applications in mind, however, can not only relieve this burden by simplifying configurability, it can help increase system reliability and improve device security.
For embedded system developers, adopting the PC architecture as a design foundation brings with it a compelling set of advantages. The semiconductor technology supporting the architecture is both powerful and diverse.
Compatible processor choices range from extremely low-power versions such as the Intel Nano to state-of-the-art multicore devices. Peripheral device options cover a wide range of networking, media, user interface, and general-purpose I/O functions.
In addition to the hardware support, the PC architecture enjoys an unparalleled level of software support. Protocol stacks for virtually every communications channel are available from multiple sources, as are hardware drivers for both peripheral components and a wide range of I/O module types. On top of that ride several different operating systems and a multitude of applications programs for both embedded and information technology uses.
System development using the PC architecture also has wide support. A vast range of development tools in several different languages are available for PC-based software development. In addition, there is substantial programming expertise available in the industry for these languages and tools.
All of these benefits come at a relatively low cost. The low cost stems partly from the high production volumes and resulting production efficiency that the hardware enjoys. Intense competition among a wide range of hardware and software vendors also works to keep costs low.
Unfortunately the PC architecture also brings with it several attributes that create problems for embedded applications. One of the most obvious is the long startup time needed to make applications available for use, especially when running under Windows. A PC-based embedded design running a Windows operating system can take 30 seconds or more to become functional after power on.
This long boot time is not entirely the result of operating system requirements, however. The standard PC BIOS (basic input output software) requires as long as 13 seconds to complete discovery and initialization of the PC’s hardware. Loading of the OS and its custom settings, followed by loading of the application, takes up the remaining time (see Figure 1).
Figure 1 – Embedded designs based on the PC architecture exhibit excessive boot times - even without the operating system - creating acceptability issues for potential mainstream customers.– Embedded designs based on the PC architecture exhibit excessive boot times - even without the operating system - creating acceptability issues for potential mainstream customers.
Such long delays between activating a device and it becoming ready to use create an availability issue unacceptable to mainstream users who represent the bulk of the market. Unlike early adopters, these mainstream users are not interested in technology itself. All they want is the function that the technology is to provide. These users have expectations that, like the telephone, a device will begin working almost immediately when activated.
Start-up delays are not the only unfortunate attribute of the PC architecture running a Windows variant. Such devices also exhibit reliability and availability limitations. Windows-based systems are notorious for their vulnerability to attack through a network connection.
They also suffer from occasional software glitches that cause system crashes. Often the only resolution to these crashes is to reboot the system which, given the long boot time, compounds the availability issue for PC-based designs.
From an embedded design stance, the PC hardware architecture is also excessively rigid. Market demands for backward compatibility during the PC’s evolution have cemented the x86 as the central processor. In addition, compatibility demands the presence of many legacy hardware elements, preventing the embedded developer from trimming these often unneeded elements out of a design.
Fortunately, there is an opportunity for reducing or eliminating many of these concerns. That opportunity lies with the BIOS. The BIOS handles foundation system tasks such as hardware initialization and loading of the operating system. It also, however, provides a variety of essential services to the operating system. These connections at both the lowest and highest system levels mean that the BIOS can affect all aspects of system behavior, so modifications made there will have ripple-through results.
A variety of vendors offer BIOS software for the PC architecture. Many of those offerings, however, condition the system for traditional information technology (IT) applications of the architecture.
For example, an IT-oriented BIOS expects to initialize a keyboard controller, set video display options, and wait while a hard disk drive (HDD) spins up before the BIOS can access the OS files stored on disk. An embedded system leveraging the PC architecture, however, may not have any of these hardware elements.
Unfortunately, most IT-oriented BIOS implementations have hard-coded these system policies and attributes that keep the PC architecture operating solely as a PC. This hard coding creates significant challenges for developers seeking to adapt the architecture to embedded applications. Removing or bypassing the unnecessary code adds both development time and risk.
Embedded BIOS Solution
What embedded system developers need is a BIOS designed for configurability. Phoenix Technologies’ Embedded BIOS(R) with StrongFrame(R) technology is one such offering. It was designed from the ground up to simplify the designer’s task when modifying the BIOS for different system behaviors, different hardware configurations, and even a variety of choices in the operating system.
The embedded BIOS is also designed for extendibility. System developers can add functionality to the BIOS without any rewriting of the original source. The BIOS can also run portable applications such as a basic web browser as part of the firmware. The BIOS and its additional functionality also operate independently of the OS (see Figure 2), so that such applications can be available to the user before the OS loads or in the event of an OS crash.
Figure 2 - A configurable BIOS that leverages the System Management Mode (SMM) of the x86 architecture - like the Phoenix Technologies Embedded BIOS with StrongFrame technology - can resolve many of the PC architecture's security and availability issues.
Figure 2 - A configurable BIOS that leverages the System Management Mode (SMM) of the x86 architecture - like the Phoenix Technologies Embedded BIOS with StrongFrame technology - can resolve many of the PC architecture's security and availability issues.- A configurable BIOS that leverages the System Management Mode (SMM) of the x86 architecture- like the Phoenix Technologies Embedded BIOS with StrongFrame technology - can resolve many of the PC architecture's security and availability issues.
Because these applications form part of the system firmware they also possess a high degree of security. The BIOS and its applications kernel cannot be altered from within the system. This prevents both malicious software and application software errors from permanently damaging firmware operation.
A key factor in the design of an embedded BIOS is the way it handles the system configuration policy. In IT-oriented BIOS designs that policy is hard coded. The firmware searches for specific types of hardware at specific locations and decides at run time how that hardware is to be handled. The typical IT BIOS has more than 1000 such policy decisions to make. Changing that code thus becomes a monumental task.
The embedded BIOS is designed to make these policy decision points configurable. Because the embedded system’s hardware structure is fixed and known, much of that configuration can occur at build time. Developers can select values for system parameters and enable or disable system options when creating the BIOS object code.
The remaining configurability can occur at run time to handle variations within a standard platform design. The installed BIOS consults a personality module that contains specific hardware information for that device to guide its initialization policy. By having part of the system policy configurable at run time, developers can create a single BIOS build for a platform that will automatically handle platform variations, simplifying manufacture and support.
Boot Time Reduction
This combination of build-time and run-time configurability in the embedded BIOS design can dramatically reduce boot time. Legacy devices such as the PS/2 keyboard and mouse controllers must be part of the system hardware for an IT-oriented BIOS to boot, for instance, but can be easily eliminated from the design when using a configurable BIOS. This can shave as much as three seconds off the boot time by eliminating the need to search for devices that may be attached to the controllers.
Another time savings opportunity exists within the video subsystem of a PC. An IT-oriented BIOS searches for and loads information from an external video option ROM that describes the hardware within the video subsystem, a process that requires as much as three seconds. As with the PS/2 controllers, the IT BIOS must find this option ROM in order to boot. A configurable BIOS keeps this information locally for faster access if needed, or simply eliminates this step if the design has no video subsystem.
The hard disk drive (HDD) that is standard within a PC represents another opportunity to reduce boot time. An IT-oriented BIOS expects to find an ATA HDD and has a built-in delay of up to ten seconds to wait for the drive motors to spin up to speed following power-up. The configurable BIOS allows designers to readily replace the HDD with a Flash disk, handling the relevant code changes by modifying the personality module.
In addition to drastically reducing boot time, an embedded BIOS can offer extendibility of its functions by utilizing the System Management Mode (SMM) that became part of the x86 architecture in the 486 generation.
The SMM was originally used to handle advanced power management (APM) as a background operation in the PC, but the advanced control and power interface (ACPI) has since replaced APM in PC designs, leaving SMM free for other uses. SMM adds to the Real and Protected modes of earlier generations that the OS and applications use, creating an independent, background execution thread that is unaffected by system operation in the other two modes.
System Monitoring Enhances Security
The independent operation of the SMM provides an opportunity to enhance the system’s security and reliability. The SMM code could contain applications that give the user basic functionality.
Those functions would become available as soon as the hardware initializes – even before the OS loads. Further, the independence makes code under the SMM immune to software-induced errors that originate in the OS or its applications and remain available in the event of OS and application crashes.
Because firmware-based code running in SMM cannot be accessed by the OS or applications running in the other two modes, it becomes highly secure. Hackers cannot alter or erase the programming from within the system.
The ability to survive crashes of the OS or its applications puts SMM code in a position to monitor OS and application objects and activity to increase system reliability. The SMM code could identify errors, unauthorized modifications, or failures in the OS and applications, then take corrective action such as rebooting the OS. In the meantime, the basic functionality in the SMM-based applications continues to remain available, increasing the system’s availability for use.
One way to provide such monitoring is for the system developer to create a list of sensitive software objects such as CMOS settings and key files on mass storage, then use a hashing algorithm to create a validation code for this data. The monitoring program can then use the hashing algorithm and the validation code to detect any errors or changes in these critical objects.
The system can respond to detected errors in various ways such as sending error messages over the network, restoring the damaged files from backup copies, rebooting the OS or application, or completely shutting down system operation, depending on the error and the developer’s requirements.
The protection that such monitoring provides can extend beyond secure system operation to provide security against software piracy, as well. The monitoring programs can examine the hardware for security codes to validate the environment before launching an application.
This validation step prevents copied software from running on an unauthorized machine. Physical barriers such as epoxy can protect the codes by ensuring their destruction during any attempt to extract them.
Adding Secure Provisioning
Along with enhanced system reliability, monitoring firmware operating in SMM can provide a system design with a new capability: secure provisioning. The firmware can hold a list of software objects in the OS and application code that are open for updates.
Because the firmware has access to system resources such as the network interfaces and stacks, mass storage, and file systems, the firmware can make modifications to OS and application code from outside the OS. Thus, the system can receive, validate, and implement updates and enhancements under the firmware’s secure control.
Such updates can occur either at boot time or during run time. For a boot-time update the BIOS can query the network to look for specific software objects and see if updates are available. The run-time updates would allow the system to system to request files from the network in response to a system condition.
The applications for such automatic provisioning are extensive. For example, a point-of-sale kiosk can load its operating system, applications, and data files automatically upon power up, so that a remote management team can repurpose the kiosk without a site visit. Similarly, identical hardware blades in a system can each receive a unique functional configuration under network control during power-up.
The combination of a configurable BIOS and SMM firmware thus greatly expands the applicability of the PC architecture to embedded applications. It helps eliminate the long boot times inherent in IT-oriented BIOS designs by eliminating hard-coded configurations and thus simplifying customization for a specific hardware platform.
The boot reduction, in turn, increases system availability and thus the design’s acceptability to mainstream users. System security also increases. The combination provides armor against hacker attacks and renders software piracy by simple cloning unproductive. It also expands design options by supporting secure field reconfiguration and maintenance.
The right type of BIOS can eliminate many of the drawbacks that the PC architecture brings to embedded applications without sacrificing compatibility with PC hardware, drivers, protocol stacks, operating systems, and a wide range of applications.
Similarly, development tools, languages, and applet libraries also remain applicable to the development effort. The developer thus has increased ability to leverage the x86 architecture for embedded development while minimizing its drawbacks.