27 or Anniversary.Next^12, AI, Runtime

Anniversary

True to form, today is my work anniversary. I started Intel on February 24, 1997 This post also builds on my last posting in this vein http://vzimmer.blogspot.com/2023/02/26-or-anniversarynext11-and-wisdom-of.html. At this point I have spent more than half of my life on this planet at this single company.  

Since the last posting I've been back to the office daily, sometimes visiting the Crossroads for lunch, where I had my first sighting of a Cyber Truck.

I'd often work through lunch and eat from the local self-serve facilities but the pickings have been slim. So slim that even a 2-month-expired tuna sandwich was eaten by someone.

 I last took a sabbatical in 2011 where I smashed up my arm on the 2nd day and ended up w/ 2 surgeries. I still recall the one-handed typing away at the ITJ articles https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf that appeared later that year.  Typically sabbaticals expire but with the strangeness of COVID there were extensions that turned into a revised evergreen policy where sabbaticals no longer expire.  Regrettably, though, one stops accruing time after reaching 16 years. Looks like I need to pull the trigger on at least one month in the upcoming year, viz.,

 

Beyond cyber trucks, old sandwiches, and sabbaticals, the last year has seen a lot of energy around AI. Even the University of Washington lecture series has been dominated by this topic. An interesting talk from Meta was included in https://www.ece.uw.edu/news-events/lytle-lecture-series/ with slides https://www.ece.uw.edu/wp-content/uploads/2024/01/lecun-20240124-uw-lyttle.pdf and a recording https://www.youtube.com/watch?v=d_bdU3LsLzE. You can catch me at 6:36 on LHS of the screen

It's always interesting to be there in person. One comment that intrigued me was a comment from Yann LeCun about the Metaverse build out and GPU procurement. I cannot recall if it was on-tape or off-the-record so I've avoid going further than that.

This talk was at the Lyceum HUB but all of the other talks were across the street.

Another interesting talk https://www.cs.washington.edu/events/colloquia/details?id=3310 was from Fei-Fei Li of Stanford and ImageNet https://ieeexplore.ieee.org/document/5206848 fame.

This was near the comp sci building

LeCun's and Li's talks were like Taylor-Swift-concert-crowds but for techies. Nice to see these thought leaders share their insights and experience in person. 

Google Waymo was also in the mix with a talk https://tcat.cs.washington.edu/events/taskar-center-memorial-distinguished-lecture/ on the challenges of autonomous driving and AI https://www.youtube.com/watch?v=pK5ChzMsfE0

So let's pivot from AI lectures to a topic closer to home, namely firmware runtime. I chose this topic since one of the most popular posts is on this blog series was UEFI variable runtime http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html. I suspect this stems from the fact that most folks have interactions during life of platform at runtime. In our quest for 0-second boot this makes even more sense. 

Regarding how firmware is exposed to the operating system, and thus ultimately the user, at runtime, there are various modalities. 

These include:

• Static info tables
• Advanced Configuration and Power Interface (ACPI)
• Flattened Device Tree (FDT)
• Interpreter bytecode
• ACPI AML interpreter
• UEFI EBC sandbox
• x86 VDM for video int10h calls
• Native code runtime
• UEFI runtime
• Power9 OPAL
• Platform Runtime Mechanism (PRM)
• Opaque host modes - synchronous and asynchronous activations

• SMI(SMM)- x64
• SMC(TrustZone)- ARM
• Trap(Machine Mode) - RISC-V

These are all for the host firmware, or firmware running on the main application processor/core.

There is also device firmware running in the SOC.

In addition, at the platform level, the host can signal 'non-host' such as an Embedded Controller (EC) on client and Baseboard Management Controller (BMC) on server.

Below shows some of the latter 

 

    

 from https://link.springer.com/book/10.1007/978-1-4842-7939-7.

A lot of the flows are blended. For example, some of the descriptions of ACPI and SMI for errors described in https://cdrdv2.intel.com/v1/dl/getContent/671067 but the paper is light on ACPI.

Regrettably the collection at https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A is pretty spare on ACPI, too, although https://link.springer.com/book/10.1007/978-1-4842-7974-8 covers construction and design in the case studies.

A curation of ACPI material can be found in the following:

Public documents on ACPI

2022

Intro to ACPI from ACPI spec

https://uefi.org/specs/ACPI/6.5/01_Introduction.html

2019 

ACPI tutorial

https://acpica.org/sites/acpica/files/asl_tutorial_v20190625.pdf 

2013

ACPI and UEFI

https://cdrdv2.intel.com/v1/dl/getContent/671067 

APEI and UEFI

ACPI overview https://www.intel.com/content/dam/www/public/us/en/documents/research/2009-vol13-iss-1-intel-technology-journal.pdf

2009

ACPI and SMM

https://link.springer.com/article/10.1007/s11416-009-0138-0 

2006

ACPI attacks

https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf 

2004

ACPI HOWTO

https://tldp.org/HOWTO/pdf/ACPI-HOWTO.pdf

2003

IA64 book, including UEFI and ACPI chapter

https://www.amazon.com/Itanium-Architecture-Programmers-Understanding-Processors/dp/0131013726

 

2001

ACPI Book

https://dl.acm.org/doi/book/10.5555/940719 

1997 

ACPI implementation guide

https://www.baldwin.cx/~phoenix/reference/docs/acpi_impguide.pdf 

1996 for first spec - full history in 
https://en.wikipedia.org/wiki/ACPI 

 

A colleague suggested that I should have spent more time in the books writing about ACPI since he spends his time debugging issues on Windows and can quote many instances of poor or misunderstood ACPI constructions. I also chronicled in the past my exchange https://vzimmer.blogspot.com/2018/ with the Linux kernel leadership on the topic. 

A lot of people grouse about UEFI and ACPI when in fact it isn't the standard they are critiquing but instead the implementation.  Namely, it's often a confusion between interface and implementation. 

For example, on topics like the firmware support package (FSP), I hear complaints. I often offer the following dichotomy there:

    Consumer (caller)

    Interface (specification)

    Producer (implementation)

You can find examples of using FSP (consumer/caller) with EDKII 

https://www.intel.com/content/www/us/en/content-details/671038/a-tour-beyond-bios-using-the-intel-firmware-support-package-2-0-with-edk-ii.html or coreboot https://link.springer.com/chapter/10.1007/978-1-4842-0070-4_4. The interface itself is defined at https://github.com/intel/fsp/wiki, and one way of building (producer/implementation)

https://cdrdv2-public.intel.com/671296/a-tour-beyond-bios-creating-the-intel-firmware-support-package-with-the-efi-developer-kit-ii-fsp2-0.pdf.  As such, there are 3 layers.

Sometimes people grouse about FSP when in fact it's the implementation, not the API. And it has been a long run on FSP. The Intel IOTG folks kicked it off in 2010 and then Jiming and I conspired to have a working group that I've lead/co-lead since 2014 on the same with various other co-leads and collaborators along the way. Some of the outputs of that collaboration that record Maurice, Ravi and Jiming details can be found in the '15 book https://link.springer.com/book/10.1007/978-1-4842-0070-4, too. Maurice is now doing great things in fw at MS and Jiming at AMZN, resp., AFAIK. One of my key contributions in those 2013/2014 days was teasing out the FSP spec which was originally an amalgam of silicon details and API's into a couplet of docs, namely the main interface spec, the FSP EAS, and the respective SOC integration guides, such as can be found today in https://www.intel.com/fsp and in https://www.github.com/intel/FSP, respectively. This allowed for creating class drivers for FSP in the various platform code (e.g., coreboot and EDKII at the time) and abstracting SOC specifics. And I should forget how the decade+ of cross-group collaboration allowed for scaling FSP's from embedded to both mainstream client and servers, as demonstrated by the rich postings on Github. It's not a perfect split between EAS and integration guide, though, but as we've struggled with the 2001 Intel Framework API's and 2006+ UEFI PI spec interfaces, building that 'firmware socket' set of abstractions is tough given the variability of silicon and products over time.

Same with UEFI.  The interface is at https://uefi.org/specifications. Two implementations can be found at https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Dxe and https://github.com/u-boot/u-boot/tree/master/lib/efi, respectively. Most folks complain about the EDKII implementation when they invoke 'UEFI is broken', I feel. This reminds me of the sentiment that some person with the handle of 'the_panopticon' mentioned in https://news.ycombinator.com/item?id=39481434. 

So back to ACPI. The evolution of ACPI in the did-90's predates late 90's EFI. EFI started as a sample and then the Tiano project with EDK and then EDKII subsumed Framework/PI and EFI/UEFI but not the ACPI specification. As such, no modularization of ACPI from the beginning because of Conway's Law (i.e., the folks who owned the UEFI spec and its reference implementation didn't own the ACPI spec for the first nearly 2 decades). In fact a lot of the ACPI table construction on the Intel platforms was derived was the DaVinci/Kittyhawk clean-room C BIOS that pre-dated Tiano in that hotbed of late 90's BIOS innovation called DuPont, WA Intel site. This model of static tables differs from the ARM ecosystem which does dynamic table generation since they started much later on the journey and had a single-team/Linaro view of entering standards-based firmware.

An advantage of dynamic table generation is flexibility but a downside is that it is harder to do attestation since the table fields are not known at build time. Even build time calculations, though, are aggravated by patching. So in practice it is not really done, just like a lot of configuration and PCR[1] content not really be reconstructed for some attestation / verifier flows.

Thinking about these taxonomies of firmware, from SAL+BIOS to Kittyhawk to ACSFL to EDK to EDKII to slim bootloader to coreboot to.... I realize that I might have the dubious honor of having worked on the broadest variety of host firmware at my employer.

Time marches on. In mentioning DaVinci/Kittyhawk workstation BIOS, I realize that my colleagues on that late 90's adventure have largely left the company, from retirement to downsizing to becoming execs at other tech shops (e.g., MS). Similar to the thinning of the crowd of others, such as even my 2015 colleagues from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk who have all left for startups (e.g., Eclypsium) or retirement or other big tech (e.g., Amazon). Well, given those statistics and chaos in tech, this might by be my last Next^* blog. Even if it is, though, I have enjoyed the run and people I've met along the way. Hopefully I have re-payed my employer's and colleagues trust with sufficient contributions these last 27 years.  

Cheers

"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.

Deprecation and introduction of interfaces

Specifications may appear to be static codifications set in stone, but they are often evolutionary species. One of the challenges in evolving a specification includes when, if ever, to deprecate content in lieu of new additions. Sometimes technology may fall out of use or be deemed by the market not to be the most viable. Often, though, this class of information is not elided from specifications unless they are hard scientific reasons, like elision of MD5 or SHA1 from specifications 

because of pre-image attacks https://en.wikipedia.org/wiki/Preimage_attack. I recall one person telling me that about 40% of the Wifi specification was relevant; the key was knowing 'which' 40% merited attention.

This blog will talk about a few specifications, such as the UEFI, PI and Intel SDM, that weigh in at several thousands of pages. To be with the UEFI and PI specification, one area that has potential for deprecation is Itanium support. The EDKII upstream has already removed Itanium related code from the various packages. There are vestiges of Itanium in chapter 2 of the UEFI Specification https://uefi.org/specs/UEFI/2.10/02_Overview.html#intelitanium-based-platforms for the calling conventions, though. Similarly, support for the Itanium reset paths https://uefi.org/specs/PI/1.8/V4_MCA_INIT_PMI_Protocol.html# and extended SAL https://uefi.org/specs/PI/1.8/V4_Sal.html services can be found in the PI specification. The latter of which was the EDKII adaptation of calling the Itanium System Abstraction Layer (SAL) (SAL) https://redirect.cs.umbc.edu/portal/help/architecture/24535901.pdf interfaces from a UEFI environment. 

As a quick background, Itanium had a platform scoped SAL and processor scoped Processor Abstraction Layer (PAL) set of firmware layers designed to provide both boot and runtime services. The RISC-V Supervisor Binary Interface (SBI) https://github.com/riscv-non-isa/riscv-sbi-doc is sort of an amalgam of SAL and PAL since it provides both core, SOC and (potential) platform capabilities. SAL is interesting in that unlike UEFI, that goes into a virtual-only calling mode after SetVirtualAddressMap(), the SAL calls could be called in either physical or virtual mode throughout the life of the platform. This posed some challenges for writing UEFI code since position independent code (PIC) options for C compilers haven't been universally supported across all of the EDK toolchains, especially in the early days with Visual Studio, or for IA32 with its inability to read the instruction pointer address as possible in other architectures. For assembly-language Itanium code it was pretty simple to write PIC code. So the Extended SAL (ESAL) of the PI spec and EDKII provided a way to have non-fixed up and fixed up C code that would use a common data area. 

In addition to the SAL support, another fascinating aspect of Itanium was the support for floating point exceptions in the Floating-Point Software Assist (FPSWA) https://redirect.cs.umbc.edu/portal/help/architecture/24541501.pdf driver, as described in https://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143 

This driver was loaded from the EFI System Partition during boot and would provide runtime support for floating point exceptions. Regrettably soft-loading critical flows from disk like the FPSWA have not been pervasive, even in the face of relatively expensive $/byte of semiconductor NOR SPI flash. This stems from the supply chain challenge where the motherboard and fixed disk media may be provisioned, secured, and recovered by alternate parts of the ecosystem, namely OEM/ODM for the board versus OEM/ODM/integrator/VAR/IT for the disk and its bootloader and OS images, respectively.  

Another area that is an interesting artifact from the past is the BIOS interface in the Intel Software Developer Manual https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf. This interface is an Int15h API to manage microcode patches.

Starting in the early 1980s, the PC/AT BIOS exposed services through 16-bit 'int' calls or software traps, which the most famous being Int13h for disk access, Int 10h for video, etc. These API's all have correlatives in UEFI, with Int13h having the equivalent in EFI_BLOCK_IO_PROTOCOL, for example. The Intel Framework Compatibility Support Model (CSM) specification https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-compatibility-support-module-specification-v098.pdf provided a bridge from EFI into BIOS calls in the early days where there were few EFI native drivers, for example. But the CSM support was not introduced into the UEFI PI specification since the idea with PI commencing in 2006 would have UEFI-spec-defined APIs. In fact, Intel declared the PC/AT BIOS interfaces to be end-of-life in 2020 https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020 

and http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf.

That's where the Int15h API mentioned above is interesting. It can either go away as its the only BIOS API in the SDM, or it could be complemented by/replaced with a UEFI equivalent. To that end, the https://raw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf design reads on this capability 

The mapping of the UEFI interfaces to the Int15h included

with the specific capsule itself having the following layout

The generic capsule overview flow is described in the UEFI specification https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#update-capsule 

and other write-ups https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure and https://archive.fosdem.org/2020/schedule/event/firmware_culisfu/attachments/slides/3709/export/events/attachments/firmware_culisfu/slides/3709/FOSDEM_2020_Intel_Capsule_Update.pdf. As the code-base has been re-arranged in the open, the most recent location to find the FMP DXE Microcode Capsule support is https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Intel/IntelSiliconPkg/Feature/Capsule and of course https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. 

This builds upon the generic FMP 

and capsule update flow 

widely deployed today. Maybe avoiding putting something 'post-Int15h' in the SDM is a wise move, though, considering the plurality of interfaces for firmware updates, from https://slimbootloader.github.io/security/firmware-update.html to https://uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf to https://uefi.org/sites/default/files/resources/PRM_Platform_Runtime_Mechanism_1_1_release_candidate.pdf to https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf to.... It's a veritable embarrassment of riches.

Open platforms snapshot - May 2023

From https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel there are a rich set of platforms for EDKII in the open. 

Other than emulation platforms like SIMICS or 32-bit IOT Quark, which are all open source, the rest of the platforms are based upon variants of the Intel Firmware Support Package (FSP) https://github.com/intel/fsp

 

But how did this journey begin?

The first public discussion of the need to have a simpler, more open set of platform code commenced in 2014. I described this 'min tree' effort in the following 2015 prezo  https://github.com/vincentjzimmer/Documents/blob/master/OSTS-2015.pdf

 

 

 

 with guidance around how to take a large internal, closed source corpus into something smaller

 

 The strategy included the following elements

 

 

I described the value of open source for security assurance in another venue https://www.intel.com/content/dam/develop/external/us/en/documents/stts003-sf15-stts003-100f-820238.pdf

including the Baytrail-based MinnowBoard and Quark

I was a strong proponent of openness allowing for better security. One caveat I missed was that once the code is out there and bugs are found, then others will all lean in to help fix, at least for shared 'core' code, not https://en.wikipedia.org/wiki/Tragedy_of_the_commons

The challenge at the time was how to structure the code. We used Quark, since it was fully open, to model some of the software practices https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf

 

 

 

 

The approach entailed a decomposition of the workflow for configuration, porting, and feature addition.

At this point we only had Atom-based Minnow in the open. During this time we worked w/ the business units to get permission to open up a big core based platform code, namely Kaby Lake, and a Xeon big core server, namely Purley. The work is described 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

 

 

 

 

These studies provided a decomposition both logically

 

 

and in the source code

 

 

We updated the ecosystem on this work in https://www.platformsecuritysummit.com/2018/speaker/

This provided an overview of the server work and also a description of the software stacking.

Another view provided the workflow of the open source core on the left, the silicon packages in the middle, and the open source platform code on the right in order to curate a complete solution.

The best description of the overall workflow with a given SOC was described in https://www.intel.com/content/dam/develop/external/us/en/documents/uefi-firmware-enabling-guide-for-the-intel-atom-processor-e3900-series-820238.pdf in 2018
 

Just as we explicated security best practices in  https://link.springer.com/book/10.1007/978-1-4842-6106-4, we did describe some of this platform work that is now embodied as the 'min platform architecture' (MPA) https://github.com/tianocore/tianocore.github.io/wiki/Minimum-Platform-Architecture--MinPlatform.

Specifically, the book https://link.springer.com/book/10.1007/978-1-4842-7974-8 and its associated site https://github.com/Apress/Firmware-Development touch on this topic

 

With the evolution of a min-tree and min platform

and the MPA stack itself.

This work is also included in training material https://github.com/tianocore-training/PlatformBuildLab_MinPlatform_FW.

 

The idea behind 'min tree' was to right-size things. One of the concurrent investigations was to subset the main edk2 upstream, including breaking down some of the existing packages https://github.com/tianocore/edk2/compare/master...jyao1:edk2:ReOrg. Many companies do git-filtering to pull a subset or curate a smaller list of packages, like https://microsoft.github.io/mu/ with https://github.com/microsoft/mu_tiano_plus. The platform clean-up was easier since we historically cloned-and-updated platform code per generation, whereas the core packages are often reused, with figures like below from http://masters.donntu.ru/2020/fknt/yakubov/library/article6.pdf

Then there is also the 'Tragedy of the Commons' allusion wrt core I mentioned above.

As such, the feedback from the ecosystem at the time was that convincing management types to change a code base, albeit for a slimmer one, was a hard sell since it would invariably lead to new issues, including potential bugs. The older core had the advantage of years of flight-testing, namely evidence-of-use. But I was told that if new capabilities were added to vet the quality, such as testing / unit testing, then it would be an easier argument. That was a tough story to sell 5+ years ago but today falls on more friendly ears with the community rallying around things like https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg. Even though there are a paucity of unit tests written today, the above package forms a foundation to get that trust such that more radical refactoring can be done with higher confidence. I remember the TPM TSS project lead telling me that they had 90+% code coverage and any potential commit that broke a unit test or dropped that % was automatically rejected. 

The same story holds for evolution of new techniques like memory-safe languages like Rust into a large extant code base. Although the rewrite of critical libraries in Rust https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf showed efficacy

given history like https://www.blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-Wojtczuk-AtkIntelBios-SLIDES.pdf

the cost of integrating the language in mainline and the hardening since 2009 make it a hard sell. But for 'new code' with tricky attacker-controlled data types, perhaps the dialectic can lean toward embracing language-based security?

Speaking of wisdom of others, some of this work for a min* was motivated by a comment I heard from https://en.wikipedia.org/wiki/Window_Snyder, namely 'the security defender's best weapon is the "delete" key.' Specifically, deleted code cannot have CVE's or a lack of test coverage. So 'min' as a tactic for 'less code' is often a salubrious path to pursue.

Regarding the thread on platforms above, mentioning MPA doesn't mean that there are not other open opportunities beyond EDKII.  There are examples such as https://github.com/slimbootloader/slimbootloader/tree/master/Platform

and https://github.com/coreboot/coreboot/tree/master/src/mainboard/intel

 

 

You can find info in https://link.springer.com/book/10.1007/978-1-4842-7939-7 https://github.com/Apress/System-Firmware

 

for slim bootloader

 

 

and coreboot, respectively.

Speaking of the various platform code embodiment's, efforts like Universal Scalable Firmware Architecture (intel.com) https://universalscalablefirmware.github.io/documentation/ work to find reuse across these different environments

 This work also mentions accommodating Rust-based designs, including https://github.com/oreboot/oreboot, which is mentioned in the first of the two books above https://link.springer.com/book/10.1007/978-1-4842-7974-8, too.

 and https://github.com/u-boot/u-boot, too

 including its use in https://github.com/openbmc/openbmc

PS
Sometimes my blog posts are like Joyce's Finnegan's Wake where the last sentence and the first sentence of the book overlap.  Or maybe a snake eating its tail?  Whatever the literary motif or allusion, another of the slides from the 2015 prezo at the top of this post, namely

reminded me of more recent happening in the industry, namely the 2021 prezo from AMI https://www.youtube.com/watch?v=SeiigV8PJPE and the Aptio Open edition. It describes their variant of this 2015 vision for OCP realized in practice in 2021

This leverages the work out of the Open System Firmware (OSF) https://www.opencompute.org/wiki/Open_System_Firmware

https://docs.google.com/document/d/1pvb4cyQIdXzOtmCb1y6o_6JBnJOx9DkdrMHeYHb5LU0/edit#heading=h.6iuk77tyg1a

Sidebar - what a change between 2018-2023. Ron now at Samsung. David at Amazon. Isaac recently retired from Intel. And Gundrala sadly passed

https://ocp-all.groups.io/g/main/topic/in_memory_of_gundrala/87592963?p=,,,20,0,0,0::recentpostdate/sticky,,,20,1,80,87592963,previd%3D1611775656365391031,nextid%3D1638983329612768441&previd=1611775656365391031&nextid=1638983329612768441. Gundrala and I collaborated quite a bit when he was at Intel, including

and many others

Gundrala is missed. It was nice having an opportunity to roll down 156th with him and grab Indian Food across from Crossroads here in Bellevue during his MS (post-Intel) years.

Ok. Back to the topics of open source platform code. So this 'open platform code/mintree' is another 'recent-to-past' binding. In general the 2015 to 2021 hang time of 6 years is not unreasonable. I once recall a software VP in early 2000's telling me that 'nothing significant happens in less than 10 years.' In the world of internet time and AI I suspect the timelines are a bit accelerated, but I have definitely observed that looking for quick wins in the infrastructure space rarely occurs. 

PPS

https://twitter.com/kirkbrannock/status/1665121431519367169

 

saddened me.  Kirk this year and Sham last year

have left the building to retirement, or as I sometimes joke "had a sharp enough spoon to dig out of Shawshank." https://en.wikipedia.org/wiki/The_Shawshank_Redemption

Good times working on BIOS with both, Sham being a huge mentor to me starting in 1997. He was sort of the "BIOS Yoda" when I joined Intel. Sham's the guy who did the first SMM BIOS enabling on the 386SL, etc. And I met Kirk in 1998 starting on workstation BIOS, EFI, and then many things platform thereafter, including great design oppty's with both like https://patents.google.com/patent/US7392371B2/en

which ended up landing in https://uefi.org/specs/PI/1.8/V3_Design_Discussion.html#firmware-file-system-format

Or with guru Sham on SMM on https://patents.google.com/patent/US6775728B2/en

that lives on today with things like https://uefi.org/specs/PI/1.8/V4_MM_Protocols.html#mm-mp-protocol.

And Sham also dropped one of my favorite farewell messages, viz.,

            As many of you have already heard - after 32+ years at Intel, I have decided to retire and start the next phase of my life’s exciting journey. I had prepared a very long farewell message for all of you, filled with my sage wisdom and list of accomplishments etc. etc. but then, I looked at the address field and it struck me that I still really like most of you on the list – so here is a short version.

 

            For past three decades, I watched technologies change. An amazing Technological Symphony was being played at Intel and I was fortunate enough to be hired into the orchestra as a bell ringer. I hope my cow bell went “ting” at the right time to make the symphony even more brilliant and melodious to the world, and that it helped to harmonize and amplify the brilliant voices around me. Now, a time has come for me to pass on the bell to steadier and younger hands that would ring the bell even more vigorously and timely than I could. As for me, I would gracefully join the audience and keep nodding as you play along taking this complex orchestra to dizzying heights.