A do-it-yourself guide to building an x86 BIOS-based Computer-On-Module design
In embedded PC applications, a key difference between products can often be in the BIOS firmware. Since the hardware is all based on similar silicon platforms, most currently available x86-based computer-on-modules (COMs) have similar hardware components. The x86 processor is the main performance booster.
The Northbridge, with its integrated graphics controller (GMCH), is responsible for memory bandwidth and graphics performance while the Southbridge (ICH) provides the connectivity through high speed buses like USB2.0, LAN, PCI Express (PCIe), PCI, SATA. If needed, legacy interfaces such as PS/2, LPT, COM and FDC are supported by the super I/O controller.
The combination of these four components is in most cases fixed and is basically comparable to the hardware features of a general purpose PC. There's little room for differentiation in basic hardware. That being the case, it's vital for embedded computing designs to have accompanying software that is fully functional and more versatile than what resides on consumer or office PCs.
So what makes a x86 BIOS an "embedded BIOS?" Together with the driver packages for common operating systems, the BIOS for an embedded computer module plays a key role in the overall system performance and stability. A COM vendor offering solid software and firmware is better focused on the higher demands of the embedded design world.
Obviously a BIOS for an embedded computing platform should have a basic feature-set equal to that found on the latest desktop, notebook, and server computers. However, unlike desktop and notebook computers, COMs are built into a variety of embedded systems, including point-of-sales terminals, telecommunication, medical, manufacturing automation and others.
Therefore, support for an open system architecture is mandatory for the BIOS used in a COM. Given this, the enumeration of the PCIe, PCI and USB bus, booting from USB mass storage and peripheral devices such as SATA, SCSI or LAN, enhanced ACPI power management as well as legacy USB keyboard and mouse emulation must all be considered when creating an embedded BIOS.
As any embedded designer will agree, demands for stability and reliability in embedded applications far exceed those required in desktop PCs. For example, it would be utterly unacceptable for a COM in a medical or industrial application to occasionally crash as desktop PCs do. So paying particular attention to BIOS features for embedded COMs is essential.
There are five key areas that make the difference between an average and truly effective embedded BIOS for a COM-based design. These include:
- Industry leading AMIBIOS 8
- On-board microcontroller
- Special embedded BIOS features (details follow)
- Customer application programming interface
- System utility for BIOS binary modification
Look for these essential capabilities to find a highly-integrated firmware BIOS implementation that's well suited to embedded PC design applications. It is fundamentally important to start with a stable BIOS core supporting the latest industry standards and chipsets. Cutting corners in this area will create added costs later in the product design.
When selecting AMIBIOS8 from American Megatrends Inc., you are choosing the same proven BIOS core used by Intel's Embedded Communication & Platform Division (ECPD). AMIBIOS8 combines modularity, scalability and improved user experience in producing the most advanced BIOS solutions today.
AMIBIOS8 is well suited to embedded computer platforms because it offers many features demanded by the embedded market. Console redirection and BIOS flash update via serial port allow for real headless operation.
Although AMIBIOS8 offers support for the latest industry standards and technology, it still boots extremely fast from most initial program load (IPL) devices, including USB mass storage. In case of a power failure during an AMIBIOS8 flash update in the field, the BIOS can be recovered by using the boot block support.
Additional features offered by AMI such as TPM 1.2 support, headless operation and aggressive power management functions are also essential for embedded designs. In addition to its stability, the ability to adapt the AMIBIOS8 product to an application is what makes it ideal as a building foundation for an embedded BIOS.
Embedded PCs typically offer features not supported in a standard desktop or notebook BIOS. While on the other hand embedded PC designers have special requirements when it comes to BIOS functionality. These requirements need to be taken into account when designing additional embedded PC features like watchdog, I2C bus, OEM CMOS default settings, or flat panel auto-detection. PCs supporting these features can be considered to be real embedded PC products.
The hidden co-worker
Given the fact that silicon vendors do not pay much attention to the requirements of an embedded PC, most of the necessary embedded features are not supported by the chipset. It's for this reason that a specially designed onboard microcontroller on the COM can play an important role in making the PC an embedded PC.
By fully isolating most of the embedded PC features from the x86 core architecture, a COM offering a separate microcontroller frees up the x86 CPU and ensures 100% compatibility amongst various COM-based designs. Once this microcontroller is designed it can be reused again and again on different platforms.
Multi-Stage Watchdog. A watchdog (Figure 1, below) helps to prevent application software lock-ups. When the software hangs it can no longer trigger the watchdog. As a result of the missing trigger the watchdog will cause an interrupt, which allows the software to react to the problem, or it can force a system reboot or shut down.
In many cases it is a requirement that the watchdog is supported by separate hardware that is not part of the x86 platform itself. Moving the watchdog functionality to an onboard microcontroller allows both a fully-featured and isolated solution. Flexible watchdog implementations support a multistage-stage solution that can be triggered by software and/or external OEM hardware on the carrier board.
The watchdog should be designed to either cause an NMI, a hardware reset, a power button event or an ACPI event to inform an ACPI OS to restart or shut down. With multi-stage support the watchdog can be initialized to cause an NMI first and in case the interrupt service routine fails to fix the problem, reset or shutdown the system. This approach allows for a more flexible monitoring of the embedded software application.
 |
||
| Figure 1.It is important to have a watchdog that is supported by hardware that is not part of the X86 platform itself |
High Speed I2C Bus. Many embedded devices such as sensors, converters or data storage can be easily connected to the I2C bus interface. Due to the simple protocol and the high availability of devices, the I2C bus is a frequently used low-speed bus interface in embedded applications.
If the onboard microcontroller supports a real I2C bus host controller, the embedded PC can offer an up to 400kHz, multi-master I2C bus that provides maximum I2C bandwidth to ensure fast transmission of large amounts of data.
Non-volatile User Data Storage. Some embedded applications may require non-volatile storage of critical and important operating data. This can be offered in the form of an EEPROM or flash memory chip. For small amounts of data a 32 byte area in an EEPROM may be sufficient.
To prevent end users from changing this data, it should be possible to lock the 32 byte EEPROM area and thereby making it read only. For larger amounts of data a 64kB flash sector in the BIOS Firmware Hub (FWH) device could be used.
Even if the mass storage media that holds the operating system is not functioning and needs replacement, the user data stored in EEPROM or flash memory will not be lost.
Manufacturing and Board Information. The EEPROM in the microcontroller can also provide a rich data set of manufacturing and board information. This information might include serial number, article number, EAN code, manufacturing and repair date and so on.
It can also keeps track of dynamically changing running time and boot count data. During the manufacturing process the static data must be written to the non-volatile memory within the microcontroller.
This can be read out later by the end users software in order to obtain detailed information about the COM used in the system. Boot counter and running-time meter provide information about how many times the system has booted and the number of hours the system has been running. This is very helpful information for product maintenance, RMA service and upgrades in the field.
BIOS CMOS Data Backup in NVRAM. A backup copy of the BIOS CMOS settings must be held in non volatile memory, e.g. the flash memory device. This allows battery less applications. If a backup battery is used it will also help prevent "non-booting systems" when the backup battery has failed since the system configuration is always maintained.
Power Loss Control. The onboard microcontroller could also provide an AC power loss control feature that defines the behavior of the module once power has been restored. The following modes of operation are typically supported:
Flat Panel Auto Detection and Backlight Control. Extended Display Identification Data (EDID) is a well-known industry standard established by VESA. By understanding the basic EDID data structure, a fully-featured embedded BIOS can automatically detect and configure an attached flat panel.
When the EDID data is provided to the BIOS, panel selection in setup or configuration via proprietary data sets is no longer necessary. Additionally, the BIOS should have the ability to adjust the backlight intensity via a setup node as well as application software.
 |
||
| Figure 2. When the EDID data is provided to the BIOS, panel selection in setup or configuration via proprietary data sets is no longer necessary. |
Built in CMB Battery. COMs are well suited for battery powered mobile applications. To simplify system integration in creating a battery powered device the embedded PC should come with built in support for a battery sub system.
The ACPI BIOS and the onboard microcontroller must be designed specifically to support a control method battery (CMB). The vendor is responsible for providing detailed information about how the BIOS interfaces to the battery system. If the guidelines set forth are followed then designers can easily implement their own battery solutions.
When using an ACPI OS, most of the battery functionality associated with portable computers can be supported on the embedded platform.
 |
||
| Figure 3. The ACPI BIOS and the onboard microcontroller must be designed specifically to support a control method battery (CMB). |
Programming Interface. In today's market many COM manufacturers are offering a variety of features but these features are only as good as the customer's ability to access them. If easy access is not provided then the value is nil.
In addition to all those embedded PC features supported by hardware and BIOS, it is mandatory to offer a uniform API for easy access from the application software to the embedded PC feature set. With the API, application software developers can quite easily take advantage of the embedded PCs add-ons listed above.
Ideally, the API has been implemented as a generic board independent OS driver and is available for all common embedded operating systems. Whether it's triggering the watchdog, transferring data over I2C, reading hardware monitoring numbers or changing the backlight adjustment of the flat panel, it only requires a call to the API. Most importantly, such an API saves development time and guaranties software compatibility.
 |
||
| Figure 4. A uniform API implemented as a board independent OS driver guaranties software compatibility. |
Ideally, the API driver itself will call the BIOS for low-level hardware routines. When doing so there will be no need for end users to update application software or an API driver when the embedded PC is going to be changed.
Do-it-yourself BIOS binary modification OEMs using COMs in many cases can not use the standard BIOS that is provided by the module supplier. Special utilities and a BIOS with built-in support allow minor modifications to the BIOS binary without dealing with the BIOS source code. The following are three examples of typical BIOS binary changes:
1. OEM CMOS Default Settings. Most designers who utilize an embedded module within their system need to have their own CMOS ROM default settings. An embedded BIOS should provide the ability to store OEM defaults in flash memory thereby reducing the need for customized BIOS versions.
2. OEM Splash Screen. Hiding the PC functionality in an embedded application is often a requirement. The BIOS should instead display a logo rather than the traditional diagnostic output during POST. Users should be able to integrate an OEM logo into the standard BIOS themselves.
3. OEM BIOS. This BIOS feature allows users to integrate their own code into the BIOS POST process. In order to support this the BIOS must be capable of calling OEM code at different times during POST. With this type of OEM BIOS support a user can, for example, initialize carrier board hardware components and add boot loaders. Although most BIOS vendors offer an utility for binary BIOS modifications, some embedded PC vendors have their own utility. Congatec AG for example offers a powerful software package that allows a customer to perform the following modifications to the BIOS binary:
* Add OEM CMOS default settings
* Add OEM Splash screen
* Add OEM BIOS code
* Change the BIOS setup screens and add OEM setup screen
The utility can be also used as a:
* BIOS update utility
* Onboard microcontroller firmware update utility
* Flat panel data configuration (create EDID data set from panel data sheet information)
Provided by Congatec AG at no charge is a system utility available in both DOS command line and Windows GUI versions. It works in file mode (patching a BIOS binary) and flash mode (directly modifying the BIOS on the target PC). The utility is provided by congatec AG at no charge. When using this utility for BIOS modifications COM users can configure and customize their BIOS quickly without incurring additional costs.
Conclusion All BIOS software offerings are not created equal. This is currently a shortcoming within the embedded PC industry. If indeed all BIOS software and the accompanying COMs being offered were created equally then all the features mentioned earlier would be available and the consumer could benefit from uniform functionality.
Unfortunately this is not yet the case within the industry so it's up to the consumer to closely examine the functionality of the COM being offered. With a fully-featured BIOS that is tailored to the extensive needs of embedded engineering and offering true versatility and design flexibility, successfully implementing an x86 computer-on-module application will be easier and faster.
Christian Riesinger is the R&D Manager at congatec AG. He's been working for over 10 years as a BIOS engineer and has been instrumental in implementing new embedded PC features within the industry.