Open source platforms, FSP consumers, FSP producers, and STM updates

Overview
You've seen in the past when I have talked about Intel Firmware Support Package (FSP), hearkening back to 2014 [1][2]. There are 2 parts to FSP - the Consumer or use of the FSP in a platform, and the production or creation of an FSP binary.  We'll review examples of each in turn below, in addition to some updates since the 2015 IDF prezo.

By the way, some of these items were also posted to [22] but the latest posting seems to have disappeared.  As such, if you've already read some of this from that site, feel free to skip over the duplicate material.

FSP Consumer
We're posting an updated platform using the 1.1 FSP [3][4]. This tree moves beyond the Baytrail work in [2] and includes Braswell [5]. A good overview of porting the tree is provided, too [6]. This shows some of the best practices on building EDKII on top of FSP. Specifically, the only macrocode binary is in the Intel FSP, with the rest of the EDKII code to provide the core UEFI & PI services, along with the platform initialization, in open source.

This is an important step to show how FSP + open source can be used to build a full solution, or EDKII can'Consume' an FSP binary. This provides parallel work-flows to things like a coreboot Braswell solution [13], for example, that also builds upon Intel FSP. Turing equivalence argues that it is all 'just code', so we want to show a few 'equivalences' here.

This is a work in progress that should eventually migrate to [11], but in the interim take a look and provide feedback on some of the code partitioning and design.

Speaking of coreboot, EDKII and FSP, my colleague Lee Leahy [23] and I are slated to talk at the upcoming coreboot conference [24]. We'll review the EDKII CorebootPayloadPkg [26] at [25].

FSP Producer
In addition to the Intel Atom based platform that consumes an Intel FSP binary from [12], there has been a lack of public demonstration of producing an Intel FSP, as described in [2]. This is by design in the sense that the Intel FSP encapsulates matter that does not have public documentation, thus cannot be open sourced. This poses the challenge of how to provide guidance on how to create an Intel FSP. This is where the Intel Quark EDKII code comes into play. Since the low-level silicon initialization, including memory initialization, is already open source, the project providesan opportunity to show how to create an Intel FSP [7]. Luckily we now have an early example of this in public view [8].
I look forward to future platforms that move beyond FSP 1.1, too [10]. And to that end, the FSP 2.0 specification is now live [27], along with the Boot Setting File (BSF) specification [28] that has been used in all of FSP 1.0, 1.1, and now 2.0.

Good stuff.

STM
Speaking of good stuff, here are some updates following last year's IDF prezo [19], including the SMI Transfer Monitor (STM) mentioned at [14]. Specifically, you can now find the STM source code on a public repository [15]. In addition to the documents on the STM itself [21] and the original STM [20], there is also another virtualization technology shared in the repo that wasn't in [20] release, namely the DMA protection work described in [16] which can be found at [17]. This complements the host-based protection of the FRM [18] with some protection from I/O devices performing errant DMA transactions.

Conclusion
You'll hopefully observe a theme here of having more open source platform solutions, including protection technology. This is one way to engage with the community and reduce the barriers to providing robust, transparent platform solutions.

References
[1] Zimmer, "EDKII, FSP, and other topics", blog posting, September, 2014
https://firmware.intel.com/blog/edkii-fsp-and-other-topics

[2] Zimmer, "Firmware Flexibility using Intel(R) Firmware Support Package," Intel Developer Forum,
September 2014
https://firmware.intel.com/sites/default/files/SF14_STTS001_Intel%28R%29_FSP.pdf

[3] Yao, et al, "A Tour Beyond BIOS Using the Intel(R) Firmware Support Package 1.1 with the EFI Developer Kit II," April 2015
https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf

[4] Intel Firmware Support Specification External Architecture Specification (EAS), Version 1.1a, November 2015
http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1a.pdf

[5] Braswell EDKII project, April 2016
https://github.com/mangguo321/Braswell

[6] Wei, et al, "Open Braswell UEFI Codebase - Design and Porting Guide," February 2016
https://github.com/mangguo321/Braswell/blob/master/Documents/Open_Braswell_Platform_Designing_Porting_Guide.pdf

[7] Yao, et al, "A Tour Beyond BIOS Creating the Intel(R) Firmware Support Package 1.1 with the EFI
Developer Kit II, April 2015
https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf

[8] Quark FSP 1.1, April 2016
https://github.com/feizwang/quarkfsp

[9] Quark SOC code
https://github.com/tianocore/edk2/tree/master/QuarkSocPkg

[10] Intel FSP2.0 consumer code, March 2016
https://github.com/jyao1/FSP2.0

[11] EDKII project www.tianocore.org

[12] Intel Firmware Support Package (FSP)
intel.com/fsp

[13] coreboot Braswell code that consumes Intel FSP 1.1, April 2016
https://github.com/coreboot/coreboot/tree/master/src/soc/intel/braswell

[14] SMI Transfer Monitor (STM) overview, August 2015
https://firmware.intel.com/blog/stm-updates
http://vzimmer.blogspot.com/2015/08/smi-transfer-monitor-stm-unleashed.html

[15] STM Source code, March 2016
https://github.com/jyao1/STM

[16] Yao, Zimmer, "A Tour Beyond BIOS Using Intel(R) VT-d for DMA Protection in a UEFI BIOS," January 2015, https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_Intel_VT-d_for_DMA_Protection.pdf

[17] DMA Package https://github.com/vincentjzimmer/STM/tree/master/Test/DmaPkg

[18] Yao, Zimmer, "A Tour Beyond BIOS Launching a VMM in EFI Developer Kit II," September 2015, https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_VMM_in_EFI_Developer_Kit_II_0.pdf

[19] Zimmer, "STTS003 - Developing Best-in-Class Security Principles with Open Source Firmware", Intel Developer Forum (IDF), San Francisco, August 2015
https://firmware.intel.com/sites/default/files/STTS003%20-%20SF15_STTS003_100f.pdf

[20] STM 1.0 August 2015
https://firmware.intel.com/sites/default/files/STM_Release_1.0.zip

[21] Yao, Zimmer, "A Tour Beyond BIOS Launching STM to Monitor SMM in EDK II", August 2015 https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_STM_to_Monitor_SMM_in_EFI_Developer_Kit_II.pdf

[22] https://firmware.intel.com/blog

[23] coreboot Quark FSP MemoryInit support, January 2016 https://www.coreboot.org/pipermail/coreboot-gerrit/2016-January/039748.html

[24] coreboot convention 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016
https://calendar.google.com/calendar/embed?src=6b1u8iq13jj8cp6kfokq4vlo20%40group.calendar.google.com&ct=America/Los_Angeles&dates=20160612/20160616&mode=agenda

[25] EDKII CorebootPayloadPkg overview, June 14, 2016 https://calendar.google.com/calendar/embed?src=6b1u8iq13jj8cp6kfokq4vlo20%40group.calendar.google.com&ct=America/Los_Angeles&dates=20160612/20160616&mode=agenda

[26] https://github.com/tianocore/edk2/tree/master/CorebootPayloadPkg

[27] Intel Firmware Support Package (FSP) 2.0 Specification, April 2016
https://firmware.intel.com/sites/default/files/FSP_EAS_v2.0_Draft%20External.pdf

[28] Boot Setting File (BSF) Specification version 1.0, March 2016
https://firmware.intel.com/sites/default/files/BSF_1_0.pdf 

Post-Intel Developer Forum 2014

I would like to thank Tim Lewis for mentioning this blog at http://uefi.blogspot.com/2014/09/new-bios-related-blogs.html. I have dual-posted this item to https://uefidk.com/blog/edkii-fsp-and-other-topics, too, as an experiment. The later community has some interesting code projects and write-up's I reference below.

I spent a few days last week in San Francisco at the Intel Developer Forum (IDF).  My hotel was right off Union Square, thus allowing me to witness of cross-section of San Francisco each morning.

All of the sessions were at the Moscone Convention Center.

My presentation at https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1265 now has the material posted https://intel.activeevents.com/sf14/connect/fileDownload/session/08F28DCA2DB2EA88418F93B309D82DE4/SF14_STTS001_102f.pdf.

The audio variant of the material should be posted in a couple of weeks. My talk immediately preceded and also mentioned the session of UBMS https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1266 led by Brian Richardson and Mark Doran.

As always, the most exciting part of the event entailed discussion with customers and collaborators both within and outside of Intel. My session was at 9:30am on Thursday and I took a short trip down memory lane, remarking on the two presentations I made in 2003, the first of which entailed how to build out platforms using the Intel (R) Framework specifications http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html along with Bob Hart from Insyde and Mike Kinney from Intel, which became the foundation for chapter 7 of the Beyond BIOS books http://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908 and http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295.

My talk picked up off Brian and Mark's talk from last year https://intel.activeevents.com/sf13/connect/fileDownload/session/DB60155205A8DF5837DA22D0FF90E3A3/SF13_STTS001_100.pdf and built out the progress during the intervening twelve months. I was happy to have Giri Mudusuru and Jiewen Yao from the PC Client Group (PCCG) and my Software and Services Group (SSG) help with questions and answers at the end, too, in addition to serving as co-authors on some of the white papers mentioned later in this blog.

Beyond the FSP-on-EDK2, which is a hybrid of source plus binary, the session also treated on alternate enabling models, including pure open source. Since the session only ran for one hour, with 50 minutes of presentation and 10 minutes of Q&A, we wanted to provide both the attendees and the broader ecosystem an opportunity to 'go deeper' on the subjects treated. As such, beyond the above-listed presentation material, we also note some addition material on slide 27.

The two papers we posted ahead of the talk includes the FSP-on-EDK2 aspect in http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_0.pdf for the initial portion of the third agenda item, and http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_the_TinyQuark_Design.pdf for the second portion of fourth agenda item, respectively. The idea behind the white papers is to 'add words between the Power Point pictures', or elaborate on some of the design intent behind these two engineering efforts.

Another reveal at the talk is the upcoming book from Apress Embedded Firmware Solutions. The alpha posted online http://www.apress.com/9781484200711 already treats the coreboot plus FSP topic, with the final book due early next year. Again, this type of material production aligns with the intent of providing more behind-the-scenes detail and intent of these efforts. Presentations are great to set the tone and direction, and open source repositories must exist in the 'reduction to practice' phase, but having the written word in between the evangelism and the bits helps close the loop for the development community, in my opinion.

Some of the material left of the cutting room floor, in the interest both of time and scope of the presentation, included the recent UEFI payload for coreboot built with EDKII http://www.uefidk.com/develop#accordions_develop-page-9. This was going to follow foil 16 of the presentation were the concept of a 'payload' is introduced, but the inclusion seemed to veer astray of the EDKII/coreboot + FSP tenor of this section.

Here are a couple of the redacted foils that show the flexibility of these open source firmware communities, EDKII, FSP, and coreboot.

and

In the first diagram above you can see that the payload is composed of modules out of EDKII built into a firmware volume. This is the spatial view. We didn't want to mix GPL-based coreboot and EDKII sources, so the only import from the coreboot community was the coreboot memory declarations, or CBMEM, which were also defined in coreboot's libpayload, a BSD-friendly licensed set of sources. The second diagram above shows the flow of the UEFI payload with the coreboot platform 

The ultimate theme of the presentation, though, was to offer customers choice. The imagery used to reinforce this point included the quotation "All Roads Lead to Rome" http://en.wiktionary.org/wiki/all_roads_lead_to_Rome with 'Rome' in this case representing the customer using Intel(R) products and the 'Roads' describing the various enabling options.

Beyond IDF and its technical sessions, though, there was a rare Sergey Brin sighting http://www.theverge.com/2014/9/10/6133589/this-photo-of-sergey-brin-doing-yoga-at-IDF-is-not-strange, although my picture is a bit blurrier

And IDF also featured live music Weds night, namely Weezer http://www.weezer.com/

which was pretty interesting.

While at IDF I also had a chance to work directly with Jiewen, and overseas colleague. We typically interact over email or phone given his home site in the Shanghai, PRC, area and mine in the Seattle, WA, US area. One of the common questions we receive about UEFI Secure Boot UEFI Secure Boot entails Authenticated Variables. This was a topic treated lightly in the implementation document, so Jiewen and I created http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf to specifically address the SMM-protected variant of this driver posted on http://www.tianocore.og.

On any of these presentations, white papers, and even this blog posting, I look forward to community feedback.

2/15/2015 update - the book cited at the end of the IDF presentation is now for sale http://www.apress.com/9781484200711

Trends and openness

The balmy days of summer have made me reflect upon the past. And colleagues leaving of late make me more thoughtful. This is sort of a twist on the earlier career development talk, but with advice on how to pivot and react to the world. Of course the discourse includes a long-winded blog format that also treats on various aspects of life in tech and the human condition.

To begin, I work at a remote site (aka 'Siberia' of West Coast), so a long period of time can pass between seeing most colleagues. Even in the age of video conferencing, few parties use that class of tool, and I keep my camera covered with a yellow sticky note for other reasons.... In fact, I can work with some colleagues for years and only communicate on the phone or e-mail. When I finally do meet one of those long-distance collaborators in person, I often want to blurt out "you sounded much taller/shorter/fatter/older.... on the phone." But there really isn't an appropriate response. At one point I had mistakenly thought a collaborator was the Office Space stapler guy while remotely collaborating, and when we did finally meet, I sat stunned for the first ten minutes when I realized that I had mistaken this gentleman for an erstwhile cryptographer. The stapler guy image and the tan, fit person sitting across from me in the conference room didn't quite align.

On the other side of the coin, I do see certain people aperiodically over the course of the years, say at internal conferences or face-to-face mission meetings. In the early days of my tenure we would beat our chests and opine about all-night coding sessions, weight lifting, and other antics of youth, all with shiny, fresh cherubic faces.

Fast forward 10-15 years, and I note the weariness on faces w/ lines reflecting hours of ennui in meetings, bodies thicker around the middle from those days of eating lunch while on con-calls + fast-food while working late + more meetings + poor eyesight from poring over code and docs....  There is an occasional spark in an eye recounting the past, but mostly there are discussions that entail children and who is promoted or working at company XYZ.

But the advantage of wisdom includes having a network of collaborators and a more senior role to effect change. And that position is important, because the one thing that is constant over this span of time is change, especially in the technology industry. And when it comes to disruptive trends and change in our industry, I like to think of these trends as the four horseman of the apocalypse. When a disruptive trend is afoot, you can be in one of the three places: in front of the trend (and get trampled), behind the horses (and do clean-up duty), or riding one of the horses. Given my simplified view of things, you can imagine my predilection, namely riding one of the horses and being that agent of change.

As part of riding that course and driving change, one of the trends I observe has been the movement to open ecosystems, open source, including the move from PC/AT style BIOS to firmware environments like UEFI and its edk2 based development on tianocore.org. The salient portion of system software work, whether operating systems like Linux or edk2, includes openness and ecosystems. That's where open source can help.  Marc Andreesen rightly noted that software is eating the world http://online.wsj.com/news/articles/SB10001424053111903480904576512250915629460, and now open source software is eating software http://readwrite.com/2013/12/12/open-source-innovation#awesm=~oIwdZdqu0YdTo8.

This tend of open source source helps inform innovation paths, too.  Whether the discussion includes the minimal features to exemplify a capability, such as a micro-hypervisor using hardware virtualization https://github.com/udosteinberg/NOVA, or showing how a full UEFI edk2 implementation on Quark (1MByte image) can scale down to a 64-kbyte solution with "TinyQuark" http://firmware.intel.com/sites/default/files/Intel_Galileo_TinyQuark_64K.zip for https://firmware.intel.com/projects/get-started-intel-galileo-development-board. Why zips for the latter and not checked into an upstream open source IA firmware ecosystem? That's a discussion for another day. These small examples prove an innovation direction ahead of broad product execution that may embrace some of the design precepts demonstrated therein.

Another example of openness and innovation is network boot. Recall my description of IPV6 network booting at http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html. I'm a big fan of pre-OS networking https://www.researchgate.net/publication/258834396_A_Quick_History_of_UEFI_Networking and I chair that subteam, along with security, in the UEFI forum.

Since that discussion the options at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml have been expanded by my friend at HP Samer El-Haj-Mahmoud http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf. The essence of these new options is to allow the UEFI machine to express that it has the ability to boot using a TCP-based, or connection-oriented protocol like HTTP, versus today's TFTP-based PXE wire protocol. This allows for more robust and scalable deployments without the need for retries and timeouts that afflict the UDP-based TFTP deployments.

Processor Architecture Types

Registration Procedure(s)

Expert Review

Expert(s)

Vincent Zimmer

Reference

[RFC5970]

Available Formats

CSV

Type	Architecture Name	Reference
0x00 0x00	x86 BIOS	[RFC5970][RFC4578]
0x00 0x01	NEC/PC98 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x02	Itanium	[RFC5970][RFC4578]
0x00 0x03	DEC Alpha (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x04	Arc x86 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x05	Intel Lean Client (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x06	x86 UEFI	[RFC5970][RFC4578]
0x00 0x07	x64 UEFI	[RFC5970][RFC4578]
0x00 0x08	EFI Xscale (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x09	EBC	[RFC5970][RFC4578]
0x00 0x0a	ARM 32-bit UEFI	[RFC5970]
0x00 0x0b	ARM 64-bit UEFI	[RFC5970]
0x00 0x0c	PowerPC Open Firmware	[Thomas_Huth]
0x00 0x0d	PowerPC ePAPR	[Thomas_Huth]
0x00 0x0e	POWER OPAL v3	[Jeremy_Kerr]
0x00 0x0f	x86 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x10	x64 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x11	ebc boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x12	arm 32 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x13	arm 64 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x14	pc/at bios boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x15-0xff 0xff	Unassigned

These tags as part of the wire protocol for DHCP, along with the URI device path node from the UEFI 2.4 specification, errata B, allow for negotiating this download and informing the network boot program from where it was loaded, respectively. Good stuff. And I look forward to booting UEFI on the Skynet.

Openness and ecosystems also allow for bringing people along in the journey. I was shocked and pleased when one of my overseas colleagues mentioned how to escape from the 'Cathedral', namely a reference to Eric Raymond's book http://www.catb.org/esr/writings/cathedral-bazaar/ on the same. The meme infects technologists regardless of experience or culture, as exemplified by our Friedman'esque Flat World http://www.amazon.com/The-World-Is-Flat-Twenty-first/dp/0374292884.

And you have to innovate. I cannot recall the number of conversations I've had over the years which evolve roughly as follows (I'm the 'technologist' here):

[technologist] 'You can do this feature with open technology.'

[incumbent] 'Don't do that, you'll compete w/ my value proposition.'

Which is sometimes met by 

[incumbent's marketing] 'It's easy to pass someone by when they are standing still.'

Exactly.

Regarding this exchange, the technologist doesn't want to break the cathedral's feature since both parties often work for the same company. But the technologist does observe these business facts to his colleagues, namely that the bazaar has the potential to power this disruption. Given that potential, why not disrupt yourself? I use the analogy of driving down I-5 to Portland. I can mind the fuel gauge and re-fuel when necessary. This entails diligence in observing the physical reality of an automobile. Or I can ignore reality and run out of gas in the middle of the interstate. The fuel constraint is like the competitive technology, you should only ignore at your own peril and 'control' the phenomena as best you can.

In the thick disruption and openness, being open also helps solve the outside-in problem. Sometimes a technologist in the cathedral wants to drive something that the other priests in the cathedral are loathe to support. So the 'outside-in' strategy can include getting customers (i.e,. the 'outside') excited and pulling the internal team (i.e., the 'inside') to respond. This is the less-kind version of  http://knowledge.wharton.upenn.edu/article/outside-in-strategy-for-the-c-suite-put-your-customers-ahead-of-your-capabilities/ since recalcitrant priests may be caught flat-footed to respond to the customer request once the outside-in push accelerates. But by enjoining the outside with open source ecosystems, there is a ready substrate to help the cathedral meet the incoming business request. Essentially the bazaar is the join point and shared infrastructure to evolve technology between partners, such as common open source code into which the cathedral can accrete its features.

The other fact I have realized over time is that everyone has their own cognitive frame and history. This is where the humanities http://blogs.scientificamerican.com/cross-check/2013/06/20/why-study-humanities-what-i-tell-engineering-freshmen/ still have a place in engineering. The arts teach 'how' to think and embrace change. Whether its the questioning of all premises in the spirit of Socrates, realizing the arbitrary language games of many conversations via Wittgenstein, or treating the world with skepticism that is resolved via Popper-like proofs and refutations. Take these words with a grain of salt, of course, as my bachelors degree is in electrical engineering and my masters in computer science. Thus you're reading the advocacy of an autodidact in the humanities, not a lettered representative therein.

And sometimes you just need time to be alone with your thoughts.

And you have to leave your ego at the door. The best advice I received on this point came from Andrew Fish, who once confided in me his secret, namely when you are in the thick of a debate and you realize that you are in the wrong, do the 'flip', or embrace the interlocutor's position. There is no shame in evolving your position in light of additional data. The flip should be done with due care and consideration lest you become a relativist or perceived as wishy-washy, but you must observe the truth when you see it. Part of leaving your ego at the door also includes taking criticism and feedback. You will often be incorrect, or not everyone will love you or your ideas, especially if you are on the wave front of a disruption. And the more you disrupt, the more ire you might draw from your peers and the incumbents.  And following Rumsfeld, "Learn to say `I don't know.' If used when appropriate, it will be used often."

And you must also always tell the truth. My best advice in this vein comes from Mike Richmond: "Never lie, but don't always tell everything." Telling the truth and being genuine eases the burden of having different stories for different parties and having to compartmentalize yourself. You will ultimately succeed on being transparent and delivering value, not on dissimulation and currying favor.

Another piece of advice includes finding the true root cause of an issue. It's quite easy to 'blame' other people, or the ad hominem attack, since the targets are nearly inexhaustible, with the last number I heard pinning the figure at a world population of over seven billion people in 2013. This class of attack sows enmity and reduces your credibility since a barbed tongue replaces truth.  But the technique goes pretty far, especially within companies. Only when existential realities like external market forces or internal resources enter the fray does this technique lose its potency.

Also, I observe that technologists who were most successful in the last disruption have difficulties in adapting to the next trend. I analogize this to the armies in the wake of World War I (WWI). In that conflict, trench warfare prevailed and the best defense devised for future conflicts by the French was the Maginot Line, or an armored variant of a trench covering their border. When World War II occurred, airplanes flew over the line. The quote that is often related to this historical event includes: "generals always fight the last war, especially if they have won it."

In the technology industry, you can imagine the parallels to the Maginot Line. Specifically, the technologist who drove the last disruption may be loathe or unable to address the next one. To me, you should always acts as the challenger, or a recent colleague graduate, with something to prove. The technology industry doesn't respect tenure. It instead demands results. And as Heraclitus said (now we're going pre-Socratic), "you can never step in the same place of a river twice." In the river of technology, that has never been more true than today.

But spotting trends is tough. I recall the exuberance of Gilder's Telecosm.  This hasn't aged as well as Grove's or Christensen's books, I fear. It turns out that the fiber of the Telecosm became the conduit for the web and data traffic that drove the new businesses, such as Google.

And having a network doesn't just include your co-workers. Your network should span other industries and companies - see advice on same at http://www.forbes.com/sites/ricksmith/2014/07/02/5-career-mistakes-you-will-regret-in-10-years/. I still remember my first trek to the Intel Developer Forum where I presented in 2003. The then-CTO of Sun Greg Papadopoulos said in his keynote "All of the smartest people don't necessarily work for your company." Your company does have the smartest people who are both dialed into the road map, strategy and capabilities of that enterprise, though, so I believe the advantage still goes to the company - necessary for success, but typically not sufficient (i.e., the 'if' but no the 'iff'). To close the sufficiency argument (and get to 'iff'), alternate views and help of others, especially in open ecosystems I've described in this posting, are key. As evidence of same, just throughout these recent blog entries you'll find reference to colleagues both within and outside of my company from whom I have had the honor to learn and collaborate over the years.

So you might not always guess right, but by enjoining the community with openness, listening, and reacting to the customer and acclimate market needs, you'll do fine. The tactics might include a pivot, flip, or re-plan, and through all of those actions remain genuine, honest, and work hard.

Speaking of working hard, time to get back into the melee and cease by blog graffiti on the wall of the internet.

"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