1 / 27

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

scott
Download Presentation

Option ROM Designs for UEFI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SYS-006T Option ROM Designs forUEFI Tony Mangefeste Senior Program Manager Microsoft Corporation

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

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

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

  5. Brian RichardsonSenior Technical Marketing Engineer

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

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

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

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

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

  11. BIOS legacy setup comparison • Too many function keys • BIOS, OpROM #1, OpROM #2, … • Too many menus • Different menus forBIOS 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

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

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

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

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

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

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

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

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

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

  21. Closing Remarks

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

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

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

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

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

More Related