I noticed the recent post on Google+ https://plus.google.com/u/0/113713059726404063654/posts/7KTPg174pm1 about the UEFI PlugFest presentation http://www.uefi.org/sites/default/files/resources/UPFS11_P6_OptionROM_AMI.pdf. Specifically, Brian's https://plus.google.com/u/0/+BrianRichardson/about slide 3 comment "–Designed to reduce code size".
Code size and host firmware implementations, such as UEFI-based solutions, can be a controversial topic. As can be boot-time, security,....
As such, I'm not going to discuss a feature comparison of coreboot versus EDK II for comparable hardware in this posting. I showed a design comparison of the firmware designs on slide 16 of https://firmware.intel.com/sites/default/files/resources/SF14_STTS001_102f.pdf, but size and / or other metrics like cyclomatic complexity weren't discussed. That'll be an exciting posting for another day. A data driven view is always the best way to approach this topic and I'd like to have 2 fully open platform trees build in coreboot www.coreboot.org (plus a payload like U-Boot http://www.denx.de/wiki/U-Boot with its I/O drivers) and EDK II http://www.tianocore.org/edk2/ on a community site.
There's no better way to teach developers about a topic than source trees, IMHO. I recall talking with a developer recently about SMM and Authenticated Variables. He had read https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf and kept asking follow-up questions. After seeing the EDK2 implementation https://downloadcenter.intel.com/download/23962/EDKII-Update-for-Intel-Quark-BSP and the PI SMM code therein he finally said "I get it."
And speaking of open source, glad to see posting of information like https://download.01.org/future-platform-configuration-hub/skylake/register-definitions/ to help enable open source firmware community development. Good stuff.
For this posting, though, I wanted to address the note above at the top of the blog regarding the plug fest presentation. The size comment was embedded in a broader point about "UEFI solves many problems for the IHV." It wasn't meant to be 'UEFI relative to something else', but more 'various embodiment options of UEFI.'
Specifically, the UEFI Driver Model has the concept of Bus drivers and Child device drivers. Common idioms are put into Bus Drivers, which today include USB, PCI, SCSI, Blue Tooth, etc. The bus drivers are typically stored in the system board ROM by the Original Equipment Manufacturer (OEM) so that the child device drivers built by the Independent Hardware Vendors (IHV's) only have to carry device specific code. The latter code is typically delivered as separate binaries in Host Bus Adapter (HBA) cards, such as PCI adapter, or embedded in the OEM system board firmware image.
The above figure from the UEFI 2.5 specification www.uefi.org above shows the relationship of the bus and child device drivers. Servers with sophisticated RAID and networking devices still enjoy the ROM savings and configurability afforded by the UEFI Driver Model. For small devices and more purpose build devices, this bus/device dichotomy may not yield as many code savings since you will not often observe a 1 bus to many devices relationship.
I don't want to be viewed as a UEFI apologist or partisan in this posting, but I did want to clarify the context of the 'size' comment here. It was size in the sense of, if given N PCI device drivers, either duplicate logic from the bus driver is copied into each device driver instance (e.g., EFI1.02), or the EFI1.10+ (now UEFI2.5) driver model with the bus and device driver dichotomy of sharing code logic pushed into the bus driver.
Cheers
Code size and host firmware implementations, such as UEFI-based solutions, can be a controversial topic. As can be boot-time, security,....
As such, I'm not going to discuss a feature comparison of coreboot versus EDK II for comparable hardware in this posting. I showed a design comparison of the firmware designs on slide 16 of https://firmware.intel.com/sites/default/files/resources/SF14_STTS001_102f.pdf, but size and / or other metrics like cyclomatic complexity weren't discussed. That'll be an exciting posting for another day. A data driven view is always the best way to approach this topic and I'd like to have 2 fully open platform trees build in coreboot www.coreboot.org (plus a payload like U-Boot http://www.denx.de/wiki/U-Boot with its I/O drivers) and EDK II http://www.tianocore.org/edk2/ on a community site.
There's no better way to teach developers about a topic than source trees, IMHO. I recall talking with a developer recently about SMM and Authenticated Variables. He had read https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf and kept asking follow-up questions. After seeing the EDK2 implementation https://downloadcenter.intel.com/download/23962/EDKII-Update-for-Intel-Quark-BSP and the PI SMM code therein he finally said "I get it."
And speaking of open source, glad to see posting of information like https://download.01.org/future-platform-configuration-hub/skylake/register-definitions/ to help enable open source firmware community development. Good stuff.
For this posting, though, I wanted to address the note above at the top of the blog regarding the plug fest presentation. The size comment was embedded in a broader point about "UEFI solves many problems for the IHV." It wasn't meant to be 'UEFI relative to something else', but more 'various embodiment options of UEFI.'
Specifically, the UEFI Driver Model has the concept of Bus drivers and Child device drivers. Common idioms are put into Bus Drivers, which today include USB, PCI, SCSI, Blue Tooth, etc. The bus drivers are typically stored in the system board ROM by the Original Equipment Manufacturer (OEM) so that the child device drivers built by the Independent Hardware Vendors (IHV's) only have to carry device specific code. The latter code is typically delivered as separate binaries in Host Bus Adapter (HBA) cards, such as PCI adapter, or embedded in the OEM system board firmware image.
I don't want to be viewed as a UEFI apologist or partisan in this posting, but I did want to clarify the context of the 'size' comment here. It was size in the sense of, if given N PCI device drivers, either duplicate logic from the bus driver is copied into each device driver instance (e.g., EFI1.02), or the EFI1.10+ (now UEFI2.5) driver model with the bus and device driver dichotomy of sharing code logic pushed into the bus driver.
Cheers
No comments:
Post a Comment