I just returned from the Open Compute Project (OCP) U.S. Summit 2016 in San Jose. I gave a talk on firmware updates http://ocpussummit2016.sched.org/event/68u5/towards-a-firmware-update-standard. The talk has also been posted to Youtube http://www.youtube.com/watch?v=3yGbwUwwjxc. I This talk builds upon the background provided at the 2015 OCP and UEFI PlugFest, respectively, as described in the "UEFI and the Cloud" posting https://firmware.intel.com/blog/uefi-and-cloud.
For this talk we laser-focused in on the firmware update topic. I received feedback, such as "Good message this morning, glad you guys are interested/passionate about OCP from a FW ecosystem sanity perspective."
The material has a home at http://www.uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf, but it should get posted to the OCP website shortly.
One of the messages we wanted to provide is that the UEFI Capsule interface is both a host-based API. From the UEFI specification we have the interface to send a capsule (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf)
and then the EFI System Resource Table (ESRT) to detect what are the capsule-updatable elements (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf).
Beyond the API we have the envelope or data payload (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf):
All of these elements are brought together in the graphic from the prezo and former white papers (from figure 5 of https://firmware.intel.com/sites/default/files/resources/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf):
Our advocacy in the 2016 talk was that even if the update is delivered out-of-band, say via a service processor, the data envelope should be the same. Imagine an independent hardware vendor (IHV) curating an update blob. Why tax the IHV to create separate blobs for different delivery paths?
Going forward we will work with other standards bodies like the DMTF http://www.dmtf.org/, along with OCP opencompute.org and the UEFI Forum uefi.org, to harmonize these efforts. And along with the standards work engage with open source upstreams like tianocore.org to have a robust implementation. And given https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload it would be great to have co-equal support in both firmware ecosystems, including coreboot.org.
PS
Sad news today about Andy Grove https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/. It reminds me of my early days at Intel, including the signed copy of his man of the year issue I received as a new employee at Intel http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html.
For this talk we laser-focused in on the firmware update topic. I received feedback, such as "Good message this morning, glad you guys are interested/passionate about OCP from a FW ecosystem sanity perspective."
The material has a home at http://www.uefi.org/sites/default/files/resources/OCPsummit2016_Towards%20a%20Firmware%20Update%20Standard.pdf, but it should get posted to the OCP website shortly.
One of the messages we wanted to provide is that the UEFI Capsule interface is both a host-based API. From the UEFI specification we have the interface to send a capsule (from http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf)
All of these elements are brought together in the graphic from the prezo and former white papers (from figure 5 of https://firmware.intel.com/sites/default/files/resources/UEFI_Plugfest_2015_Challenges_in_the_Cloud_Whitepaper_0.pdf):
Our advocacy in the 2016 talk was that even if the update is delivered out-of-band, say via a service processor, the data envelope should be the same. Imagine an independent hardware vendor (IHV) curating an update blob. Why tax the IHV to create separate blobs for different delivery paths?
Going forward we will work with other standards bodies like the DMTF http://www.dmtf.org/, along with OCP opencompute.org and the UEFI Forum uefi.org, to harmonize these efforts. And along with the standards work engage with open source upstreams like tianocore.org to have a robust implementation. And given https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload it would be great to have co-equal support in both firmware ecosystems, including coreboot.org.
PS
Sad news today about Andy Grove https://newsroom.intel.com/news-releases/andrew-s-grove-1936-2016/. It reminds me of my early days at Intel, including the signed copy of his man of the year issue I received as a new employee at Intel http://vzimmer.blogspot.com/2014/02/anniversary-day-next-next.html.
