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

 A decade has passed since the posting https://vzimmer.blogspot.com/2014/01/advances-in-platform-firmware-beyond.html describing the journey of Tiano https://www.researchgate.net/publication/377810413_TechnologyIntel_Magazine_-_Advances_in_Platform_Firmware_Beyond_BIOS_and_Across_all_Intel_R_Silicon, which at the time was Intel Framework based specifications and the EDK implementation. As such, this month makes 20 years since the article landed on the internet.

The write-up was curiously available in several languages:

    English - https://github.com/vincentjzimmer/Documents/blob/master/it01043_eng.pdf

    Portuguese - https://github.com/vincentjzimmer/Documents/blob/master/it01043_pg.pdf

    Japanese - https://github.com/vincentjzimmer/Documents/blob/master/it01043_j.pdf

    Russian - https://github.com/vincentjzimmer/Documents/blob/master/it01043_ru.pdf

    Spanish - https://github.com/vincentjzimmer/Documents/blob/master/it01043_sp.pdf

    Chinese - https://github.com/vincentjzimmer/Documents/blob/master/it01043_cn.pdf 

Today the EDK https://sourceforge.net/projects/edkit/ has become https://github.com/tianocore/edk2 and the Framework https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html corpus is UEFI PI https://uefi.org/specs/PI/1.8/index.html. The OS-visible interface has gone from EFI 1.10 https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf to UEFI https://uefi.org/specs/UEFI/2.10/, too. 

Given the amount of change over this interval, I always have a tough time refreshing the graphic 

Many interesting twists and turns on this journey that started in the late 90's and still continues as we step into the year 2024.

Re-use - ideas, et al.

This is a quick note on 're-use'.  Recall how UEFI was derived from EFI, which in turn started as IBI, as mentioned in in http://vzimmer.blogspot.com/2018/10/ghosts-of.html and various histories of EFI in books http://vzimmer.blogspot.com/2021/01/books-and-computers.html and papers https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf. 

As a background, the original Intel Boot Initiative had its own filesystem called "IBIFS". It was a simple log-structured filesystem that made for easy parsing. But the challenge with this filesystem was how to provision boot media from other operating systems, such as Windows. In the 1990's MS-FAT was the prevailing filesystem although it was much more complex than IBIFS. The IBI/EFI team was encourage to adopt MS-FAT https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc, along with PE/COFF https://docs.microsoft.com/en-us/windows/win32/debug/pe-format executables, as the filesystem and executable format, respectively. This was supported by having a license to use these specifications for production of EFI firmware. 

The other advantage of using MS filesystem included MS providing tools to format, check and provision disks https://www.intel.com/content/www/us/en/download/714351/uefi-shell-disk-utilities.html whose sources were derived from MS Installable Filesystem (IFS) C++ kit provided to OEM's. This was my first dive into C++-on-a-C-framework (i.e., no global constructors, etc).

And PE/COFF allowed for using Visual Studio and commercial linkers. At the time we had less luck in getting PDB format and KD wire protocol made public. We wouldn't open source the EFI Debug support protocol and nub based upon reversing that infrastructure, of course. 

Of course using ANSI C with PE/COFF was more advantageous than using non-standard art like the coreboot romcc that proved brittle to maintain long-term, although it was a clever solution prior to the advent of cache-as-ram (CAR) https://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006.pdf. Prior to CAR we had to perform unnatural acts using MMX registers and other on-processor resources (with the peak weirdness of PEI CIS 0.3 and its register 'call levels') in order to implement pre-permanent memory flows like DRAM initialization in the host firmware. 

I was reminded of this logic of re-use based upon a few recent topics, including USF https://github.com/universalscalablefirmware and EDK2 GSoC conversation. On the USF topic, there is a discussion of using a self-describing format like CBOR https://www.rfc-editor.org/rfc/rfc8949.html in lieu of the UEFI HOB's https://universalscalablefirmware.groups.io/g/discussion/files/New%20data%20format%20for%20Universal%20Payload%20Interface.pdf. Even though I helped create HOB's, I am one of the first to support moving to a more standard format, especially given the existence of work like https://github.com/intel/tinycbor. To me this is the same spirit of using known filesystem formats, etc.

When asked about this I often cite the economics of host firmware development. Imagine a 5,000 person host firmware producing community across open source participants, OEM's, ODM's, firmware vendors, first party device creators, etc.  Recall the supply chain picture from erstwhile 2015 CanSecWest prezo

As such, compare this to the application and OS producing community that is easily orders of magnitude larger. Given the developer community size disparity it is difficult to justify the R&D and validation expense for bespoke host firmware-only solutions. Given NIH sometimes in engineering communities I also quote "Good artists invent, great artists steal" Picasso  https://medium.com/ben-shoemate/what-does-it-mean-good-artists-copy-great-artists-steal-ee8fd85317a0.

And given challenges of HOB's I understand the critique of Terse Executable (TE) during gsoc thread "[edk2-discuss] GSoC Proposala replacement for the TE format (it’s buggy and most platforms mostly abandoned it over various issues)," I'm not sure where he received his telemetry on 'abandoned' for working systems. Scraping FD images from the internet? Similar to some of the weird history on those GSoC threads like "PEI and DXE in 1998" when the latter were created in early 2000's as derivatives of EFI into the earlier boot flow. This TE assertion is close to home given the TE image format signature has 'vz' as opposed to PE/COFF 'mz', as originally described in https://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908

So has the TE image been relevant in the industry? Let's do some rough back-of-the-envelope calculations. To begin, the TE image format is easily over 20 years old. In the spirit of the last blog on statistics I'd sat we started to scale Framework EDKII in 2005

Imagine in the ensuing years it's tough to calculate the number of PC's, servers, and clients that shipped using UEFI PI-based firmware, including #'s like https://www.statista.com/statistics/576151/unit-shipments-pcs-united-states/. For Windows8 UEFI was required so you can argue 100% at that point. 

To take a swag lets assume 250 million units / year over the last 17 years, yielding 4.25 billion units. Let's also assume the fabrication of the PEI phase pre-memory uses TE's and that each fv/ibb/fvrecovery has ~ 50 peim's compiled with TE. So that would yield the market has shipped 50 * 4.25  =  212.5 billion TE images into the market. And if platform updated 5 times during life, 1 trillion TE's may have been produced. So even if we go 'Beyond TE', 1T has been a good run. And I look forward to the next wave of firmware technologists' proposals - the critique is a pre-condition to invention/innovation - but the next wave needs to close the loop by proposing, documenting, coding, delivering, validating, and scaling their alternative. 

I still recall meeting one of the original developers of MS-FAT in Windows at a driver dev-con in the early 2000's in Redmond. He mentioned that 'writing the code was only 10% of the effort.' The latter class of activities were the remaining 90% for a professional software engineer. Or the old trope 'the last 10% of a project takes 90% of the time.'

Finally, these cardinality of the produced TE image set calculations remind me of a colleague at Cornell during my undergrad. He worked part-time in the astrophysics department, whereas I spent time modeling and mocking up particle beams for a professor who did microwave and plasma research as part of SDI https://en.wikipedia.org/wiki/Strategic_Defense_Initiative. My friend noted that the astrophysics researchers there would reckon calculations plus or minus a couple orders of magnitude. I won't argue host firmware is of the same scale but it does note the challenges in precision in various domains.

Sometimes folks believe in bespoke and not studying the past arc of history in tech. I recommend spending some time on bitsavers.org, for example, to folks. But it reminds me of the advice given to me by a retired manager - "Sometimes you see someone put their hand in the chipper. You can say 'there's a chipper, there's a chipper', but they ignore you. Once they are beyond their elbow you need to jump in, at least." Or the dual of child rearing, which was "Sometimes the young child needs to bump her knees on the coffee table while learning to walk."  For those not in the PNW a chipper is https://www.familyhandyman.com/list/best-wood-chippers/.

BTW
I just sampled some of the OCP Security https://www.opencompute.org/wiki/Security tech talks. Work to avoid e-waste such as ownership transfer https://docs.google.com/document/d/1oANhjvv_R7E5n8w1RroN8l8-0jdYlfdQDp_3RqGV66k/edit# for servers presented by Google datacenter engineer nicely complements their work on Chromebooks with their developer mode https://www.chromium.org/chromium-os/chromiumos-design-docs/developer-mode/ and other art to allow for unsupported devices to be over-flashed by community firmware for continued life & usage. Nice to see work to avoid aged hardware from only have a fate of visiting the refuse bin/salvage yard.

It might be a stretch to analogize re-use of ideas in this blog post and re-use of hardware in the circular economy from this OCP talk. The former stands on the shoulders of giants and leverages information ecosystems (knowledge, tools, remediated flaws) whereas the latter leverages extant hardware for appropriate use-cases. But interesting stuff nevertheless.

fin (98)

musings about firmware cultures

In a quick journey around firmware cultures in this posting, I'll talk a bit about the recent Open Source Firmware Conference (OSFC) 2020.

The Open Source Firmware Conference (OSFC) started in 2018. It was a broadening of the coreboot conference to include other open source firmware projects. Some examples of the earlier coreboot conference include the 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016 where Intel talked about the ‘then recent’ UEFI Payload project https://youtu.be/I08NHJLu6Us and Intel FSP 2.0 https://youtu.be/uzfiTiP9dEM. I was invited to give the keynote of the inaugural OSFC conference in 2018 https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf  There common themes such as chipsec, Slim Bootloader, Min Platform, coreboot, and Intel FSP were noted.

 

Now have FSP SDK   https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 mentioned in that keynote, too.

Fast forward to OSFC 2020 https://cfp.osfc.io/osfc2020/schedule/ and you see many of the same sentiments being reiterated. Intel talked about extending Intel FSP for programmable service engine support https://cfp.osfc.io/osfc2020/talk/TNTFYV/, a more modern configuration mechanism https://cfp.osfc.io/osfc2020/talk/AS7EZR/, and the efforts https://cfp.osfc.io/osfc2020/talk/VUNDSC/ to have a more reusable payload  https://github.com/universalpayload. From those talks we then go to the efforts to remove dependencies upon SMM, including the Platform Resource Monitor (PRM) https://cfp.osfc.io/osfc2020/talk/MCJASB/. 

Beyond those talks, Jiewen Yao co-presented on the Security Protocol and Data Model (SPDM) https://cfp.osfc.io/osfc2020/talk/ECQ88N/ along with Xiaoyu Ruan. SPDM is a new standard from the DMTF for device and host firmware security that is critical for upcoming security initiative support. openspdm is a sample implementation of SPDM specification. It will be used in multiple device and host firmware implementations including UEFI EDK II and possibly other platform firmware, such as a Baseboard Management Controller (BMC) based upon OpenBmc, etc.

Beyond SPDM, Jiewen also shared the background and efforts with Virtual Firmware for Intel Trust Domain Extensions (TDX) https://cfp.osfc.io/osfc2020/talk/CRKZB8/. This effort entails open source efforts to help scale enabling for TDX and provides a venue to discuss aligning enabling with other confidential computing efforts like AMD Secure Encrypted Virtualization (SEV). The TdShim is also used as a foundation for any service Trust Domain (TD) for TDX advanced feature in an EFI-light environment, such as the virtual firmware for a container or virtual TPM services. It bridges the gap between TD startup and applications running, and it enables the customers building their own use cases on top Intel TDX.

Andy Jassy during re:invent this year also spoke about how change in large companies is often driven by outsiders since long-time employees are often reluctant to replace what they've built in the past. And in the spirit of change, Rust was a topic of a few https://osfc.io/ talks this year, including the virtual hallway track discussion.

Specifically Jiewen Yao and I presented on Enabling Rust in UEFI firmware https://cfp.osfc.io/osfc2020/talk/SLFJTN/. This is a complementary talk to those by Google on enabling Rust in oreboot https://cfp.osfc.io/osfc2020/talk/SLFJTN/ and Rome https://cfp.osfc.io/osfc2020/talk/TBSHA8/, respectively. Although these are early days, there is definitely a groundswell of interest to evolve how critical infrastructure code such as firmware is written, especially given the needs for more robust code and efficiency of the developer workflow. And as an example of that sentiment, since OSFC is a virtual conference, the closest thing to the ‘hallway track’ was commentary in the sharing tool, including the following exchange on Rust

  

Open Source Firmware Conference 2020

Bret Barkelew6 hours ago

I agree with Ron that now I've worked with Rust it's like pulling teeth when I have to go back. ;)

.

J. Redpath5 hours ago

a sign of something good

.

Vincent Zimmer5 hours ago

yes. moving from C to Rust feels like the same dynamic of moving from assembly-based firmware to C 20 years ago.

.

Diego Rodríguez5 hours ago

^this

In addition to that hallway track discussion above, there were other hallway discussions in the Facebook session about UEFI versus coreboot complexity.This reminded me of the culture of UEFI and coreboot, or as I sometimes think, a "windows-bios" versus a "linuxbios." By that I mean the EDK code is written in the style of Windows kernel code and coreboot is written in the style of Linux kernel code.

To begin, coreboot literally started as "LinuxBIOS", as mentioned in chapter 4 of https://www.amazon.com/gp/product/B01JC1LDTY/. EDKII history is described in the "Beyond BIOS" article https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.  

The reality of the latter is that Ken Reneris, mentioned in http://vzimmer.blogspot.com/2018/10/ghosts-of.html, created the original IBI/EFI core. He was a OS/2 and Windows kernel/Hal veteran who joined Intel in '98 around the time of the initial IBI effort. Ken brought along the same Camel Case coding style as Windows kernel code, the Containing Record (CR) https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/8_private_context_data_structures/81_containing_record_macro macro from ntddk.h into efi.h, TPL's from Windows IRQL's, .inf's, and the build command-driven build of the original EFI sample which became the EFI Developer Kit's I and II. CR's are pretty interesting in that it allows for a 'public' interface in a structure to have some appended, implementation-specific instance 'private' information. This allows for C++ keyword functionality for public/private to be emulated in C code.

Speaking of the legacy of ex-MS Ken, the prevalent use of GUID's in EFI, along with the 'protocols', or GUID-named API's, bear not a small resemblance to COM https://en.wikipedia.org/wiki/Component_Object_Model. Think iUnknown versus HandleProtocol, etc. but forging COM's C++ infrastructure in C.

Ron, on the other hand, notes that the original LinuxBIOS was derived from Linux, thus it has stutter-case/Indian Hill https://www2.cs.arizona.edu/~mccann/cstyle.html coding standard, basic make support, and Kconfig as LinuxBIOS became coreboot. coreboot also started out as fully-open, whereas EDKII slowly released more sources of the last 20 years.

Beyond coding standards, the EDK-based implementations of UEFI always vied to cover the entire boot flow, from the tuple of {reset, silicon init, platform init, OS bootload phase} as {SEC, PEI, early DXE, late DXE}. DXE is both platform initialization and the UEFI core. coreboot, on the other hand, supports the same tuple as {bootblock, romstage, ramstage, payload}. The payload for coreboot could always have been a full kernel, as CSM-like compatibility module like Seabios, or today even a EDKII-Dxe implementation in the core of the UefiPayloadPkg. 

The richness of the OS bootload phase in coreboot is separated from the basic silicon and board initialization. With the DXE phase doing both platform initialization and OS bootload, the complexity of the latter ends up encroached on the former. The OS bootload code is highly reused and rich, per the UEFI specification, whereas board initialization is a high traffic area where board specific changes often occur and is the venue to host a lot of the bring-up and debug experiences.

Popping up from my trip down memory lane, OSFC also had debates between MS and others on the chat channel about the distinction between the general purpose platform where the OS producer may be different from the platform producer, versus a more vertical platform with the firmware and OS provisioned under the same authority.

Or the distinction between a full feature platform that supports a plurality of shrinkwrap OS's versus doing the minimum and letting the OS do the rest.

Another big distinction between the two is that EDK grew up initially closed and any of the open elements were released under a permissive BSD license. whereas coreboot grew up open with the GPL license. I was curious about the value of the GPL in firmware and received the following comment from Marc Jones many years ago  via the question 'why hoard SATA bug fixes?' EDK BSD allows for snapping the open source instance and not redistributing changes, such as bug fixes, whereas the GPL of coreboot, Linux, and u-boot obligate the party changing the GPL code to redistribute their fixes.

Luckily, there are more than a few common points of alignment between EDKII and coreboot today.  These include EDKII-based UEFI Payload Package for shrinkwrap OS support, both communities are pursuing unit tests w/ cmocka, ACPI is the predominate runtime interface, etc.

From those present-day alignments there are also some similar trends, such as the oreboot from C-based coreboot and the RUST-on-edkII investigation versus full EDKII C code

Speaking of EDKII implementations, in addition to the PDF of some of the OSFC talks, the videos of talks for OSFC 2020 can be found at https://vimeo.com/showcase/osfc-2020.

Beyond the OSFC talks, one can find the recently-published "Understanding the Trusted Boot Chain Implementation" at the following links  https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/, https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.pdf, https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.mobi, and https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.epub. These binaries are compiled from https://github.com/tianocore-docs/edk2-TrustedBootChain. This material is above-and-beyond the recent book https://www.amazon.com/Building-Secure-Firmware-Armoring-Foundation-dp-1484261054/dp/1484261054/ and was created in order to provide guidance to communities, such as the Trusted Computing Group and TianoCore, on consuming and producing the measurements in a more interoperable fashion.

I also just noticed another security related EDKII publication, namely an insightful analysis of PE/COFF image loading https://arxiv.org/pdf/2012.05471.pdf.  This is close to home for UEFI and EDKII. The work reminds me of the more generic studies like https://eprint.iacr.org/2019/564.pdf.As you may have guessed from my earlier blogs and writings, I'm a fan of more formality and rigor in the pursuit of future-looking designs and validation, respectively.

Tiano, '147, and 22 or Anniversary.Next^7

This covers my 7th blog aligned with my work anniversary, a successor to http://vzimmer.blogspot.com/2018/03/open-platforms-and-21-or.html.  I'm now passing the 22 year milestone.

I try to land this blog posting on the anniversary day. Luckily this year I received an email reminding me that I'm already one year into my 3 year sabbatical eligibility. As far as topics go, replying to Juan's https://twitter.com/juanrodpfft/status/1099896998704996352 brought up a couple of milestones in time, namely Intel Achievement Awards (IAA's).  Some background on the IAA can be found at https://blogs.intel.com/jobs/2012/05/why-the-intel-achievement-awards-ceremony-was-amazing/#gs.13ww1ppY.

My first of 2 IAA's was delivered in 2004 and read on the Tiano architecture.

Tiano is the code name of what became the Intel Framework Specifications and the EFI Developer Kit (EDK), which has since evolved into the EDKII project and the UEFI Platform Initialization (PI) specifications. Even though this was about 15 years ago, progress in this space is continuing apace, including the open platform work. The last decade and a half was laying the foundations of the host firmware, and the next will be scaling how it's delivered.

To that end, the open Kaby Lake (KBL) platform has a newly added system, namely the Clevo board
https://github.com/tianocore/edk2-platforms/tree/devel-MinPlatform/Platform/Intel/ClevoOpenBoardPkg for System76 KBL laptops. This builds upon the infrastructure detailed in https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf.

So this means that I'm still building upon the project recognized by the first IAA, but what about the second one? The award from 2012 was on deploying signed updates across Intel and the industry, building upon the NIST 800-147 standards effort https://csrc.nist.gov/publications/detail/sp/800-147/final.

In the last 7 years work continues in this space and follows a similar arc, namely standards and scaling an implementation. A scaling of implementations of signed updates can be found in work like https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf and additional standards, such as https://csrc.nist.gov/publications/detail/sp/800-193/final for resiliency. The latter is important because one of the challenges of deploying '147 style updates includes fear of a machine become bricked, or not successfully completing the update.

Awards are an interesting thing. One school of thought is that an award should only be delivered after an idea is delivered to market for several generations, thus ensuring that the originator of the idea carries the ball to the goal line. Without this tracking you end up with possible technologist patterns like a 'pump and dump', namely evangelize an idea and achieve rewards, but move on to the 'next big thing' prior to enabling and scaling the concept, or 'dumping it' on others prior to delivering market success. At the same time, though, technology is often a funnel that starts small with a few pioneering parties at the beginning, or mouth of the funnel, and telescopes to much larger sets of contributors by the time it appears in the market. So if you wait until the end, it's harder to reward smaller classes.

A colleague once suggested a potential solution to this 'pump and dump' risk for senior technologists, namely extend their review cycle from twelve months to a couple of years. The logic being that the annual review cycles encourages 'pump' periodicity of 12 months in order to optimize the remuneration calculus of annual reviews.

I personally don't know if there's a magic bullet other than the have a culture of each individual having the 'business first' mindset of one of the below quotations. Also, perhaps you can get away with a random 'pump and dump', but your personal brand and reputation will ultimately suffer for this type of behavior. The industry is relatively small, and 'trust is earned in droplets but lost in buckets.' A dump or two can lead to spilling that bucket.

Speaking of quotations and beyond those couple of awards milestones, a few other items came to mind during this anniversary posting. These include memory quotes from mostly-former colleagues, such as DM's "If anyone knew true cost of a project, nothing would be funded" or BP's "It has always been this bad.  you are just now higher up in the organization to see more." From there we have more valuable life and career advice, such as "Never lie, but don't tell all of the truth" or GC's "Two sisters never got along with - 'Polly' and her sister 'Ticks.'" Another one that helped me empathize with the machine was RH's "Moving higher in management ranks means making successively more impactful decisions with diminishing amounts of information."

In addition to the quotations I can source, the next ones are ones I find myself dispensing that I cannot recall if they originated from a party inside or outside, including "Prioritize your work with business first, team second, career third, "Be kind to people because you don't know what crisis they have going on personally," and finally "Your career is like archery of Zen - the harder you focus on the target of just 'success' the more difficult it will be to achieve."

OK. Awards and quotations. That's enough for noting the passing of 264 months.

"So Long, and Thanks for All the Fish"

Yesterday my last day in DuPont after nearly 18 years, 15 of those in the same cube, here at this WA Intel site. Off to work at the Seattle office in early '15. So long, DuPont, and thanks for the memories. And all of the Fish, although in this case 'Andrew Fish.' Although Fish doesn't work at Intel any longer, the inventor of the "Intel Boot Initiative" (IBI), which became EFI/UEFI, still lives in the South Puget Sound. We broke bread for the final time at our favorite local restaurant.

This is the "R&R" mentioned in the acknowledgements section of the 2nd edition of Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, "Also many of this team will recall over ten years of "design discussions" at R&R." I captured Fish on the left and Mark Doran http://newsroom.intel.com/community/intel_newsroom/bios?n=Mark%20S.%20Doran&f=searchAll on the right eating our final Teriyaki bowls. As always, good conversations on firmware and technology. And the picture is also epic in that the duo often introduces itself as "Andrew Fish who invented EFI, and Mark Doran who delivered it to the industry."  Mike Kinney & I held down the other side of the table. I've learned quite a bit working with all three of these colleagues over these many years.

During my final days at Compaq in late 1996 I talked to Intel about joining, and my options were "Join Portland for Xeon, or DuPont for Merced." I was inspired by the thought of joining the 64-bit revolution, so there was no doubt in my mind as to which locale to choose.  Also, having grown up in Texas, the Pacific Northwest was a large unknown, so the distinction between OR and WA didn't even factor into my decision.

And my whole tenure at Intel in DuPont since February 1997 has been boot firmware.  I began with a PC/AT BIOS underneath the Merced System Abstraction Layer (SAL), with the original OS loader interface of SAL_PROC (0x13), as a 64-bit mapping of BIOS 13h.  Same for video mapping of SAL_PROC (0x10), keyboard of SAL_PROC (0x13), etc. The OS community wasn't amused.

As the OS interface evolved to C-based IBI, then EFI, the underlying boot infrastructure changed. I moved from driving some of the SAL-on-BIOS for server (aka "FrankenBIOS"), to the short-lived Workstation Product Division (WPD) where we evolved a C-based boot solution. The latter pioneered art such as the Furball and interposer, which were the predecessor of the Intel Framework Compatibility Support Module (CSM) and CSM16 binary.  We called the former 'furball' because it was something we imagined a native 32-bit (IA32) and 64-bit (Itanium) firmware solution would eventually 'cough up', with a less than pleasant imagery derived from the world of cats.

In 1999 we had evolved the workstation firmware to binary modules called "Plug-In Modules", or PIM's. I recall a fateful meeting with the lead on that effort and my colleague visiting from OR. The conversation went something like 'And we can also put the PIM's into option ROMs, too.' At that point I realized the trajectory was ill-fated since the problem with open platforms and option ROM's isn't factoring code to run in that storage container so much as 'how' to interoperate with the system firmware, namely what API's to expose, where to define them, and how to evolve this art. And to that end, I realized that EFI would win as it was the only man standing to solve this problem.

Specifically, EFI nailed down the interface methodology to the OS loader and option ROM community where the broad interoperability was needed.  Moving the underlying initialization firmware to a new methodology, such as what became Intel Framework and then UEFI PI was valuable, but not the necessary first step.  The first step was to lay the foundation for broad interop in order to have time for the top-level OS and IHV ecosystem to start moving their dependent infrastructure.

At that point in my career when I had that realization, I was lucky enough to have a friend and Intel colleague like Andrew Fish who suggested I have lunch with Mark Doran.  Afterward I on-boarded to the EFI team in 1999 and the rest has been a great 15 run on helping evolve EFI into UEFI, EFI-on-BIOS into Framework and then UEFI PI, and the open source offering from "EFI Sample" to EDK to today's EDK II.  Since then a lot of code and specifications have ensued

with hopefully more to come in 2015+.  Not sure if there is another 15 years into the run.  Although one co-developer of Tiano, the code-name for the underlying Framework (and now PI work) quipped a few years ago "We said Tiano was the '20 year' BIOS replacement solution, so when did you start counting?"

Speaking of 2015+, I had better get back to work if I want to get a head start on the next way of the firmware revolution started in South Puget Sound, WA.

Cheers