"Advances in Platform Firmware 'Beyond BIOS'" - 10 years later.....

The last ten years have witnessed remarkable progress in the evolution of standards-based firmware. In this blog posting I review some of the events and changes that have occurred since the paper Advances in Platform Firmware Beyond BIOS and Across All Intel® Silicon was published in the Technology @ Intel online magazine on January, 2004.

Although back issues are no longer posted on Intel's website, a copy can be found at UPDATE or https://github.com/vincentjzimmer/Documents/blob/master/it01043.pdf

For this blog in January 2014, let's discuss what has changed since this paper was published in January of 2004. The first change at the Intel level is the logo. Instead of the drop-e in the logo, viz.,

2006 and onward featured the new Intel logo.

or a recent shot of the logo at the company headquarters.

At a personal level, the bio on the paper lists me as a 7 year Intel veteran w/ "100 US patents pending or issued." Of those 100, probably 10 were issued at that time. Today on the front door of my 17 year anniversary, my patent count is nearly 300 issued and 500 pending. Also, my job description has changed a few times, as has my business unit name (not my team & its charter), since 2004.

Another interesting aspect of this paper includes the number of translations. Works like Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ are only available in English, as are the Intel Tech Journal papers http://www.intel.com/content/www/us/en/research/intel-technology-journal/2011-volume-15-issue-01-intel-technology-journal.html, whereas this 2004 paper was translated into Japanese JP, Portuguese PG, Russian RU, Spanish SP, and even showed up on a Chinese website CN in translation.

In addition to the translations, an Intel Press editor noticed this article and offered me the chance to write Beyond BIOS back in 2004, too, after several others had passed on a request to pen a book on the same. In the ensuing decade since this paper's publication I've used the term "Beyond BIOS" a few times, as can be seen in a search of CV for that 2-tuple of words. The dialectic becomes especially interesting when people classify UEFI as a type of BIOS, viz., "UEFI BIOS." So how to go 'Beyond BIOS' in that case?  Another logical antimony like Russell's Paradox http://en.wikipedia.org/wiki/Russell's_paradox for firmware, I suppose.

Beyond these personal details, though, the evolution of the firmware technology has experienced the most pronounced changes. Specifically, in 2004 we referred to the Framework specifications as "The Intel(R) Platform Innovation Framework for the Extensible Firmware Interface." We internally joked at the time that reading off the title consumed more time than the firmware needed to boot a system. In 2004 the "Tiano" code base was an internal project and formatted as a monolithic entity, namely the "Tiano release X", where 'X' varied as we evolved the implementation to support the 30 Framework specifications and EFI 1.10 specifications. At that time, these were the only public firmware specifications and were hosted at intel.com.

After 2005 the EFI, and then Framework, specifications evolved into the UEFI and PI specifications, respectively, as shown in the timeline below.

And during the ensuing decade after this paper's publication, the Tiano implementation went open source at http://www.tianocore.org, the UEFI specification evolved from UEFI2.0 to the most recent UEFI2.4 on http://www.uefi.org, and the UEFI Platform Initialization (PI) specifications evolved from PI1.0 to PI1.3. The specification timeline appears at the top portion of the figure, too. The bottom portion of the figure demonstrates the evolution of the code base, namely from the monolithic EFI Developer Kit I (edk1) to the package-based, modular, cross-platform buildable EFI Developer Kit II (edk2). The UDK is a validated, supported snapshot of a subset of the edk2 project.

And as far as hardware support is concerned, the 2004 paper discusses Itanium, IA32, and XScale as supported by the code-base. Since then, Intel divested of its XScale product line, ARM added its 32-bit and 64-bit bindings to the UEFI specification and the edk2, and Intel evolved to 64-bit with x64.

Regarding security, the paper also talks about 'cryptographically validated' modules before use. Since then, the industry has evolved Secure Boot technologies that span from the hardware, through the firmware phase, and culminating in the hand-off to the OS loader with UEFI Secure Boot.

The venerable boot flow of Figure 1 in the paper is largely the same as today, including liberal re-use of that figure across many subsequent publications. And the 'design-by-interface' nature of EFI/Framework, via today's UEFI/PI, still apply. With codified API's in the specification and GUID-managed namespaces to avoid collision between 3rd party innovations and API's managed by the standards group, UEFI/PI has been holding its own quite well.

As I pause and reflect, in the 1990's I recall having several volumes of the Win32 API in hard copy. At the time, I thought that API's came down from the deity in a fully-formed state.  Late 90's coincided with my joining the EFI team that ultimately delivered the EFI1.02, EFI1.0, UEFI2.0-2.4 specs, Framework 0.1-0.9x, and PI1.0-PI1.3 documents. In that ensuing decade and a half I realized that infrastructure doesn't just appear overnight, sort of like Athena being borne full-grown from Zeus's head. 

Now for my vantage of today, I realize that infrastructure evolves in an organic fashion over time, from a couple hundred to several thousand pages, a reference implementation from the 10's of KLOCs to millions of lines of code. But that's where the design principles and the underlying conceptual integrity really matter. And for this posting, the prevalence of the assertions in the above cited white paper and today's deployed UEFI + PI art with its corresponding implementation in open source attest to that fact.

Beyond this memory lane trek for the UEFI and PI specs, the most exciting recent culmination of this effort involves Galileo and Quark http://www.intel.com/content/www/us/en/processors/quark/intel-quark-technologies.html and its recent open source action. Specifically, the board support package (BSP) zip and documents for the Quark can be found at the URL 

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23197. This package contains the file Quark_EDKII_v0.9.0.tar.gz which includes UEFI PI packages with full source code that build in an edk2 tree https://svn.code.sf.net/p/edk2/code/trunk/edk2/. This allows for using open source tools like GCC, edk2, and this .7z file to provide a full bootable solution for Quark. This package includes memory reference for the PEIM, SMM infrastructure and sample drivers, and other SI initialization code. Historically many of these codes have been withheld from open source for Intel hardware.

A new processor family and all of the edk2 source code to build the platform available in open source. Things don't get more exciting than this. Here's a picture of the one I purchased from Amazon http://www.amazon.com/Intel-Galileo1-DDR2-1066-Motherboard/dp/B00GGM6KJQ/ 

So has the journey ended with this decade-later milestone? In my opinion, 'no.' I view the evolution of technology in spatial terms, as shown in the figure below. 

The Left-Right, or East-West headings include scaling and broad adoption of the standards and source technology, which has been happening over the last decade, with the broad adoption of UEFI in the release of Microsoft Windows(R) 8 and the requirements around UEFI for booting. East-West also includes adoption of UEFI and PI by new device segments, such as the Quark device mentioned above.

In my mind, north includes accretion of additional functionality on top of UEFI, such as more networking capabilities like the HTTP-boot mentioned in http://tools.ietf.org/rfc/rfc5970.txt, richer usages, etc. Moving south involves leveraging the PI infrastructure for new distribution mechanisms of code like FSP, hardware/firmware co-design http://www.google.com/patents/US8522066, etc.

I try to be consistent in my view of life, so hopefully this 10-year retrospective exemplifies my sentiment of "I would argue that the landscape for invention, innovation, and creation has never been more fertile" from http://vzimmer.blogspot.com/2013/03/a-technical-career-path.html, too. 

Another ironic aspect of taking the long, retrospective view of the project includes the response of others. During the earlier portion of the decade I spent quite a bit of time engaging with both internal and external teams on adoption. Prior to the broad industry embrace of the technology, many teams were wary of engaging. This reminds me of the John F. Kennedy quotation of "Victory has a thousand fathers, but defeat is an orphan." In the early 2000's, I sometimes felt we were orphans, whereas today our work has many fathers.

As noted in the logo iconography above, Intel as a company has been around longer than I've been alive, so I am honored to have been given the opportunity to play a small role in the broad, exciting endeavor of riding Moore's Law and adding computation capabilities to the daily lives of so many around the world. 

And in the long tradition of Intel and open, programmable platforms, working with the Galileo board above reminds me of my first Intel platform, an Intel SDK-85 https://archive.org/details/bitsavers_intel80859nualJul77_5544585 (and with that familiar drop-e on the cover) that my father gave me back in those early days in Houston. This allowed me to experiment with coding and hardware interfacing, albeit in 8-bit assembly, viz.,

The ones on the web seem to have aged better than mine http://oldcomputers.net/intel-mcs-85.html. 

With that I should close this, my inaugural blog for 2014, tonight. Barring any life changes, the next blog should be "Anniversary Day.Next.Next," consistent w/ my February 24 postings of '12 and '13. 

Cheers