I need a BIOS for my embedded x86 design. Which choices do I have?

Lets say that you are going to develop a one-time, black box device, with a single CPU SKU, running a mainstream Linux version, and yes, you need some level of security like secure boot and perhaps secure flash update. Your team obviously has knowledge about Linux and programming in C. Most likely they know how to use open source software, find information and documentation, research feature implementations and resolve issues with the help of open source communities. As the device, and with it, the BIOS specifications are well defined and limited, a cost effective solution can be an open source bootloader like Intel’s Slim Bootloader, Firmware Support Package (FSP) or Coreboot. Both are well documented, have the support of a large community and they are somewhat backed up by Intel and AMD. The latter sounds trivial but is very important because part of the required microcode encapsulated in the open source is only made available in object code format from the silicon manufacturers. In other words, a black box within an open source project. These binaries contain the tweaks needed to support certain features within the processor, and also to correct errors in the silicon. Nothing wrong there: updates are released regularly with release notes that tell you what is new, but more importantly, what you need to modify in your code. If your design is very limited in feature set, and you are not an early adopter of new silicon, then the open source you are going to download will be mature, and most of the issues, if any, will be resolved by the community. If you are an early adopter, than that’s where you can expect trouble, and you need to wager if you want to take this risk.

If you are an early adopter, than that’s where you can expect trouble

On the other side of the spectrum you have the open source EDK from the UEFI organization, an initiative originally founded by Intel to assure compatibility between x86 processors, peripherals and OSes, but today has evolved to promote interoperability between different silicon architectures too. The EDK therefore is maintained by companies that need high levels of compatibility, extended feature sets and advanced security. So, the open source EDK seems a good alternative if your design is more than a black box system, requires multi OS support, remote management (BMC features), and up to date security. But after downloading and installing you will soon notice that this comes at a cost; it’s overwhelming and will require a firmware team to invest a significant amount of time in learning how to customize the UEFI code for their device.

That’s the reason why independent BIOS vendors (IBV) such as Insyde Software Inc. are members of the UEFI organization. They use the EDK’s as a basis to develop and deliver feature rich and tested firmware bundles that fully support the Reference Validation Platforms (RVP) from Intel and AMD accompanied by matching documentation, training, support, and if you so wish, customization services to adapt their UEFI solution for you specific design. For you, asking the question about BIOS, this implies that your starting point for a demanding, feature rich device is a BIOS that is already running on a RVP. Since your hardware engineers hopefully have designed your device based on such RVP, you will have a working system to compare against the device you will need to bring up.

Of course, using a commercial BIOS implies investing in acquiring a license for the source code, training and paying for support, but on the other hand, it will definitely give you a head start compared to using an open source project, struggling through loads of documentation and files by yourself.

Don't forget about security and vulnerability

These recent years, attacks at the firmware level have showed that open source components are vulnerable to unintended leaks. Being able to keep track of CVE's and more important to remedy them has become a very important activity in the firmware product lifecycle. Regular updates to firmware components, and proven secure update methods need to be accounted for when planning the release of end-products and updates in the field. Especially when the firmware is signed and locked, this can be a difficult and dangerous process that needs proper testing.