Option ROM Designs for UEFI SYS-006T Option ROM Designs for UEFI Tony Mangefeste Senior Program Manager Microsoft Corporation

Why UEFI? UX value prop from day one: fast boot, OEM certification, no backflash Secure Boot eDrive support for BitLocker Network unlock support for BitLocker System On Chip support Support for > 2.2 TB system disks Seamless Boot (UEFI Graphics) Boot Next support (UEFI Variable Services) Windows Deployment Services Multicast Value prop slide, add content

Optimizing for UEFI Redesign legacy Option ROMs into UEFI Option ROMs IHVs – deploy UEFI Option ROM support, manufacturing tools, and device drivers with UEFI support ODMs – provide service with updated toolsets, 64-bit environments, native factory tools with UEFI OEMs – secure your firmware, optimize for speed Consumer – look for newer UEFI-based platform firmware Talk to the point that this isn’t “new”, Microsoft’s been engaged with our ecosystem partners for xxx time… Move more towards the front…? (will investigate) Mark Doran to speak to the unity in message between Microsoft / Intel

How Microsoft is helping Option ROM Designers Microsoft offering a signing service through WinQual Free of charge to use to WinQual members Generating demand through direct partner engagement and customer awareness Engaging with IHVs on UEFI Option ROM adoption

Brian Richardson Senior Technical Marketing Engineer

UEFI: Key concepts Clean model without legacy PC limitations Consistent end-user interface for setup Designed to reduce OpROM code size Based on a widely adopted industry standard (over 180 member companies) Solves problems for BIOS, add-in card, & OS vendors

Changing Option ROM models The UEFI model keeps most PC concepts UEFI drivers can be embedded in BIOS or stay attached to the add-in device (OpROM) Driver/OpROM allows pre-OS configuration Changes to user experience and driver model Allows IHV to focus on driver functionality OEM can customize look & feel without the need for major changes by the IHV

UEFI driver & OpROM execution UEFI drivers and UEFI OpROMs will only be executed for devices in the boot path Different from legacy BIOS, where all OpROMs are executed on every boot Enables much faster boot time if the device is not required in the boot path (save init for OS) The OS driver can’t assume that the UEFI driver or OpROM has been executed

HII HII: Overview Localization Forms and strings Setup browser Input sources

HII: Key concepts Firmware and drivers publish forms to a central data store for pre-OS configuration OpROM forms describe device configuration System firmware uses a common setup UX is a function of the platform, not OpROM Drivers don’t carry their own UI (smaller code) OEM setup supports branding and different input methods (mouse, touch, or keyboard)

BIOS legacy setup comparison Too many function keys BIOS, OpROM #1, OpROM #2, … Too many menus Different menus for BIOS setup and OpROMs End user has problems finding the right menu No connection to the operating system Inconsistent interface causes problems for the end user

Compare to UEFI & Windows 8 Single key to enter BIOS setup menu Same key defined for all Windows 8 systems Single menu for BIOS, UEFI driver, and UEFI OpROM settings Easy for OEM support OS-specific boot entries, using UEFI variables UEFI allows consistency across PCs running Windows 8

How the OEM uses HII Platform branding Single setup menu Change input based on form factor (keyboard, mouse, touch) Microsoft Windows 8 logo requirements for BIOS setup keys

Changes for the IHV User setup is a function of the platform, not the add-in card. HII Lighter payload for the OpROM. Single interface for the user.

User setup is a function of the platform, not the add-in card. Changes for the IHV User setup is a function of the platform, not the add-in card. HII No direct access to UI from the OpROM. User interaction is triggered through HII.

Changes for the IHV OEM can change the look and feel without altering OpROM. HII Lighter payload for the OpROM. Single interface for the user.

Input handling is based on the platform, not the OpROM. Changes for the IHV Input handling is based on the platform, not the OpROM. HII Platform input may use keyboard, mouse, touch screen, or remote methods.

UEFI OpROM: Best practices The UEFI Driver Model has multiple benefits over legacy BIOS Option ROMs Removes legacy x86 hardware limitations Based on well-documented standards Decouples driver and OpROM from the UI Code to specification, not implementation Test against multiple UEFI implementations

UEFI OpROM: More best practices Understand the difference between UEFI HII and the OEM/IBV setup browser requirements Make sure drivers are written to HII from UEFI 2.1 specification or later Focus testing on UEFI Class 3 (no CSM) to eliminate any legacy dependencies

Relevant info from UEFI 2.3.1 spec 2.5.1 Legacy Option ROM Issues 10 Protocols –UEFI Driver Model 13.4.2 PCI Option ROMs 20 EFI Byte Code Virtual Machine 28 HII Overview 29 HII Protocols 30 HII Configuration Processing and Browser Protocol

Closing Remarks

Optimizing for UEFI Redesign legacy Option ROMs into UEFI Option ROMs IHVs – deploy UEFI Option ROM support, manufacturing tools, and device drivers with UEFI support ODMs – provide service with updated toolsets, 64-bit environments, native factory tools with UEFI OEMs – secure your firmware, optimize for speed Consumer – look for newer UEFI-based platform firmware Talk to the point that this isn’t “new”, Microsoft’s been engaged with our ecosystem partners for xxx time… Move more towards the front…? (will investigate) Mark Doran to speak to the unity in message between Microsoft / Intel

Call to Action Consider how your Option ROM designs will be coded and the performance impact Native Code? EBC (EFI Binary Code) How do you plan to install & execute your Option ROM? Servicing Option ROMs in the future Attend an Intel Training Event for more information about UEFI

Further reading and documentation Event Site: http://channel9.msdn.com/Events Resources: UEFI Forum Learning Center: http://www.uefi.org/learning_center/ UEFI IHV resources @ intel.com: http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/uefi-driver-and-application-tool-resources.html Review the UEFI specification (2.3.1) Review Windows Certification Requirements Use the TianoCore edk2-devel mailing list for support from other UEFI developers

For questions, please visit me in the Thank You! For questions, please visit me in the Speakers Connection area following this session.

1/13/2019 8:26 PM © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.