Skip navigation

Embedded Community

7 Posts authored by: brian_ami

Wow, I take the week of CES off and looks what happens … everybody is talking about UEFI. My Twitter account exploded with articles on UEFI from around the world (thank you Google Translate, since I can’t read French, German, Japanese, Chinese or Indonesian).

 

The big focus seems to be on the cool graphical interfaces companies like Asus and MSI are adding to UEFI on their desktop platforms. And I admit, they’re pretty cool … the BIOS setup menu has been pretty much a text interface since the era when top-loading VCRs were considered “technology”.

 

But I think it’s important to understand how UEFI is related to those graphical pre-boot interfaces. After all, the industry has had high-resolution graphics controllers for a long time. Why does UEFI suddenly unleash new user interfaces? Does UEFI actually require users to move from keyboard to mouse?

The GUI isn’t New-ey

Uncomfortable rhymes aside, the graphics capabilities of UEFI aren’t a new thing. Companies like AMI, MSI and Asus have been previewing GUI pre-boot interfaces for several years. Here’s a demo video of the Asus interface from 2009

BIOS providers like AMI have been showing graphical interfaces and development libraries back when UEFI was just “EFI” … you know you’ve worked in technology too long when you refer to “the good old days” as sometime back in 2004. Adding GUI in pre-boot comes from some major improvements in how UEFI handles graphics output versus a 16-bit BIOS.

Understanding GOP

Once effect of UEFI is replacing legacy BIOS interrupt calls, which depend on 16-bit x86 compatibility, with protocols. The traditional VESA modes used by the BIOS to define a display adapter’s supported modes rely on software interrupts, so they had to be replaced. The result is the UEFI Graphics Output Protocol (GOP), which replaces a complex set of modes with a simple video buffer.

 

The VESA BIOS Extensions (VBE) define a large table of graphics modes, but a developer can never assume that a specific mode is supported. This makes it very hard for a developer to make an interface that works across different graphics cards. Yes, they can write an interface to a common resolution (800x600 for example) but there are several different modes that can be used to support that resolution, assuming it’s supported at all using VBE (remember, these modes are optional).

 

GOP just defines a buffer for a particular resolution and color depth. This makes it easier to support a new resolution, or have the display scale to a different resolution. There are also common resolutions in use (example: Microsoft Windows requires 1024x768 and 800x600 for GOP in their bootloader, Intel EPOG supports 800x600 in GOP). This simplicity in implementation makes GUI development easier for the BIOS and pre-boot applications, such as the AMI Provisioning environment.

The GUI isn’t Mandatory

For folks in the embedded market, a GUI pre-boot interface isn’t always seen as a necessary feature. In fact, it’s often seen as undesirable for headless systems or deeply embedded platforms. For a system with no local display, an interface like this doesn’t make much sense.

 

 

So good news for embedded customers … UEFI doesn’t require a graphical pre-boot interface. UEFI has been on platforms for years, and vast majority ship with an interface that looks and acts like the “legacy BIOS” text interface. This allows the base firmware to get upgrades without affecting compatibility with console redirection tools designed for headless management. As an added bonus, tech support doesn’t have to learn a new interface.

 

Even if you want to take advantage of graphics in pre-boot, UEFI has a solution for console redirection. Thanks to a “console splitter” driver, user output can be processed differently depending on the physical interface. Users see a colorful interface in a graphical frame on the monitor, a user connected to the same computer gets VT-100/ANSI 80x25 text via serial port or Serial over LAN (SoL). This allows “headless” console interfaces to work even if a graphical option is used for BIOS setup.

Theme01.png

So Why Now?

If you ignore “tablet madness”, CES 2011 made UEFI look like a really big deal. Of course, UEFI has been shipping into the PC market for years, but it’s never been … well, sexy. When 3TB drives started shipping last year, UEFI suddenly became important because of the need for GPT to overcome MBR partition limitations. When boot speed was the focus at the end of 2010, UEFI got a little more attention.

 

CES 2011 was a good show of new product releases that started developing with UEFI in 2009 and 2010. Since firmware is hard for some people to visualize, graphical BIOS setup is an easy way to show “under the hood” innovation to the press. Never mind the fact that the GUI isn’t mandatory, or that it’s only one way UEFI improves platform firmware. The emergence of graphics under UEFI just goes to show the universal rule of technology …

 

… everybody loves a good tradeshow demo

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

 

Got a question about BIOS or UEFI? … it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Ask a BIOS Guy: TianoCore

Posted by brian_ami Jul 19, 2010

It turns out that when you start a blog called “Ask a BIOS Guy,” people actually ask the author questions about BIOS. Trust me, it’s an amazing revelation. This week I’m answering a question about the TianoCore project that “ramsey” posed after reading my “Why UEFI” article.

 

“I understand Intel has an opensource EFI/UEFI solution called Tianocore that ppl experimenting with EFI can flash onto their platform and allow for boot? Or is Tianocore more of a build environment? Can you explain the distinction between what this opensource project provides vs. EFI based solutions provided by vendors like AMI?”

 

This is a great question. Answering it requires a little background, including the history of how Intel got involved in an open source project that delivers components for firmware developers.

 

Even though Intel is primarily known as a hardware company, a lot of their projects focus on software solutions. After all, the CPU and chipset don’t do much unless they’ve got software to run. As I explained in my first blog entry, UEFI was designed to solve a lot of problems common to BIOS developers, PC manufacturers, operating system developers and chipset manufacturers.

 

UEFI grew out of Intel’s Extensible Firmware Interface (EFI), which debuted on 64-bit Intel® Itanium® platforms. The change in processor architecture required a different approach to the firmware interfaces. The original EFI specification focused entirely on firmware-to-OS interfaces, modernizing what the 16-bit BIOS accomplished with software interrupts. Companies like AMI supported our own EFI-compatible implementations like Enterprise64.

 

Once the EFI concept started to extend beyond the Itanium family, there was some interest in having a common framework for exchanging chipset-specific code. Companies like Intel distribute “reference code” for the low-level initialization of silicon. This code is written by the same company that designs the silicon, so they have a better understanding of how the chip is supposed to work … plus, they have access to “undocumented knowledge” that can’t necessarily be shared with all of the BIOS providers.

 

TianoCore is the BSD open source implementation of the “Intel® Platform Innovation Framework for EFI,” which the rest of us started calling “the Framework” if only to save precious minutes on conference calls (plus “IPIFEFI” is a horrible acronym). This code became the EFI Development Kit (EDK), which is described on the project’s sourceforge page

 

The EDK is essentially a container for the Framework's Foundation code and sample drivers. The EDK is also a development kit for developing, debugging, and testing EFI and Framework drivers, EFI Option ROMs, and EFI Applications for use in the Framework environment.


The EDK is used as a building block for everything from device drivers to programs like AMIDiag for UEFI, a platform diagnostic that doesn’t need an OS to run. AMIDiag interfaces directly with UEFI so even if a system can’t boot to the OS it can be properly diagnosed. For embedded systems, this means you can diagnose the motherboard before trying to extract it from a hardened enclosure.

 

It’s important to note that the EDK isn’t intended to be a complete BIOS solution. Intel is many things, but it’s not a BIOS company. Normalizing the interfaces below the OS-to-firmware layer helps get silicon enabling code into the hands of developers faster. The silicon reference code and each BIOS vendor’s “secret sauce” don’t fall into the EDK … much like other commercial projects that incorporate open source in the base code. So the EDK isn’t a turnkey BIOS solution.

 

What a BIOS vendor provides is a complete solution for BIOS development. The EDK is a set of building blocks to help get started with UEFI. All of the BIOS vendors use elements of the EDK, but each one puts their own particular “value” on top of it. For AMI, it’s everything from an integrated development environment to a code structure that helps developers get source updates faster … plus flash utilities, debug tools, engineering services and technical support to help bring those products to market.

 

Once EFI adoption started to rise, everyone went to work on standardizing these elements. The EFI 1.10 specification became the basis of the Unified EFI (UEFI) specification, and the Framework kick started the UEFI Platform Initialization (PI) specification. This allows standardization at the OS-to-firmware interface and below it. TianoCore still lives in the UEFI world, hosting the EDK and other critical projects like the EFI Shell.

 

TianoCore and the EDK are a good are a good way to start learning about UEFI, and provide tools for more than firmware development. Device drivers, applications and OS loaders can all benefit from the EDK. It’s a good base for making better use of what the BIOS provides using UEFI.

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

Got a question about BIOS or UEFI? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Tablet computers seem to be all the rage, making your boxy desktop computer look even less hip. But that doesn't mean the BIOS underneath your “standard PC” is going away. It’s still as important as ever.

 

Touchscreen and tablet computers have been around for years, but for some reason they’ve always been a hard sell. I have personally benefitted from this lack of adoption, recently buying a cast-off Panasonic Toughbook with a lovely 10" touch screen for a mere fifty dollars.

 

But recently some turtleneck wearing hipster with a company named after a piece of fruit produced a pretty cool tablet computer, so the once maligned tablet PC is now the hottest thing since sliced pads … er, bread. Now the computer news is filled with new tablet designs based on Intel Architecture products.

 

Sure, the tablet PC is nothing new to Intel-based products. Products like the Panasonic Toughbook H1 medical tablet pre-dates our fruity friend by several years … but they’ve been part of a specialized market. Recent announcements like the Cisco Cius start blurring the lines between tablet and embedded telecommunications system. The embedded space also features Panel PCs … tablet functionality for more stationary systems.

 

So where the does the BIOS, long associated with expansion cards and keyboard-based interfaces, fit into the world of tablet computing? Well, the same place it’s always been.

At first glance, it’s easy to build an Intel tablet. There are a variety of low-power Intel Atom processors, which can be combined with an off-the-shelf operating system and commodity hardware to fit your particular form factor. So that’s pretty easy … now pick the OS.

 

Here’s where it gets complicated. Choose an established OS like Microsoft Windows 7, adapt an existing Linux distribution to be more tablet friendly or use one of the newer operating systems like MeeGo or Intel’s Android x86 port? As a tablet manufacturer, you may not want to choose right away, or you want the option to quickly switch to a new OS as the tablet market evolves.

 

Even though tablet users may never change the OS, using BIOS allows the tablet developer to quickly boot and test different operating systems. BIOS also opens up the possibility of booting recovery or installation disks from different media, like USB or SD slots.

 

So what happens to the things people associate with BIOS? The old school boot screen full of tech jargon has long since been replaced on most systems by a simple boot logo. With today’s short BIOS boot times, that screen flies by as the OS starts to load.

 

User setup on a tablet depends on the approach the developer wants to take. One approach is a "no touch configuration," removing the BIOS setup all together. Even without a standard BIOS setup screen, the system boot order can change dynamically if USB boot devices are added.

 

Another approach to user setup goes in the completely opposite direction, presenting a fully graphical setup that takes advantage of the touch screen. Companies like AMI provide everything from graphical setup layouts to on-screen keyboards in setup. This is an advantage if a company wants to market a "hackable tablet" to more tech savvy users.

 

So tablets change the form factor, but BIOS still plays the same role in system compatibility and configurability. Users may never see all of the options provided by the BIOS, but developers can use these tools to take full advantage of the Intel ecosystem.

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

 

Got a question about BIOS or UEFI? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Ben Hardwidge at THINQ recently wrote an “exclusive” article stating that MSI’s upcoming shift to UEFI means “BIOS could soon be on its deathbed”. I appreciate the attention Ben’s article has brought to UEFI and BIOS. It’s just too bad that most of the article is … well … wrong.

 

If only there was someone you could talk to about BIOS … oh wait, there is. Hi, my name is Brian and I’ll be your blogger today.

 

The way the THINQ article describes UEFI is a bit misleading …

 

"UEFI (universal extensible firmware interface) is a continuation of Intel's original EFI project, which was designed to replace the BIOS with a user-friendly point-and-click interface, as well as addressing many other troublesome areas of the PC's legacy."

 

UEFI actually stands for “Unified Extensible Firmware Interface.” The term “Unified” was added in 2005 when the EFI spec was transferred from Intel to a non-profit trade organization. I’ll let the UEFI home page explain it a little better …

 

"The UEFI specification defines a new model for the interface between personal-computer operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications."

 

It’s not hard to get confused over BIOS and UEFI. These technologies are behind-the-scenes in the industry and not well understood. I don’t want to spend this entire article describing why UEFI was developed, or what limitations exist in the legacy BIOS model (I did that last month). However I do want to correct some problems with the article, and address a few points brought up in the comments.

 

None of the UEFI specification deals with a “user-friendly point-and-click interface.” UEFI does define the Graphics Output Protocol (GOP), a great replacement for the troublesome VESA BIOS interface, but it doesn’t force anybody to use it. AMI has some pretty cool GUI options for Aptio, but they’re options that UEFI makes easier to implement. Many BIOS customers prefer the text interface: it’s well understood by technicians, lightweight and easily redirected to a console for remote management (serial port or serial-over-LAN). Yes kids, the VT100-style 80x25 interface is still a “feature” in the embedded market, so having a text-mode BIOS isn’t a disadvantage.

 

UEFI is an evolution of the BIOS model, backed by major players in the computer industry. Claiming UEFI is going to kill BIOS is like saying lizards killed off the dinosaurs, or the Intel® Core®™ i5 wants to take a tire iron to the Intel® Core2™ Duo. It’s something we all agreed was necessary (the evolution, not the tire iron), and over a hundred companies continue to participate in the development of the spec.

 

FYI: I use the term “we” because I was one of the first members of the UEFI board of directors.

 

The article’s anonymous source states that MSI is making the shift to UEFI as the default firmware on their platforms over the next three years. But that’s not an “exclusive” … it’s old news (same as the need for GPT on drives over 2.2TB). The entire PC industry is making the shift to UEFI, and some are already there. You might already be using UEFI and just don’t know it.

 

Look at MSI’s Wind series of netbooks … they use Aptio, which is AMI’s implementation of UEFI (complete with that “clunky” text interface).  The news for MSI is that they’re moving their motherboard products to UEFI (which I suspect is a larger part of their business). Even embedded computing, which is considered to be more conservative in adopting new technologies, has adopted UEFI over the past two years.

 

What the article’s anonymous source says about using UEFI on all motherboards is true, sort of. However, it has nothing to do with the UEFI specification …

 

"UEFI doesn't support every board; you have to use certain code with certain motherboards."

 

Translation for the BIOS-impaired: the BIOS on a motherboard is made for that motherboard. A UEFI-based BIOS for a new motherboard won’t work on a different model motherboard, but that’s the same for “classic” BIOS.

 

So UEFI is already here and in use on a lot of today’s computers … why does it still sound like “news” to people? We still call it “BIOS” whether it’s based on 16-bit legacy interfaces or UEFI because it does the same fundamental thing. We had this discussion at a UEFI meeting years ago, and we could come up with a better term (UEFIOS? BIOEFI?).

 

General Motors wants people to stop using the term “Chevy” in place of “Chevrolet” but it’s still a car and people still call it “Chevy” out of habit. After decades of personal computers, I don’t think it’s a big deal to keep the acronym.

 

Also keep in mind this transition from legacy BIOS to UEFI is deliberate. There’s a lot of infrastructure that has to change, from OS loaders to test utilities. Companies like MSI are making the shift to UEFI in a way that doesn’t disrupt their development cycle … and companies like AMI design their UEFI products to ease this transition.

 

There’s so much more I could talk about regarding UEFI and what it does to improve BIOS, but then I would have anything to say in the next article. A commenter using the handle ‘172pilot’ made this observation …

 

"EFI is coming, but this article misses the fundamental point, and implies that it's for the nice shiny wrapper. Nothing could be further from the truth."

 

I think that sums it up nicely.

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

 

Got a question about BIOS or UEFI? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

The wonderful thing about being stuck on the tarmac for three hours on a flight with “unforeseen technical difficulties” is that you have a lot of time to catch up on your reading. So you can thank airline-related mechanical failure for this week’s article on the BIOS and OS portability.

 

Scanning a pile of unread links in Google Reader lead me to this Slashdot article – “Installing Linux On ARM-Based Netbooks?”  The anonymous submitter is asking why it’s difficult to change the operating system on low-cost netbooks (from Microsoft Windows CE to Linux, or from one Linux distribution to another). Even the article says “ARM” in the title these cheaper computers run a variety of processor architectures (ARM or MIPS based).

 

Most of these low-end netbooks load the OS from flash memory instead of a hard disk or solid-state drive (SSD). This means the computer is hard-coded to launch the primary operating system (in most cases, an older version of Microsoft Windows CE). A normal PC user would just put a different OS on a USB thumb drive and change the BIOS settings … but these platforms don’t have a BIOS.

 

Since the platform designer assumed the end user won’t change the OS, they use a simple bootloader to bootstrap the OS image in flash memory. The good news: the system is cheaper. The bad news: upgrading the system or changing the OS requires a soldering iron, “1337 skillz” or whatever computer they use in the movies that hacks into high-security networks in under sixty seconds (I checked Fry’s already, they’re out of stock).

 

I do want to point out this is not a knock against ARM or MIPS. I know, I’m writing an article for an Intel website, but the lack of OS portability has more to do with firmware than hardware (bootloader versus BIOS). The PC’s inherent configurability made it very easy for operating systems like Linux and FreeBSD to gain traction on Intel Architecture platforms, and using something like a bootloader to latch one specific OS to the platform takes away from that flexibility.

 

A good example is the MeeGo project, which recently released a downloadable image for version 1.0. It’s pretty easy to test it on a netbook with the right hardware requirements … download the image file, write it to a USB key and boot to the USB key. With a few hours of its release I had MeeGo v1.0 installed on my Intel Atom-based netbook. It’s the same experience as booting to a Microsoft Windows or Linux install DVD.

 

On Intel Architecture platforms, MeeGo uses the same boot process as any other Linux-based OS:

  • BIOS initializes the hardware at power-on
  • BIOS builds a set of runtime interfaces for the OS
  • BIOS bootstraps the OS loader
  • OS kernel uses information from the BIOS to determine how to configure the system

MeeGo is portable to non-Intel platforms like the ARM-based Nokia N900, but that OS image is ported to one specific system. Getting it to boot on a different platform is probably non-trivial, because there isn’t a BIOS to handle the OS-to-hardware interface.

 

So what does this have to do with embedded computing? These inexpensive netbooks are prime examples of how embedded systems were traditionally designed … the hardware and software get tied together in a way that makes it difficult to separate them. In today’s embedded computing market, this model is starting to go away.

 

With more COTS hardware available for extreme temperature ranges and low-power consumption applications, embedded developers have to consider application portability. Embedded platform designers can address this need by making it easy for their end customer to swap operating systems, which is a key feature of BIOS in the Intel Architecture ecosystem. Keep this in mind the next time you’re designing an embedded solution.

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

 

Got a question about BIOS? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

One of the reasons I started this blog is to take some of the mystery out of BIOS, which is often portrayed as arcane computing … some combination of technology and black magic. I think it’s valuable to take time in this forum to expose the type of tools available to the BIOS developer. Today’s article focuses on how an Independent BIOS Vendor (IBV) handles debugging BIOS issues.

 

The goal for any BIOS vendor is to deliver a product that doesn’t require extensive debugging. Of course, things don’t always go the way we plan … just like I didn’t plan to spend last weekend having my car repaired, or wait on that tow truck in the rain …

 

Anyway, let’s look at three different scenarios for debugging BIOS on an embedded Intel Architecture system:

  1. Debugging BIOS on a deployed system: determine where the BIOS hangs in the boot process and view extended error codes
  2. Debugging BIOS during development without source code: view verbose debug and trace messages as the BIOS executes
  3. Debugging BIOS during development with source code: analyze, stop and step-through BIOS source code on a debug target system

Deployed Systems

For this example, assume a “deployed system” is setup to work as the customer would receive it. This can be a system in the field or one submitted to quality assurance for integration testing.

 

Debugging BIOS on this system uses checkpoints to show progress through the boot process. BIOS checkpoints are also useful for quality assurance processes, helping to identify where the BIOS may be hanging in the boot process. Think of like the diagnostic module they attach to a car when the “check engine” light comes on (you think that light would come on before the engine starts to smoke).

 

The important thing about debugging BIOS in a deployed system is that it shouldn’t be too intrusive … this is a solution that has to work in the field. In the past checkpoints were viewed on a “checkpoint card” (also known as a “port 80 card” since the checkpoints go to I/O port 0x80). Adding such a card requires an open PCI slot (not common in today’s systems) or a LPC bus header (somewhat proprietary). Both require opening the case, which is tough to do on today’s systems … just look at small form factor platforms like Qseven or the Intel® Embedded Development Board 1-N450.

 

Some board vendors create proprietary methods for displaying BIOS checkpoints, but there are solutions that solve the “open case problem.”  AMIDebug™ Rx is one example, using the USB debug port functionality on Intel USB 2.0 controllers. This solution uses a commodity port that doesn’t require the case to be opened, and lets the USB port to operate normally when AMIDebug Rx is disconnected.

 

Advanced Debug Without Source Code

Development debugging without source code used to rely only on checkpoints, but that has changed with the introduction of UEFI. I discussed the user advantages of UEFI in my previous blog article, but there are numerous developer advantages as well. UEFI defines a set of debug strings, displaying verbose information about the boot flow. Debug strings are enabled when the BIOS is compiled and are routed to a secondary output (keeping them separate from the main system display).

 

[AmiDbg]NBPEI.Entry(FFFF495B)

[AmiDbg]SBPEI.Entry(FFFF1AED)

[AmiDbg]>>> PM Registers Before GPIO Init <<<

[AmiDbg]+===================== PM Registers dump =====================+

[AmiDbg]  PM1a_EVT_BLK.PM1_STS      : Addr = 0400 => Val = 0001

[AmiDbg]  PM1a_EVT_BLK.PM1_EN        : Addr = 0402 => Val = 0000

[AmiDbg]  PM1a_CNT_BLK.PM1_CNT      : Addr = 0404 => Val = 00001C00

[AmiDbg]  PMTMR_BLK.PM1_TMR          : Addr = 0408 => Val = xx9E5F20

[AmiDbg]  P_BLK.PROC_CNT            : Addr = 0410 => Val = 00000000

[AmiDbg]  GPE0_BLK.GPEO_STS          : Addr = 0428 => Val = BDFF0000

[AmiDbg]  GPE0_BLK.GPEO_EN          : Addr = 042C => Val = 00000000

[AmiDbg]+==================== SMI Registers dump =====================+

 

That sequence may look like nonsense to the average user, but it’s great information for debugging UEFI platforms. UEFI debug strings are the equivalent of verbose messages in the Linux kernel, more detailed than basic checkpoints and far more informative than what that so-called mechanic told me about my transmission.

 

[AmiDbg]Register PPI Notify: 605ea650-c65c-42e1-ba80-91a52ab618c6

[AmiDbg]PEIM 8401a046-6f70-4505-8471-7015b40355e3 was not started!!

[AmiDbg]PEIM e008b434-0e73-440c-8612-a143f6a07bcb was not started!!

[AmiDbg]PEIM 32505be8-6469-4f79-9b01-66b3f9617e7d was not started!!

[AmiDbg]PEIM a47438d5-94e9-49b3-bc31-7e6bc9363814 was not started!!

 

I know, it’s hard to believe any of that makes sense … just trust me.

 

That stream of technical nonsense doesn’t get built into a production BIOS, but developers can enable it during development for advanced debugging. These strings can be piped to a RS-232 serial port or captured by USB debug devices like AMIDebug Rx (for systems that do not include a legacy serial port).

 

Advanced Debug With Source Code

Development debugging with source code is the most detailed level of BIOS debugging, adding the ability to step and trace through code in real-time. It’s the best way to see “under the hood” of the BIOS while it runs, assuming the hood isn’t in flames on the side of the highway. You would think something wouldn’t burn like that in a rain storm …

 

Sorry, where was I? Right, source level debugging.

 

Compiling BIOS in debug mode generates a MAP file, used to connect the execution of BIOS on a debug target back to the exact line of source code on the debug host system. If your boss asks, tell them it’s like a GPS that understands processor instructions. The trick is connecting the two systems so the target BIOS can be controlled by an application on the host system. There are two common methods … one connects to the processor, the other connects to the BIOS.

 

A direct processor connection uses a JTAG port, allowing a processor emulator to be connected to the system. Companies like Arium,  market devices that connect to the Intel XDP connector, enabling direct control of the processor at the reset vector. (Arium is an Affiliate member of the Intel® Embedded Alliance).

 

Connectors like Intel XDP are common on development boards, but rarely seen on production platforms. For this reason, BIOS developers market alternatives that give the same level of debug control to systems without XDP or JTAG ports. Each BIOS vendor has a variation of this tool. At AMI, the AMIDebug Rx is used as a host-to-target connection enabling the AMI Debug suite to run prior to memory detection. This type of BIOS debug tool allows JTAG-style debugging on production level hardware.

 

Debug, Debug and Debug Some More

BIOS development isn’t as widely understood as driver or application development, but a variety of debugging methods exist. Platform developers can do everything from diagnose systems in the field to trace source code.

 

I wonder if my car had a USB debug port. I’ll ask the insurance company about that once the fire department gets done with my car …

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

 

Got a question about BIOS? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Ask a BIOS Guy: "Why UEFI"

Posted by brian_ami May 10, 2010

If you've looked at anything related to the Basic Input/Output System (BIOS) in the past few months, you’ve seen the acronym “UEFI” a lot. Not only are the major BIOS vendors offering UEFI solutions, but Intel uses UEFI for embedded development  platforms and customer reference boards.

 

There’s piles of technical nonsense we can discuss here for firmware developers …  documented protocols, drivers that replace legacy Option ROMs, C programming interfaces, support for IA32 and x64 architectures. But in this jargon it’s important to understand the benefits UEFI has for system users. I believe we know them better as “customers”.

 

BIOS in the Intel® Ecosystem

In Intel® Architecture, BIOS provides low-level hardware initialization, software portability and easy migration to different operating systems on the same platform. This is why the motherboard you buy at the store can run everything from Microsoft Windows 7 to Ubuntu out of the box … or why a single embedded system can run everything from MeeGo to Microsoft Windows Embedded without altering the firmware. It’s a huge advantage in the Intel ecosystem.

 

But the legacy 16-bit BIOS architecture has limitations, which is why the industry developed the Unified Extensible Firmware Interface (UEFI). This new level of standardization opens up an architecture-independent set of interfaces, going beyond the original BIOS. Let’s look at three areas where UEFI brings clear advantages … drive size limits, pre-boot networking and pre-boot applications.

 

Drive Size Limits

The issue facing most customers this year is booting to a drive over two terabytes (2TB) in size. This doesn’t sound like a problem for most embedded developers, until you think about the storage requirements of digital surveillance or medical imaging systems. The master boot record (MBR) partitioning scheme uses 32-bit values to describe partition offsets and length, which limits the largest disk partition to around 2.2TB. It’s not just a BIOS limit, since the OS uses the same MBR data in the boot loader.

 

The UEFI alternative to MBR is the GUID Partition Table (GPT). GPT disks use 64-bit values to describe partitions, handling disk sizes up to 9.4 zettabytes (go look that up, it’s way bigger than any Wall Street bonus paid out last year). GPT also fixes other issues related to MBR (data integrity, backup tables and maximum number of partitions). The UEFI Forum has a FAQ on Drive Partition Limits with more details.

 

Pre-Boot Networking

Next is networking and the coming day when our various connected devices use up every IP address on the planet. My IT manager insists this is a big deal, making it sound like the plot to one of those end-of-the-world disaster films. But before you go building an ark or stocking up on canned goods, you should know the industry has already been working on a solution.

 

The IPv6 specification has been in development for years, overcoming the limitations of the current IPv4 specification (to be fair, four billion IP addresses sounded like a lot in the 1980’s). UEFI incorporates IPv6 as well, so network booting and remote management capabilities integrate seamlessly as the industry migrates to this new networking standard.

 

Pre-Boot Applications

Finally we look at pre-boot applications … programs designed to run in between the end of the BIOS but prior to the operating system. These applications have been around for years, usually embedded in the flash part with the system BIOS or tucked away on a hidden disk partition.

The problem with most pre-boot applications is making them platform independent. UEFI’s documented interfaces for boot and runtime services give developers a clean method of accessing essential routines without the need for an OS kernel or driver stack. Even graphical interfaces are possible, relying on the new UEFI Graphics Output Protocol (GOP) instead of older VESA VGA interfaces.

 

One real-world example is Dell’s Unified Server Configurator (USC), designed by Dell and AMI to simplify server deployment. This UEFI graphical application eliminates the need for the “system DVD” and has been shown to speed up bare-metal provisioning. It’s just one example of using native UEFI applications to provide value-add services. Embedded diagnostics, network-based BIOS update utilities and system recovery can be part of a COTS platform, no matter what OS the customer deploys.

 

More to UEFI Than Meets The Eye

Since I’m a “BIOS Guy” I could ramble on for pages about UEFI … but the important thing to understand is that the benefits aren’t just for BIOS developers. UEFI enables features that trickle down to a better customer experience, and are already being seen in today’s platforms. If you need BIOS for an upcoming Intel platform, it’s best to learn more about UEFI.

 

Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.

 

American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.

 

Got a question about BIOS? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Filter Blog

By date: By tag: