Configurable BIOS improves embedded PC operations

Configurable BIOS improves embedded PC operations

Designers need a PC BIOS that targets embedded systems, rather than IT

BY STEVE JONES
Phoenix Technologies
Milpitas, CA
http://www.phoenix.com

The PC architecture forms a powerful platform for general-purpose computing and for dedicated embedded functions. Unfortunately current PC implementations suffer significant drawbacks that can prevent mainstream adoption when used in embedded applications. Using a BIOS optimized for embedded applications can cut these drawbacks and allow designers to leverage the PC architecture.

Rapid availability for use when activated is an obvious drawback of PCs. Mainstream users will tolerate only a few seconds of operational delay after turning on a device before becoming frustrated. And, a design that exposes its inner workings, such as a PC displaying its boot sequence, creates confusion and concern among embedded system users.

One of PC system software’s greatest limitations is excessive boot time. The time from the application of power until an application is ready to use often runs 30 s or more sometimes minutes. Not all of that is the fault of the operating system, however. Simply initializing the hardware can require as long as 10 s, before a device is even ready to load the OS.

Traditional BIOS customization difficult

Another attribute of PC system software that creates challenges in embedded applications is the PC’s required component policy. The boot firmware and the operating system expect several hardware components to be present in the system for it to operate properly – usually a keyboard, a monitor, maybe a hard-disk drive, a signaling device such as a speaker or beeper, and certain types of timers.

Developers face another major challenge when adapting the PC architecture for an embedded application: the fruits of their design effort are vulnerable to theft, as application software is usually easy to copy.

Adapting the PC architecture for embedded applications has significant design challenges, but the cost advantages are too compelling to ignore. Many design teams have developed spot solutions to some issues. What is needed is a way to tackle the system software root of the problems. Replacing Windows with an RTOS only addresses part of the problem. The PC BIOS also needs modification if challenges such as the boot delay are to be overcome.

Embedded BIOS needed

The PC BIOS is the code responsible for initializing system hardware and running power-on self-test (POST) routines to provide a stable system base upon which the operating system will build. For most embedded systems, this initial code is relatively simple. The PC BIOS was designed for information technology (IT) applications and must deal with a much more complex processor and system hardware architecture than the typical embedded system (see Fig. 1 ). This complexity includes the need to update processor microcode and to work through several bridging devices to reach system resources such as system DRAM and peripheral devices.

Fig. 1. Part of the boot delay in PCs stems from the complex hardware architecture that places peripherals, memory, and the BIOS ROM on the far side of bridging devices.

This complex structure contributes significantly to the startup delay. Numerous initialization routines, for instance, must run out of the relatively slow boot ROM in order to make the processor’s cache available for use:

• Enabling APICs.

• Enabling multiprocessing.

• Loading microcode.

• Clock chip programming.

• Initializing cache.

• Initial table loads.

• Initializing legacy I/O.

• Enabling A20 gate.

• Initializing KBC.

• SMBUS initialization.

• SPD reading (each DIMM).

• Memory controller initialization.

• JEDEC memory programming.

Even after the cache is available, there is a substantial amount of code that initializes required legacy components.

A traditional PC BIOS, however, is relatively difficult to customize. The BIOS follows an initialization policy decision tree that specifies where to find and when to initialize required hardware as well and how to gather additional configuration information for whatever optional hardware may be available. In most traditional BIOS offerings those policy decisions are hard coded and difficult to change.

Embedded developers, therefore, need to work with a PC BIOS that has been developed with an eye toward embedded system rather than IT. This software should be structured to simplify customization for hardware variations, allowing the elimination of code for hardware that developers know will not be present. Such customization can greatly reduce the BIOS boot time. Experiments show that BIOS boot time can drop from the typical eight or nine seconds to as low as 73 ms.

Structuring the embedded BIOS

One way the BIOS can be structured to support such customization is to remove hard-coded policy decisions and insert a board personality layer that it consults at critical steps to learn how to locate and initialize key hardware elements. This removes the need for specific hardware at specific locations without sacrificing legacy compatibility and can help speed boot time by taking decision-making out of the boot sequence. Because the developer can customize the BIOS at build time to a specific hardware configuration, the BIOS does not need to query the system during run time for the presence of hardware or wait for a response or time-out.

The BIOS can address software vulnerability challenges by taking advantage of the System Management Mode (SMM) available in the x86 architecture. SMM serves as a third operating mode to hide frequently-run background software from the normal application processing mode and the OS’s protected mode. Originally, SMM served to run the advanced power management (APM) algorithms for a PC, but advanced control and power interface (ACPI) has since taken over these tasks, leaving SMM available for other uses.

One significant advantage to running software in SMM is that it operates independently of and in parallel with applications and the operating system and can function as a check on behavior of the OS and applications. The OS or an application can crash without affecting the SMM code’s operation, allowing the SMM code to respond to, and perhaps correct, errors.

New capabilities gained

Operating in SMM also adds a new capability for secure remote provisioning to a PC-based design to provide periodic software updates to add new features. Ideally, providing such updates would require neither user action nor a user site visit by the vendor. However, giving the device a network link over which software updates can travel also opens opportunity for introduction of malicious code.

With part of the BIOS running in SMM, however, the BIOS gains the ability to examine downloaded code for accuracy and authenticity before allowing the new application or update to run. Because SMM operates independently, the OS or applications code has no opportunity to interfere with or corrupt this process. Remote provisioning thus obtains the security it needs.

The BIOS can also enhance system security. The boot code, running in SMM, can examine OS and application software objects for errors or modification before allowing them to boot, cutting the threat of malicious software. This also helps make software piracy more difficult by preventing changes in copied software, such as replacement of a company’s name and logo, that might disguise its true source. The application code can also challenge the hardware platform for a security code to ensure that it is running on a valid computer.

This tool should be structured to simplify customization for hardware variations, allowing the elimination of code for hardware that developers know will not be present. An example of such BIOS software design tool is the Firmbase Software Development Kit from Phoenix Technologies (www.phoenix.com). A BIOS structured to address the needs of embedded applications rather than the traditional IT approach can resolve many of the challenges in using the PC architecture in embedded applications. ■