TW04023 WINHEC2004

Implementing EFI On 32-Bit Systems: 

Implementing EFI On 32-Bit Systems Tony Pierce Technical Evangelist Windows Industry Engagement Tonypi @ microsoft.com Microsoft Corporation

Session Outline: 

Session Outline The Intel Platform Innovation Framework for EFI Phoenix Technologies EFI Implementation Plans

The Intel® Platform Innovation Framework For EFI*Mark Doran Senior Principal Engineer, Intel Corporationmark.doran @ intel.com: 

The Intel® Platform Innovation Framework For EFI* Mark Doran Senior Principal Engineer, Intel Corporation mark.doran @ intel.com

Agenda: 

Agenda What system vendors, board vendors, and BIOS engineers need to know about the Framework High level architectural view Demo How system vendors, board vendors and BIOS engineers can get and learn about the Framework Business model When system vendors, board vendors and BIOS engineers need to deploy the Framework Board and system products from Intel Platform enabling from Intel divisions

Goals: 

Goals Understand how BIOS is being replaced, and why it’s about time How Intel, you and your BIOS vendor can work together to make this a smooth transition

Intel® Platform Innovation Framework For EFI: 

EFI OS Loader EFI OS Loader Intel® Platform Innovation Framework For EFI legacy OS Loader legacy OS Loader Hardware Hardware Pre-EFI Modules Hardware Specific Compatibility Support Module Platform Drivers EFI Drivers PEI Foundation DXE Foundation Compatibility Support Module Pre-EFI Foundation Hardware-specific pre-EFI modules DXE Foundation Framework Drivers Hardware specific drivers and implementations of Architectural Protocols Platform Drivers EFI Drivers for adding value to the platform Compatibility Support Module (IA32 only) Framework Drivers EFI Drivers Pre-EFI Initiialization (PEI) Foundations legacy Option ROMs legacy Option ROMs Driver Execution Environment Architectural Protocols Platform Drivers

Framework Implementation Properties: 

Framework Implementation Properties Uses standard MS tools to develop and debug Modular, modern GUID-based, complete relocatabilty Device independent storage and loading Pre-boot RAM >> 1MB; control how RAM is allocated Drop-in processor/chipset modules for silicon Drive PC components into new market segments with less legacy Complete image builds from ~650K lines of source code Functionally complete equivalent to traditional BIOS Running on IA-32, Itanium® processor family and Intel XScale® technology Non-BIOS code + CSM meets size and speed goals Combined image fits in 4Mbit part Boot speed with legacy shrink-wrap OS meets existing HDG standards Resume speeds meeting HDG standards

Framework is Longhorn-ready: 

Framework is Longhorn-ready Intel desktop board with Framework ready for Longhorn via EFI. Flash includes AMI Compatibility Support module for booting legacy and POSTing legacy option ROMs. Gateway Media Center 600, shipping with Insyde’s implementation of the Framework boots Windows XP Other systems running the Framework demonstrating portability of code base Xeon® Processor Family Itanium® Processor Family Intel XScale® Technology

Framework Business Objectives: 

Framework Business Objectives Increase velocity of features delivered in silicon Improve the environment for platform innovation and differentiation for our customers Encourage adoption across the industry Enable interoperability of SW components from multiple suppliers *Other names and brands may be claimed as the property of others

BIOS Companies Supply The Framework: 

BIOS Companies Supply The Framework Framework, Framework Driver, and Sample Driver source code licensed by Intel to Independent BIOS Vendors (IBVs) IBVs create royalty-bearing products based on the Framework Not generally available outside of this model Intel systems groups working with IBVs to create firmware solutions that will be shipped on Intel boards and systems Licensing terms to IBVs Same for applications on Intel and non-Intel silicon IBVs can sublicense Intel source for customization and supportability Some restrictions on source modifications to ensure continued interoperability Intel-specific drivers also available through BIOS vendors

Intel Moving To The Framework: 

Intel Moving To The Framework Intel a major consumer of “BIOS” technology Product research, pre-silicon validation, silicon power on, platform enabling, board-level products One of the industry’s largest “BIOS” teams New CPU and chipset projects are using the Framework The first project to use it 100% began in 2002, and has now completed power-on Many more Si projects are in the pipeline While Intel will continue old-style BIOS enabling, more and more products will have “maximum mileage” on the Framework code base when they are introduced The Framework isn’t just the best EFI implementation, it’s poised to become the preferred way of enabling new Si

Intel Adoption Roadmap: 

All SKUs use Framework Expanded Support Full Support All CRBs ship with Framework All SKUs use BIOS One SKU use Framework All CRBs Ship with BIOS Limited Support Intel Board Products Intel Chipset Products *Refers to chipsets that are designed into OEM products during the indicated year All products, dates and figures are preliminary, for planning purposes and subject to change without notice Multiple SKUs use Framework Some EFI SKUs Intel Desktop Board Products Intel Enterprise Board Products Intel Mobile Customer Reference Boards Intel Desktop Chipsets* Intel Mobile Chipsets* Intel Enterprise Chipsets* Most SKUs use Framework All CRBs ship with BIOS Limited Support Full Support All SKUs use Framework All SKUs use Framework All CRBs ship with Framework Intel Adoption Roadmap

Call To Action: 

Call To Action Roadmap for PC makers 2004: learn/try, 2005: ship, 2006: convert Talk to your BIOS Vendor Create a migration plan that fits your company’s needs If your vendor isn’t a participant, encourage them to come on board! Intel Innovation Alliance members: mark your calendars! 3 day focused training in Taipei in 2H of June Hosted by AMI, Insyde, Intel

Resources: 

Resources Email http://www.intel.com/technology/framework/feedback_gen.htm Web Resources Specs http://www.intel.com/technology/framework/spec.htm Whitepapers http://www.intel.com/technology/framework/overview1.htm http://www.intel.com/update/contents/it01043.htm Other Resources http://www.insydeh2o.com http://www.ami.com/news/pressshow.cfm?PrID=146

The Phoenix Technologies EFI Implementation PlansTim LewisFirmware Architect, Phoenix Technologies: 

The Phoenix Technologies EFI Implementation Plans Tim Lewis Firmware Architect, Phoenix Technologies

Session Outline: 

Session Outline Firmware: The Promise, the Pain and the Plan Firmware Transition – Managing Risks Transferring Value to 32-bit Systems

Session Goals: 

Session Goals Attendees should leave this session with the following A better understanding of emerging firmware standards System firmware issues and the relationship to EFI Understanding how advanced tools help customers implement next generation firmware Microsoft/My team/I will benefit from this session in the following ways Understand the value of firmware to OEMs Understand the timeline for EFI

Phoenix Position: 

Phoenix Position We like EFI, but… All 32-bit implementations will need thorough validation cycle Implementations derived from other CPU architectures don’t fit well in the 32-bit environment We believe collaborative standards are the best approach Minimize risk and cost during the transition Maintain choice and opportunity for the OEM and ODM We believe we have a less disruptive approach to EFI, which will provide OEMs and ODMs with maximum choice and differentiation opportunities

EFI: The Pain And The Promise: 

EFI: The Pain And The Promise EFI Promise Enhanced Boot Loader & Partition Table Standardized Extensibility Model EFI Pain How will Current Value Transfer To EFI 32-bit – Or is it Throwaway? Transition Risks and Costs The Phoenix Plan Longhorn Supports Future Industry Move To EFI-Booted OS Both EFI and legacy boot methods supported in Longhorn timeframe Allows side-by-side Development

EFI: One Of Many Firmware/OS Interfaces: 

EFI: One Of Many Firmware/OS Interfaces Provided by: Industry Standard OS Silicon Firmware CPU & Chipset System Firmware EFI OS Current Interfaces ACPI 3.0 SMBIOS Value-add Hardware Plug-In

Firmware Transition – Managing Risks: 

Firmware Transition – Managing Risks

Firmware Key Points: 

Firmware Key Points Firmware layer must support Silicon and silicon revisions from multiple vendors Phoenix supports >240 memory controllers by 45 manufacturers Multiple operating systems and revisions Compatibility with the broadest range of add-in devices possible Features such as branding, disaster recovery, platform security, provisioning and system configuration that are OS agnostic Firmware is mission-critical to hardware manufacturers Time to Market = Time to Revenue Extensive existing platform investments – production, customer support, etc. System OEMs use firmware to differentiate their products Margins are razor thin…transitions mean cost & risk

Example: Notebook Innovation (By % Source File): 

Example: Notebook Innovation (By % Source File)

The Value Of Firmware: Compatibility: 

The Value Of Firmware: Compatibility In the High-Volume PC Market, Transition Means Cost and Risk Examples Some Large Customers Require DOS/Win98/NT3.51 Support Compatibility Means Newer Hardware Without New Software Cost Compatibility Means Lasting Investment Value Compatibility Allows Built-Up Expertise For Engineers Compatibility Is Accrued Not Designed Accumulated Industry Specifications and their Versions Interactions Between OS/Apps and the Firmware Differences Between Firmware Vendors Reliance On Implementation Behavior Every Live Specification Generates Compatibility Issues! Compatibility Works Best By Extension…not Replacement

Transitioning Value To Next-Generation Firmware: 

Transitioning Value To Next-Generation Firmware

Transitioning Value By Functional Blocks: 

Transitioning Value By Functional Blocks Extension of 32-bit Systems to Add EFI Must Maintain Compatibility, Innovation & Cost Control EFI & Current Services Should Sit As a Layer Attached to Same Underlying Operating Environment Otherwise feature support requires two separate efforts Strategy Allows Each Functional Block To Transition Separately Services are transitioned gradually, so that cost/risk is mitigated Transition of Each Block Requires Four Stages Stage 1: EFI Services Thunk Down To Use Existing Legacy Interfaces Stage 2: Legacy Interface Thunks Up To Use New Interface, But Individual Devices Thunk Down To Legacy Code Stage 3: Devices Move Over To New Model, Removing The Thunk Down Stage 4: Legacy Can Be Removed

How A Feature Is Transitioned: Stage 1: 

How A Feature Is Transitioned: Stage 1

How A Feature Is Transitioned: Stage 2: 

How A Feature Is Transitioned: Stage 2

How A Feature Is Transitioned: Stage 3: 

How A Feature Is Transitioned: Stage 3

How A Feature Is Transitioned: Stage 4: 

How A Feature Is Transitioned: Stage 4

Transitioning Value Using Integration With Existing Firmware: 

Transitioning Value Using Integration With Existing Firmware Transition via Integration with Current Firmware is Easier and Takes Less Storage Space EFI & Current Services Can Use Existing Infrastructure (examples) String/Font Pooling for Multiple Language Support Ex: ~700 Messages, ~60KB string/font for four languages (2 Asian) Ex: ~700 Messages, ~10KB string/font for English-only Shared Memory Allocator (not one for EFI & one for firmware) Shared Non-Volatile Storage Allocation User Transparency Essential EFI & Non-EFI OS Must Boot Without User Having To Know

The Value Of Using Advanced Tools: 

The Value Of Using Advanced Tools Advanced Tools Put EFI & Firmware In Same Environment Baseline platform for Phoenix firmware build environment is Microsoft Visual Studio .NET Microsoft Visual C++ Compiler Produces Tightest Object Code In our study, 18-25% Larger Than Hand-Written Assembly Next: Watcom & Digital Mars, GCC a distant 4th Custom Phoenix Tools Shrink Size Of Built-In Executables For Small Modules, Over 30% Of EXE Size Is Wasted Extensions Allow Static Declaration Of Protocols, NV Requirements, Strings, Bitmaps Phoenix Editor Allows Editing Of Modules As Binaries

CoreArchitect Screen Shot: 

CoreArchitect Screen Shot

Summary: 

Summary Non-disruptive Innovation is the Preferred Path to new Standards Lowest cost Lowest risk Maximize customer choice Maximize OEM/ODM Differentiation Opportunities Phoenix’s Chosen Solution Target date for our solution is to have an early implementation to align with Longhorn beta