SOFTWARE & DEVELOPMENT TOOLS
Differentiating Embedded Products with BIOS Customization
Many x86-based embedded solutions rely on a BIOS designed for the desktop world. More efficient and cost-effective designs can be realized by configuring a BIOS to meet the needs of the application-specific hardware and software
STEVE JONES AND NAT HILLARY, GENERAL SOFTWARE
Page 1 of 1
The common BIOS in desktops, servers and laptops, which is a BIOS designed for the IT world, is designed to make those devices behave like general-purpose computers so we can all use them in the same way. Embedded x86-based products, such as network appliances and kiosks, need to behave like appliances, not general-purpose computers. An embedded appliance needs specialized firmware that makes the device behave uniquely—that’s where BIOS comes in. Embedded firmware (which means BIOS for x86 architecture) is really the foundation of embedded device differentiation.
There are two ways of achieving BIOS-level customization for embedded systems. One is to invest the time and effort required to massage a BIOS designed for desktop and/or server use to meet the requirements of an embedded system. The alternative is to use a BIOS specifically designed for the embedded market. The latter approach helps to simplify the process of creating a custom BIOS for an embedded system, minimizing the effort and risk required, while also offering enhanced firmware capabilities
A BIOS Differentiates Embedded Products
Differentiation is a key factor in an embedded product’s success, taking it in new directions that offer an edge over the competition. Table 1 shows some of the ways BIOS can make a significant difference in a product’s functionality. In this article we’ll explore the issues associated with creating a BIOS that:
- Is configured to include only a limited subset of the features found as standard in an IT BIOS
- Is customized to include platform-specific setup screens, splash screen setups (including multimedia) and application-specific code, such as FPGA initialization code
- Satisfies a sub-second quick boot objective
- Provides enhanced firmware application capabilities such as high-availability monitoring and boot security
Most desktop or server systems require all of the desktop BIOS initiatives to be incorporated into the system, including Plug and Play (PnP), Advanced Power Mode (APM), Advanced Configuration and Power Interface (ACPI), PCI device enumeration and resource assignments, Enhanced Disk Drive (EDD), System Management BIOS (SMBIOS), System Management Bus (SMBUS), and others. In the general IT BIOS case, it makes sense to have all of these features built into the system’s BIOS so that it can support add-in hardware or software that requires this support.
For most embedded applications, however, many of these components are unnecessary baggage that add time to Power-On Self Test (POST) and consume ROM space. A configurable BIOS such as Embedded BIOS 2000 provides a set of over 800 configuration options that are used to control which functional elements are included in the BIOS build process. Any functional component not required by a given design does not get included in the BIOS binary.
Customizing BIOS User Interface and Function
Embedded devices rarely have a need for a standard BIOS user interface. If an appliance boots from an internal hard drive, it doesn’t need to be configured to boot from a floppy or CDROM, nor does it need to provide the option for nonstandard CPU or memory clocking. In addition, if there is any proprietary hardware that requires initialization and configuration at boot time (e.g., an ASIC), this code also needs to be included with the core BIOS.
Eliminating the setup screens frees the BIOS user interface to assume new forms, such as a headless design; a menu or desktop-like POST through an RS232 serial cable connected to a remote terminal program; a Telnet session over an Ethernet network; or even a graphical pre-OS environment that can present OEM-defined graphics, animation and sound as the OS loads.
Building customized user interfaces requires support from the core functionality of the BIOS, so the user interface can get control at the right times. BIOS keyboard and video calls need to be routed to a new device (i.e., Telnet) and handled appropriately.
By using a BIOS kit built for embedded targets, this process can be reduced to setting project options. Table 2 shows how this is done with build configuration statements in a configurable BIOS project file.
Initializing proprietary hardware not only requires custom code, but the initialization sequence is also important (e.g., ASIC must be configured before PCI enumeration occurs). It is imperative to the BIOS user that he or she be able to insert this custom code at the right time in the BIOS boot sequence. If all of the BIOS code is provided in source form, embedded BIOS users can call their initialization code at any point in the boot sequence. In addition, this code may be bundled as a package so that the custom code does not need to be integrated into the core BIOS code, making it portable from one platform to the next.
The time it takes for a device to become functional from power-on shapes a consumer’s perception about its performance and reliability—appliances that take longer than a second to boot seem unresponsive or sluggish. Optimizing BIOS boot time can be daunting because there are dozens of steps in the BIOS Power-On Self-Test that must be optimized.
One of the most elegant concepts for achieving quick boot is the use of the Microsoft simple boot flag enhancement, which determines which elements of POST are executed at boot time. However, there are also other areas where boot time may be reduced.
In its simplest form, the simple boot flag is used to control boot speed using the boot speed flag. During the first boot the BIOS sets the boot speed flag in non-volatile memory, and then the complete set of diagnostic tests are executed. At the end of the boot, control is handed over to the OS and if it starts up without any issues, it clears the boot speed flag. On the next reboot, the BIOS sees that the boot speed flag has been cleared, and it then runs a shorter set of diagnostic tests, reducing boot time. Should the BIOS or OS detect a hardware configuration change and/or failure, they can coordinate between themselves to ensure that a complete set of diagnostic tests are executed on the next boot cycle.
While the most significant contributor to improving boot speed is the use of the simple boot flag, there are many other areas that may be addressed to improve boot speed, including:
- Video ROM extension (takes about 1-3 seconds)
- Any other BIOS output to screen, including POST and PCI messages (takes about 100 mS)
- Hardware initialization not required by BIOS, but activated by OS, e.g., mouse and keyboard (can take up to several seconds)
Because most embedded systems have a fixed hardware configuration, it is also possible to tailor the BIOS to further improve boot speed using target-specific optimizations such as optimized memory initialization and PCI enumeration.
Through the use of the simple boot flag, eliminating hardware initializations and using target-specific optimizations, sub-second boot times have been demonstrated on a number of platforms. On one platform in particular, the time taken from reset to OS load was less than 100 mS!
Enhanced Firmware Application Capabilities
Increasingly, embedded systems developers are seeking ways to differentiate their products from the competition by adding more and more features. Firmware is the ideal place for this feature enhancement to occur, especially for those features that are required to operate independently of the platform OS. Good examples of this are high-availability monitoring and boot security.
“Five nines” availability has been an industry buzzword since the ’90s, with a significant amount of effort going into achieving this objective. In a recovering economy, embedded developers are now exploring ways to incorporate High Availability (HA) into their products.
Had the kiosk in Figure 1 employed firmware running independently of the operating system, it could have detected this failure condition in any number of ways. It then could have taken corrective action such as logging the failure, sending email across the network or just rebooting. While this was a visible failure, headless equipment is also equally vulnerable.
Firmware is the ideal place for this monitoring to occur—running independently from the OS, and running alongside the OS in system management mode (SMM), the fourth mode of the x86 processor architecture. The Firmbase SMM operating environment, for example, has its own 32-bit SMM operating environment for running portable executable programs built using Windows tools. Firmbase applications reside in the ROM alongside the BIOS, where they operate independent of the OS, even if the OS has crashed or is missing. This makes the BIOS the most appropriate place for a high-availability monitor solution, used to detect and respond to a system failure.
In some situations firmware can help solve end user tampering with appliances. Voting machines, gaming machines or even set top boxes need a chain of trust established between the application-level software, the firmware itself and the platform. If this trust doesn’t exist, a user could modify key files on a hard drive or substitute another motherboard to interfere with polling results or defraud the house. By establishing a repetitive cryptographic handshake with the application running under Windows or Linux, and the firmware running in SMM independently of the OS, it is possible for either the application or the firmware to disable the system, preventing it from doing the wrong thing.
In the past, tying the hardware to the application has been the application programmer’s job. It is now safer and easier to either extend the system’s system management interface (SMI) handler to perform the handshake or to license a boot-time security application that has logging, remote administration and OEM-level configuration at the firmware layer. Figure 2 shows an example view of a Web browser remotely managing a boot security application.
There are additional ways to use BIOS to differentiate a product at the firmware layer and gain a competitive advantage. After addressing the BIOS functional configuration, user interface, quick boot and adding proprietary functionality, which have been discussed in this article, there are many other considerations. Hard disks, for example, can be replaced by solid-state media like ROM, RAM and Flash disks or USB memory sticks. Burn-in diagnostics can be integrated into the BIOS to help automate manufacturing. A built-in debugger can speed up the board bring-up process. Additionally, special loaders, such as those for Windows CE and EFI, can provide a built-in roadmap for future technology initiatives.
Given the range of application-specific differences between embedded systems, no single, monolithic BIOS will be appropriate or efficient for all of them. The ability to tailor the underlying firmware in the same way developers customize the hardware and the application software, will go a long way toward making an embedded device straightforward to develop, and efficient and cost-effective to deploy.