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

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

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

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

6. Brian Richardson Senior Technical Marketing Engineer

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

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

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

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

11. 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)

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

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

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

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

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

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

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

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

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

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

22. Closing Remarks

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

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

25. Further reading and documentation
Event Site:
Resources:
UEFI Forum Learning Center:
UEFI IHV intel.com:
Review the UEFI specification (2.3.1)
Review Windows Certification Requirements
Use the TianoCore edk2-devel mailing list for support from other UEFI developers

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

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