300, networking, FSP, books, and good-byes

It was October of 2012 when I posted http://vzimmer.blogspot.com/2012/10/250.html.  Over a year and a half later I have finally hit 300 issued US patents 300 issued. In later posts I talked about innovation and invention http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html, so I don't have much to add.

Probably closer to my mind includes recent events. Since my last posting I had the opportunity to talk with the industry about UEFI and testing. With Ricard Neri from Intel's Open Source Technology Center I spoke at the UEFI Plugfest in Seattle last month. Our presentation and video of the same on "Open Source Test Tools for UEFI” are located at http://www.uefi.org/sites/default/files/resources/2014_UEFI_Plugfest_04_Intel.pdf and https://www.youtube.com/watch?v=aV1DSF4cwGw, respectively. I will pick up on some of the topics of open source security and tools at the upcoming ToorCamp, too http://toorcamp.toorcon.net/talks/#16.

Other events that have occurred since my last posting include publication of the UEFI 2.4 specification. Items of note there include removal of the need to time stamp each UEFI network packet and manage volatile variables for the network stack. This is important because the former entails a call to the real-time clock (RTC), which is an expensive I/O operation on some systems and may entail a system management mode interrupt (SMI) trap, which has non-zero overhead to effect the world switch. Similarly on the volatile variables. Many implementations of UEFI implement all of the variables in SMM in order to protect authenticated variables, thus even an update to a volatile variable in the performance path of the network stack can entail significant overhead. My colleagues posted a paper on these issues of PXE performance at https://uefidk.com/sites/default/files/Intel_UEFI_PXE_Boot_Performance_Analysis.pdf.

Speaking of UEFIDK.COM site, I have been encouraged to blog there, but I have yet to wean myself off of this site. Hopefully my next blogs on UEFI will migrate to that location. From that site I'd also like to note the existence of

Intel® Firmware Support Package (Intel® FSP) For MinnowBoard

·         "Wrappers" and Instructions for using Intel® FSP with MinnowBoard

·         Intel® FSP is Available from the Intel® Embedded Design Center
(Intel® Atom™ processor E6xx series with Intel® Platform Controller Hub EG20T )

- See more at: http://www.uefidk.com/content/minnowboard-uefi-firmware-download#sthash.X6BoqM8T.dpuf

under http://www.uefidk.com/content/minnowboard-uefi-firmware.  This shows how to adapt the Intel Firmware Support Package, or 'consume' that binary, into an edk2 http://edk2.sourceforge.net tree. Similar infrastructure code in the coreboot upstream at http://www.coreboot.org can be found to do similar integration, or how to 'consume' the FSP http://review.coreboot.org/#/c/4018/.  These are two examples of workflows of open source firmware ecosystems that allow for building platforms with the FSP.

To provide guidance around the FSP construction, on both the 'producer' and 'consumer' side, the Firmware Support Package (FSP) External Architecture Specification (EAS) has been posted to the location

http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/fsp-architecture-spec.html. This helps to lock down the interfaces so that the above listed firmware ecosystems can align their 'consumer' source infrastructure codes.

Why FSP?  Even UEFI/Edk2 stalwarts like my good friend Tim Lewis, CTO at Insyde Software, have expressed thoughts on using edk2 for embedded, including anecdotal commentary such as http://uefi.blogspot.com/2014/04/the-tale-of-three-conferences.html

Many discussions around UEFI have to do with complexity. And there is something to these discussions, since the very power and flexibility of UEFI has led to implementations (like that on tianocore.org) which are broken into hundreds of pieces, where assembling the right one requires the right recipes. Most embedded vendors don't need their firmware distribution to be as complicated as their Linux distribution (see yoctoproject.org).

So you can think of FSP + EDK2 as one 'recipe', among many, to ease the embedded workflow in various open source firmware ecosystems. FSP helps preserve the boundary of critical silicon initialization code, with some examples found in PI Silicon Init. This doesn't describe the only mechanism, of course. But given the end goal of booting an operating system, Mille viae ducunt homines per saecula Romam.

So enough of UEFI and FSP, an additional thought on this 'milestone day' of 300 include a mention of a book that I enjoyed reading over the last few weeks, namely Ben Horowitz's The Hard Thing About Hard Things  http://www.amazon.com/Hard-Thing-About-Things-Building-ebook/dp/B00DQ845EA/. Ben was a leader at Netscape during the startup days, and his book ranks among Andy Grove's High Output Management and Only the Paranoid Survive as more proactive business books, or managing a business in a crisis. Specifically, Horowitz speaks of the distinction between the "Wartime" versus "Peacetime" CEO. He notes how Eric Schmidt was a peacetime CEO of Google, with features like the 20% time, versus Larry Paige becoming a wartime CEO, and the more narrow but aggressive product focus.

After reading Ben's book, the question I would pose is if the same analogy works for engineers, or more generally, the employees. Namely, are some employees better at peacetime, with the less stress and ability to explore more things, than in wartime, with the enhanced focus?  I personally find constraints help with focus, and Paige's 'Scarcity brings Clarity' comes to mind. Food for thought.

Speaking of thoughts, I'll close with thoughts on co-workers who have departed. Over the last day I learned about a manager with whom I worked since the last 90's has passed away. I learned a lot from his mentoring, and I especially recall a quote he made about project development at a technology company: "If upper management knew the true cost of an R&D project, they would never fund it." Fare well, Doug.

A couple of additional thoughts are for technical colleagues still with the world, but who have recently retired from Intel. One is a Senior PE from Folsom on the CPU development team. I learned many things from Steve about the trade-off between hardware and software, especially disabusing me of the fact that 'the other guy's job is easier.' I relent and the CPU microarchitects win for complexity. Talking to Steve was like reading Colwell's tale http://www.amazon.com/Pentium-Chronicles-Politics-Landmark-Practitioners-ebook/dp/B001CBCRCA/. A parting quote from Steve that sticks with me is “You will not have all the answers, but in working with the right people, you can find them.“  So true. And thanks to the 'right people' who still answer my emails, pick up the phone, and look up from their monitors when I invade their cubicle.

And last but not least, I have to comment on the retirement of George Cox. George had a rich Intel career, including setting up the first intel.com website, CDSA, iWARP, the Intel 432, and one of his last achievements, the digital random number generator (DRNG) http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0. On the latter I still recall George quoting John von Neumann, in Geoge's distinct West Texas accent: 'Anyone who uses software to produce random numbers is in a ``state of sin''' when discussing the DRNG work with me over lunch.  That work, and the 432 http://en.wikipedia.org/wiki/Intel_iAPX_432, count as epic events in just one career, and I'm still a fan of hardware capabilities http://www.google.com/patents/US8312509, especially as it's tough for 'software to protect software.' We all need a little help from our hardware friends.

Since I started the thread with patents, I'll end with patents. Intel has been a great place to work. I joked on my Google+ channel that this is the closest I'll ever get to the C-suite in response to the patent award photo at https://plus.google.com/+VincentZimmer/posts/R764RmhX7tg. In reality, though, Intel has offered me an opportunity to work with some of the smartest people in the industry and learn from them. I only hope that I can contribute back a small percentage of what they have provided to me over the years.

And with that, off to work.