This week I've spent hanging around Linaro Connect 2013 USA, which is dedicated to bringing all of the open-source (and Linux) goodness to the ARM platform. For the 64-bit ARM architecture (AArch64), they have been promoting UEFI for quite a while but Linaro and its members are doing a lot of the really hard work of making sure that is a reality, with engineers dedicated to working from the reset vector up through the Linux kernel and into some server applications, making sure that all the necessary bits are there in open source. There were a lot of sessions this week that deal with the thorny issues of UEFI (secure boot), power management (PSCI) and ACPI (interaction with existing drivers and FDT). To top it off, this event was co-located with ARM TechCon which doubled the fun, including an interesting keynote by Simon Segars, CEO or ARM.
This follows on the heels of the UEFI Plugfest, which was co-located also, but with LinuxCon in New Orleans. My colleague, Jeff Wheeler from Insyde got to attend, and he found folks interested in the question, "Does it really work?" And the answer was, "Yes, it does" This is the impression I recently found from Bruno Cornec's blog article "First UEFI PlugFest for Linuxers". Good communication, good testing and, more importantly, UEFI and Linux work together.
The relationship between Linux and UEFI has not always been easy, with conspiracy theories and suspicious kicking of tires. But these two events have shown that they can and do work together, on x86 and ARM.
Thursday, October 31, 2013
Tuesday, October 29, 2013
ACPI Specification Now Managed By UEFI, and Why Anyone Should Care
This article by my UEFI colleagues Dong Wei (HP, VP of UEFI) and Andrew Sloss (ARM, ARM Binding Sub-Team Chair) talks about a large recent development in the firmware world: ACPI is now managed by UEFI. I was a part of the ACPI specification development starting with ACPI 2.0 up through the current ACPI 5.0 specification while I was employed with Phoenix Technologies. That specification seems unusual to me now, in that it was essentially a five-way agreement between Intel, Microsoft, Compaq/HP, Phoenix and Toshiba. But actually, back in the day when it was conceived, it wasn't that unusual, as the BIOS Boot Specification (BBS) or Advanced Power Management (APM) will attest. For every revision of the specification, essentially the 5-way consortium was reborn again, occasionally (such as when Phoenix was added or Compaq was merged with HP) with a change of membership.
Due to the unusual structure and the fact that it was tied in many ways to Microsoft's release schedule and Intel's hardware schedule, releases tended to be big and cumbersome. Adding new members was problematic, since the number of signatures required from legal departments grows exponentially.
On the other hand, UEFI has functioned pretty well since 2005 in taking input, releasing regular errata and specification updates. So with Mark Doran (Intel, UEFI president) assuming the helm of both efforts, it seemed like a good time to push them together. They really address the same target audiences: system firmware providers, OS vendors, OEMs and chip manufacturers, with a smattering of plug-in card and application vendors. It probably helps convince folks like Linaro (working on ARM) and Redhat (working on Linux) to adopt ACPI if more than Intel and Microsoft are represented.
Now the process that is used to gather input, hash out differences and formulate solutions for UEFI can be applied to ACPI with, in my opinion, great effect.
Due to the unusual structure and the fact that it was tied in many ways to Microsoft's release schedule and Intel's hardware schedule, releases tended to be big and cumbersome. Adding new members was problematic, since the number of signatures required from legal departments grows exponentially.
On the other hand, UEFI has functioned pretty well since 2005 in taking input, releasing regular errata and specification updates. So with Mark Doran (Intel, UEFI president) assuming the helm of both efforts, it seemed like a good time to push them together. They really address the same target audiences: system firmware providers, OS vendors, OEMs and chip manufacturers, with a smattering of plug-in card and application vendors. It probably helps convince folks like Linaro (working on ARM) and Redhat (working on Linux) to adopt ACPI if more than Intel and Microsoft are represented.
Now the process that is used to gather input, hash out differences and formulate solutions for UEFI can be applied to ACPI with, in my opinion, great effect.
"UEFI brings in an amazing level of standardizaton for boot loaders"
The title comes from one slide in the "Is UEFI EDK II ready for Android mobile" session at the Linaro Connect 2013 event in Santa Clara, this was on one of the slides. Here is what was presented as advantages for UEFI on ARM and Android Mobile:
- Very detailed specification from UEFI forum of industry experts
- Reduce cost of development, code is highly organized and structures - easy to add support for new platforms.
- Drivers can be independenly developed and distributed by peripheral/controller manufacturer, just like in any high level OS
- Brings in concept of "application" at boot loader level itself, can be used for test suite development, new functionality like flashing utilities, splash screens, etc.
Tuesday, October 22, 2013
PI 1.3 Review, Part 3: Updates to FindSectionData PEI Services
This article is the third in a series describing the changes made in the PI 1.3 specification. This time we look at a new entry added to the PEI Services table: FindSectionData3(). There's only one problem: this function doesn't actually show up in the table of contents, even though it is listed in the PEI Services Table in section 3.2.1 of Volume 1 of the PI.
So what happened? Well, it turns out that this function is an update to another PEI Service: FindSectionData() and simply adds a new parameter: AuthenticationStatus. This returns the result of authentication for a specific single section. The PEI core has access to this information, when it calls the Security Architecture PPI, but never passed it back. This meant that some callers, such as implementations of the Load File PPI, would have to either call the Security Architecture PPI themselves (adding delay and complexity) or hard-code it to 0 (which is what the tianocore implementation was doing). This new PEI Service optionally returns this and does so in a way that the previous function (FindSectionData()) could be implemented by calling the new function, just setting AuthenticationStatus to NULL.
But when the new function was added to the specification, there was an editing error. The new function parameter was added to FindSectionData(), which was the existing function and the new function (FindSectionData3()) is nowhere to be found. I expect this will be fixed in an errata.
Now PI 1.3 has the ability to parse firmware volumes in a secure (!) and fast (!) manner.
So what happened? Well, it turns out that this function is an update to another PEI Service: FindSectionData() and simply adds a new parameter: AuthenticationStatus. This returns the result of authentication for a specific single section. The PEI core has access to this information, when it calls the Security Architecture PPI, but never passed it back. This meant that some callers, such as implementations of the Load File PPI, would have to either call the Security Architecture PPI themselves (adding delay and complexity) or hard-code it to 0 (which is what the tianocore implementation was doing). This new PEI Service optionally returns this and does so in a way that the previous function (FindSectionData()) could be implemented by calling the new function, just setting AuthenticationStatus to NULL.
But when the new function was added to the specification, there was an editing error. The new function parameter was added to FindSectionData(), which was the existing function and the new function (FindSectionData3()) is nowhere to be found. I expect this will be fixed in an errata.
Now PI 1.3 has the ability to parse firmware volumes in a secure (!) and fast (!) manner.
Monday, October 21, 2013
IPv6 Network Boot with UEFI
Vincent Zimmer has just put up a nice little post how configuring IPv6 network boot with UEFI over on his blog here. As usual, we need him to write more since so much of the UEFI network stack was overseen by the UEFI Network Sub Team (UNST), of which he is the chair.
Tuesday, October 15, 2013
PI 1.3 Review, Part 2: PI Status Codes
This is the second article in a series describing the changes in the PI 1.3 specification. This article focuses on the updates to the PI status codes. Actually, quite a minor change, these add status codes for the firmware if it implements support for the ATA specification's Self-Monitoring, Analysis and Reporting Technology (SMART) feature set for hard drives. This feature set allows software to query the hard drives and ask about the types of faults experienced with a view of predicting eventual hard drive failure.
These status codes provide a standardized way for the system firmware to report when SMART is being enabled (EFI_IOB_ATA_BUS_SMART_ENABLE) or disabled (EFI_IOB_ATA_BUS_SMART_DISABLE) or whether it is not supported by the drive (EFI_IOB_ATA_BUS_SMART_NOTSUPPORTED). It also allows the firmware to report if it detects on the many classes of alert conditions, using EFI_IOB_ATA_BUS_SMART_UNDERTHRESHOLD and EFI_IOB_ATA_BUS_SMART_OVERTHRESHOLD.
One of the interesting things is why these were not in the PI Specification in the first place, even though they were in the EDK implementation that Intel developed around the same time. After the EFI 1.10 specification was released, there was a relatively long hiatus with no additional specification versions being released with new material, except for minor errata. People (meaning Intel, Microsoft and a few other companies) were fairly satisfied with EFI 1.10 but who was going to do all the dirty work to implement it. So Intel wrote down the Platform Innovation Framework (or PIF) specification and created a corresponding implementation, called Tiano, showing what they considered best practice for creating EFI implementations. From some comments, Intel intended that much of this work would end up in the future EFI (not UEFI) 2.0 specification.
But then UEFI came, forged by the original nine promoter companies, including Insyde. Intel suspended work on the PIF specifications. But work continued internally. When it came time for the PI specification to be created, using the PIF specifications as a starting point, we tried to gather up any loose ends from Intel's on-going development, but we failed to get these status codes. And thus, SMART status codes were all there; everyone knew about them; but they weren't the standard.
And now they are. So PI 1.3 finally catches up with PIF (at least in this area).
These status codes provide a standardized way for the system firmware to report when SMART is being enabled (EFI_IOB_ATA_BUS_SMART_ENABLE) or disabled (EFI_IOB_ATA_BUS_SMART_DISABLE) or whether it is not supported by the drive (EFI_IOB_ATA_BUS_SMART_NOTSUPPORTED). It also allows the firmware to report if it detects on the many classes of alert conditions, using EFI_IOB_ATA_BUS_SMART_UNDERTHRESHOLD and EFI_IOB_ATA_BUS_SMART_OVERTHRESHOLD.
One of the interesting things is why these were not in the PI Specification in the first place, even though they were in the EDK implementation that Intel developed around the same time. After the EFI 1.10 specification was released, there was a relatively long hiatus with no additional specification versions being released with new material, except for minor errata. People (meaning Intel, Microsoft and a few other companies) were fairly satisfied with EFI 1.10 but who was going to do all the dirty work to implement it. So Intel wrote down the Platform Innovation Framework (or PIF) specification and created a corresponding implementation, called Tiano, showing what they considered best practice for creating EFI implementations. From some comments, Intel intended that much of this work would end up in the future EFI (not UEFI) 2.0 specification.
But then UEFI came, forged by the original nine promoter companies, including Insyde. Intel suspended work on the PIF specifications. But work continued internally. When it came time for the PI specification to be created, using the PIF specifications as a starting point, we tried to gather up any loose ends from Intel's on-going development, but we failed to get these status codes. And thus, SMART status codes were all there; everyone knew about them; but they weren't the standard.
And now they are. So PI 1.3 finally catches up with PIF (at least in this area).
Thursday, October 10, 2013
PI 1.3 Review, Part 1: I2C Bus Protocol
This article is the first in a series describing the changes in the Platform Initialization (PI) 1.3 specification. The PI specification is like the unheralded younger brother of the UEFI specification. From the very beginning it was a requirement that PI implementations be able to produce UEFI, but it was also a requirement that UEFI drivers and applications and OS loaders not depend on the PI specification. If something was really needed for UEFI, it would get promoted (yes, that is the word used) from the PI specification. Why? Because there have been (and are) implementations of UEFI which are not built on top of the tianocore.org EDK1 or EDK2 implementations or even Intel's older Platfrom Innovation Framework.
It was named the Platform Initialization (PI) specification because, in the UEFI 2.0 specification (and the earlier EFI 1.x specifications), one of the block diagrams of UEFI had a big blank box labeled (you guessed it): "Platform Initialization" UEFI really deals with booting. Yes, yes, there's a lot of other stuff around user interface (HII) and security and networking, but it is all about finding the right boot device and loading the OS. If you are not a boot device (or a video device or a keyboard), you don't really get a lot of respect in UEFI. That is PI. So, what's in there? Well, there's memory controllers, GPIOs, system management mode (SMM), PCI root bridges, super I/O controllers, embedded controllers, and yes, I2C and SMBus. All in the PI specification.
I2C didn't get a lot of respect either in the UEFI world, ever since Intel began promoting the smarter, enumerable version, called SMBus. But it turns out that, as a simple, low-cost, low speed, low-power bus, it works well for controlling on-the-motherboard devices, like touch panels, MEMS sensors, small EEPROMs and other devices with relatively low data rates. Also, SMBus didn't really like multiple speed devices.
Within PI, SMBus suffered from only have a host controller protocol, but it was never extended out to a true driver stack like, say, USB or PCI. Sad. If you want to see how its really done, look at my presentation from the UEFI plugfest back in 2011.
But back to I2C. The following diagram shows the typical driver stack. It looks very similar to the typical UEFI driver stack, with a host controller protocol and an I/O protocol. But after that it gets a bit strange: what are the enumerate, bus configuration management and master protocol?
First, it is important to understand the I2C is not really enumerable. You can't poke at some register and discover that a device is present. At least not reliably, from a bus driver perspective. USB and PCI and SMBus are examples of enumerable buses. So, instead, the I2C driver stack relies on a platform driver to produce the I2C Enumerate protocol to return back a list of devices actually present on the platform.
Second, since it is possible for the I2C bus to be one of several different configurations, it is important that the bus be placed in the right configuration before talking to a specific device. For example, if the bus speed must be changed, or a multiplexer must be set so that I2C devices are actually connected to the controller. That control is provided by the I2C Bus Configuration Management protocol.
Third, the host controller support is divided into two pieces: the Master protocol and the Host protocol. In general, the device driver's use the Host protocol to queue an I2C transaction. The Master protocol is used when it is necessary to go out of order and send an I2C command. This happens, for example, when the platform driver needs to send an command to a multiplexer or bus clock device before an I2C command is sent to a device.
With the I2C protocols, the PI 1.3 specification gives a driver stack so that you can write a device driver for an I2C device that works on any platform. But this is only for DXE. In PEI, only the Master capabilities are available through the I2C Master PPI.
It was named the Platform Initialization (PI) specification because, in the UEFI 2.0 specification (and the earlier EFI 1.x specifications), one of the block diagrams of UEFI had a big blank box labeled (you guessed it): "Platform Initialization" UEFI really deals with booting. Yes, yes, there's a lot of other stuff around user interface (HII) and security and networking, but it is all about finding the right boot device and loading the OS. If you are not a boot device (or a video device or a keyboard), you don't really get a lot of respect in UEFI. That is PI. So, what's in there? Well, there's memory controllers, GPIOs, system management mode (SMM), PCI root bridges, super I/O controllers, embedded controllers, and yes, I2C and SMBus. All in the PI specification.
I2C didn't get a lot of respect either in the UEFI world, ever since Intel began promoting the smarter, enumerable version, called SMBus. But it turns out that, as a simple, low-cost, low speed, low-power bus, it works well for controlling on-the-motherboard devices, like touch panels, MEMS sensors, small EEPROMs and other devices with relatively low data rates. Also, SMBus didn't really like multiple speed devices.
Within PI, SMBus suffered from only have a host controller protocol, but it was never extended out to a true driver stack like, say, USB or PCI. Sad. If you want to see how its really done, look at my presentation from the UEFI plugfest back in 2011.
But back to I2C. The following diagram shows the typical driver stack. It looks very similar to the typical UEFI driver stack, with a host controller protocol and an I/O protocol. But after that it gets a bit strange: what are the enumerate, bus configuration management and master protocol?
First, it is important to understand the I2C is not really enumerable. You can't poke at some register and discover that a device is present. At least not reliably, from a bus driver perspective. USB and PCI and SMBus are examples of enumerable buses. So, instead, the I2C driver stack relies on a platform driver to produce the I2C Enumerate protocol to return back a list of devices actually present on the platform.
Second, since it is possible for the I2C bus to be one of several different configurations, it is important that the bus be placed in the right configuration before talking to a specific device. For example, if the bus speed must be changed, or a multiplexer must be set so that I2C devices are actually connected to the controller. That control is provided by the I2C Bus Configuration Management protocol.
Third, the host controller support is divided into two pieces: the Master protocol and the Host protocol. In general, the device driver's use the Host protocol to queue an I2C transaction. The Master protocol is used when it is necessary to go out of order and send an I2C command. This happens, for example, when the platform driver needs to send an command to a multiplexer or bus clock device before an I2C command is sent to a device.
With the I2C protocols, the PI 1.3 specification gives a driver stack so that you can write a device driver for an I2C device that works on any platform. But this is only for DXE. In PEI, only the Master capabilities are available through the I2C Master PPI.
Subscribe to:
Posts (Atom)
