In embedded PC applications, a key difference between products canoften be in the
The Northbridge,with its integrated graphics controller (GMCH), isresponsible for memory bandwidth and graphics performance while theSouthbridge (ICH) provides the connectivity through high speed buseslike USB2.0, LAN, PCI Express (PCIe), PCI, SATA. If needed, legacyinterfaces such as PS/2, LPT, COM and FDC are supported by the superI/O controller.
The combination of these four components is in most cases fixed andis basically comparable to the hardware features of a general purposePC. There's little room for differentiation in basic hardware. Thatbeing the case, it's vital for embedded computing designs to haveaccompanying software that is fully functional and more versatile thanwhat resides on consumer or office PCs.
So what makes a x86 BIOS an “embedded BIOS?” Together with thedriver packages for common operating systems, the BIOS for an embeddedcomputer module plays a key role in the overall system performance andstability. A COM vendor offering solid software and firmware is betterfocused on the higher demands of the embedded design world.
Obviously a BIOS for an embedded computing platform should have abasic 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, includingpoint-of-sales terminals, telecommunication, medical, manufacturingautomation and others.
Therefore, support for an open system architecture is mandatory forthe BIOS used in a COM. Given this, the enumeration of the PCIe, PCIand USB bus, booting from USB mass storage and peripheral devices suchas SATA, SCSI or LAN, enhanced ACPI power management as well as legacyUSB keyboard and mouse emulation must all be considered when creatingan embedded BIOS.
As any embedded designer will agree, demands for stability andreliability in embedded applications far exceed those required indesktop PCs. For example, it would be utterly unacceptable for a COM ina medical or industrial application to occasionally crash as desktopPCs do. So paying particular attention to BIOS features for embeddedCOMs is essential.
There are five key areas that make the difference between an averageand truly effective embedded BIOS for a COM-based design. Theseinclude:
1) Industry leading AMIBIOS 8
2) On-board microcontroller
3) Special embedded BIOSfeatures (details follow)
4) Customer applicationprogramming interface
5) System utility for BIOSbinary modification
Look for these essential capabilities to find a highly-integratedfirmware BIOS implementation that's well suited to embedded PC designapplications. It is fundamentally important to start with a stable BIOScore supporting the latest industry standards and chipsets. Cuttingcorners in this area will create added costs later in the productdesign.
When selecting AMIBIOS8 from
Although AMIBIOS8 offers support for the latest industry standardsand technology, it still boots extremely fast from most initial programload (IPL) devices, including USB mass storage. In case of a powerfailure during an AMIBIOS8 flash update in the field, the BIOS can berecovered by using theboot block support.
Additional features offered by AMI such as
Embedded PCs typically offer features not supported in a standarddesktop or notebook BIOS. While on the other hand embedded PC designershave special requirements when it comes to BIOS functionality. Theserequirements need to be taken into account when designing additionalembedded PC features like watchdog, I2C bus, OEM CMOS default settings,or flat panel auto-detection. PCs supporting these features can beconsidered to be real embedded PC products.The hidden co-worker
Given the fact that silicon vendors do not pay much attention to therequirements of an embedded PC, most of the necessary embedded featuresare not supported by the chipset. It's for this reason that a speciallydesigned onboard microcontroller on the COM can play an important rolein making the PC an embedded PC.
By fully isolating most of the embedded PC features from the x86core architecture, a COM offering a separate microcontroller frees upthe x86 CPU and ensures 100% compatibility amongst various COM-baseddesigns. Once this microcontroller is designed it can be reused againand again on different platforms.
Multi-StageWatchdog. A watchdog (Figure 1,below ) helps to prevent application softwarelock-ups. When the software hangs it can no longer trigger thewatchdog. As a result of the missing trigger the watchdog will cause aninterrupt, which allows the software to react to the problem, or it canforce a system reboot or shut down.
In many cases it is a requirement that the watchdog is supported byseparate hardware that is not part of the x86 platform itself. Movingthe watchdog functionality to an onboard microcontroller allows both afully-featured and isolated solution. Flexible watchdog implementationssupport a multistage-stage solution that can be triggered by softwareand/or external OEM hardware on the carrier board.
The watchdog should be designed to either cause an NMI, a hardwarereset, a power button event or an ACPI event to inform an ACPI OS torestart or shut down. With multi-stage support the watchdog can beinitialized to cause an NMI first and in case the interrupt serviceroutine fails to fix the problem, reset or shutdown the system. Thisapproach allows for a more flexible monitoring of the embedded softwareapplication.
|Figure1.It is important to have a watchdog that is supported by hardware thatis not part of the X86 platform itself|
High Speed I2CBus . Many embedded devices such as sensors, converters or datastorage can be easily connected to the I2C bus interface. Due to thesimple protocol and the high availability of devices, the I2C bus is afrequently used low-speed bus interface in embedded applications.
If the onboard microcontroller supports a real I2C bus hostcontroller, the embedded PC can offer an up to 400kHz, multi-master I2Cbus that provides maximum I2C bandwidth to ensure fast transmission oflarge amounts of data.
Non-volatileUser Data Storage. Some embedded applications may requirenon-volatile storage of critical and important operating data. This canbe offered in the form of an EEPROM or flash memory chip. For smallamounts of data a 32 byte area in an EEPROM may be sufficient.
To prevent end users from changing this data, it should be possibleto lock the 32 byte EEPROM area and thereby making it read only. Forlarger 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 isnot functioning and needs replacement, the user data stored in EEPROMor flash memory will not be lost.
Manufacturingand Board Information. The EEPROM in the microcontroller canalso 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 andboot count data. During the manufacturing process the static data mustbe written to the non-volatile memory within the microcontroller.
This can be read out later by the end users software in order toobtain detailed information about the COM used in the system. Bootcounter and running-time meter provide information about how many timesthe system has booted and the number of hours the system has beenrunning. This is very helpful information for product maintenance, RMAservice and upgrades in the field.
BIOS CMOS DataBackup in NVRAM. A backup copy of the BIOS CMOS settings must beheld in non volatile memory, e.g. the flash memory device. This allowsbattery less applications. If a backup battery is used it will alsohelp prevent “non-booting systems” when the backup battery has failedsince the system configuration is always maintained.
Power LossControl . The onboard microcontroller could also provide an ACpower loss control feature that defines the behavior of the module oncepower has been restored. The following modes of operation are typicallysupported:
* Turn On (Server Mode)
* Remain Off (Desktop Mode)
* Last State (Restores the previous power state before power lossoccurred)
Flat Panel AutoDetection and Backlight Control . Extended DisplayIdentificationData (EDID) is a well-known industry standard established by VESA.Byunderstanding the basic EDID data structure, a fully-featured embeddedBIOS can automatically detect and configure an attached flat panel.
When the EDID data is provided to the BIOS, panel selection in setupor configuration via proprietary data sets is no longer necessary.Additionally, the BIOS should have the ability to adjust the backlightintensity via a setup node as well as application software.
|Figure2. When the EDID data is provided to the BIOS, panel selection in setupor configuration via proprietary data sets is no longer necessary.|
Built in CMBBattery. COMs are well suited for battery poweredmobile applications. To simplify system integration in creating abattery powered device the embedded PC should come with built insupport for a battery sub system.
The ACPI BIOS and the onboard microcontroller must be designedspecifically to support a control method battery (CMB). The vendor isresponsible for providing detailed information about how the BIOSinterfaces to the battery system. If the guidelines set forth arefollowed then designers can easily implement their own batterysolutions.
When using an ACPI OS, most of the battery functionality associatedwith portable computers can be supported on the embedded platform.
|Figure3. The ACPI BIOS and the onboard microcontroller must be designedspecifically to support a control method battery (CMB).|
ProgrammingInterface. In today's market many COM manufacturers are offeringa variety of features but these features are only as good as thecustomer's ability to access them. If easy access is not provided thenthe value is nil.
In addition to all those embedded PC features supported by hardwareand BIOS, it is mandatory to offer a uniform API for easy access fromthe application software to the embedded PC feature set. With the API,application software developers can quite easily take advantage of theembedded PCs add-ons listed above.
Ideally, the API has been implemented as a generic board independentOS 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 backlightadjustment of the flat panel, it only requires a call to the API. Mostimportantly, such an API saves development time and guaranties softwarecompatibility.
|Figure4. A uniform API implemented as a board independent OS driverguaranties software compatibility.|
Ideally, the API driver itself will call the BIOS for low-levelhardware routines. When doing so there will be no need for end users toupdate application software or an API driver when the embedded PC isgoing to be changed.Do-it-yourself BIOS binary modification
OEMs using COMs in many cases can not use the standard BIOS that isprovided by the module supplier. Special utilities and a BIOS withbuilt-in support allow minor modifications to the BIOS binary withoutdealing with the BIOS source code. The following are three examples oftypical BIOS binary changes:
1. OEM CMOSDefault Settings. Most designers who utilize an embedded modulewithin their system need to have their own CMOS ROM default settings.An embedded BIOS should provide the ability to store OEM defaults inflash memory thereby reducing the need for customized BIOS versions.
2. OEM SplashScreen. Hiding the PC functionality in an embedded applicationis often a requirement. The BIOS should instead display a logo ratherthan the traditional diagnostic output during POST. Users should beable to integrate an OEM logo into the standard BIOS themselves.
3. OEM BIOS. This BIOS feature allows users to integrate their own code into theBIOS POST process. In order to support this the BIOS must be capable ofcalling OEM code at different times during POST. With this type of OEMBIOS support a user can, for example, initialize carrier board hardwarecomponents and add boot loaders.
Although most BIOS vendors offer an utility for binary BIOSmodifications, some embedded PC vendors have their own utility.
* 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 datasheet information)
Provided by Congatec AG at no charge is a system utility availablein both DOS command line and Windows GUI versions. It works in filemode (patching a BIOS binary) and flash mode (directly modifying theBIOS on the target PC). The utility is provided by congatec AG at nocharge. When using this utility for BIOS modifications COM users canconfigure and customize their BIOS quickly without incurring additionalcosts.
All BIOS software offerings are not created equal. This is currently ashortcoming within the embedded PC industry. If indeed all BIOSsoftware and the accompanying COMs being offered were created equallythen all the features mentioned earlier would be available and theconsumer could benefit from uniform functionality.
Unfortunately this is not yet the case within the industry so it'sup to the consumer to closely examine the functionality of the COMbeing offered. With a fully-featured BIOS that is tailored to theextensive needs of embedded engineering and offering true versatilityand design flexibility, successfully implementing an x86computer-on-module application will be easier and faster.
Christian Riesinger is the R&DManager at congatec AG. He'sbeen working for over 10 years as a BIOS engineer and has beeninstrumental in implementing new embedded PC features within theindustry.