1. From Zero to UEFI Shell Jason Jin Technical Marketing Engineer/ECG
Sep,

2. Agenda What is UEFI? How does UEFI firmware work? What is Intel® BLDK?
How Intel® BLDK address embedded challenges?

3. UEFI / PI Training Handout
March 31, 2010
What is UEFI?
Unified Extensible Firmware Interface
UEFI is an interface specification
Abstracts BIOS from OS
Decouples development
Compatible by design
Evolution, not revolution
Modular and extensible
OS-Neutral value add
Provide efficient Option ROM Replacement
Common source for multiple CPU architectures
Complements existing interfaces OS
Loader
Compatibility
UEFI
BIOS
Hardware
What is UEFI
It is based on the
Extensible Firmware Interface from Intel
The Unified Extensible Firmware Interface Specification (UEFI) is an outcome of the UEFI Forum, a non-profit collaborative trade organization formed to promote and manage the UEFI standard.
Compatible by design
Evolution, not revolution
The Major design points are that EFI needs
1. to work with ACPI as on legacy because there is a big investment in ACPI and we did not want to throw that away.
2. everything in UEFI booting to be backwards compatible
3 to not boot from the magic boot sector. We boot to the media which allows us to boot media CDs, Floppies, Hard drives that can boot both UEFI and IA32 at the same time.
You can even boot IA32, Itanium EFI, Xscale EFI and legacy BIOS all off the same boot media
UEFI is an Interface specification
Abstracts Platform from OS
The Specification was written from the perspective of lets
“Tell the OS what to do instead of having the OS tell the platform what to do.”
UEFI includes modular driver model and CPU-independent option ROMs
There are issues with option ROMs and 16bitness
There is a big push to go to something that will help in this arena
Modular and extensible
Intel and other companies have many initiatives. They continue to add features and functionality.
Intel wanted to make sure there was a clean way to add in interfaces.
And Intel worked to ensure that nothing like ACPI or SMBios are made obsolete.
This provides the flexibility to meet the current and future needs
UEFI is OS-Neutral value add
It complements existing interfaces
UEFI was designed to support backwards compatibility
_______________________________
Note: RAS = Reliability + Availability + Serviceability
UEFI / PI Overview

4. UEFI / PI Training Handout
March 31, 2010
UEFI Forum
The Unified EFI Forum is a non-profit collaborative trade organization formed to promote and manage the UEFI standard.
Board of Directors: AMD, AMI, Apple, Dell, HP, IBM, Insyde, Intel, Lenovo, Microsoft, Phoenix.
PC platforms worldwide shipment is more than 50% in 2010.
What is UEFI
It is based on the
Extensible Firmware Interface from Intel
The Unified Extensible Firmware Interface Specification (UEFI) is an outcome of the UEFI Forum, a non-profit collaborative trade organization formed to promote and manage the UEFI standard.
Compatible by design
Evolution, not revolution
The Major design points are that EFI needs
1. to work with ACPI as on legacy because there is a big investment in ACPI and we did not want to throw that away.
2. everything in UEFI booting to be backwards compatible
3 to not boot from the magic boot sector. We boot to the media which allows us to boot media CDs, Floppies, Hard drives that can boot both UEFI and IA32 at the same time.
You can even boot IA32, Itanium EFI, Xscale EFI and legacy BIOS all off the same boot media
UEFI is an Interface specification
Abstracts Platform from OS
The Specification was written from the perspective of lets
“Tell the OS what to do instead of having the OS tell the platform what to do.”
UEFI includes modular driver model and CPU-independent option ROMs
There are issues with option ROMs and 16bitness
There is a big push to go to something that will help in this arena
Modular and extensible
Intel and other companies have many initiatives. They continue to add features and functionality.
Intel wanted to make sure there was a clean way to add in interfaces.
And Intel worked to ensure that nothing like ACPI or SMBios are made obsolete.
This provides the flexibility to meet the current and future needs
UEFI is OS-Neutral value add
It complements existing interfaces
UEFI was designed to support backwards compatibility
_______________________________
Note: RAS = Reliability + Availability + Serviceability
UEFI / PI Overview

5. UEFI / PI Training Handout
March 31, 2010
UEFI Concept
OPERATING SYSTEM
Legacy OS LOADER
UEFI OS LOADER
UEFI API
UEFI BOOT SERVICES
UEFI
RUNTIME
SERVICES
Compatibility
UEFI or PI
Drivers
Driver
Driver
Memory
Timer
Boot
Devices
Protocols +
Handlers
(OTHER)
SMBIOS
ACPI
INTERFACES
FROM
OTHER
REQUIRED
SPECS
PLATFORM SPECIFIC FIRMWARE
PLATFORM HARDWARE
UEFI OS
Loader
UEFI SYSTEM
PARTITION
UEFI
Drivers
OS PARTITION
Motherboard
ROM/FLASH
Option
ROM
Option
ROM
Option
ROM
[NOTE: open up & condense (click text box)]
This slide illustrates the interactions of the various components a UEFI specification-compliant
system uses to accomplish platform and OS boot.
The platform firmware is able to retrieve the OS loader image from the System Partition.
The specification provides for a variety of mass storage device types including disk, CD-ROM, DVD and remote boot via a network.
Through the extensible protocol interfaces, it is possible to add other boot media types. These may require OS loader modifications if they require use of protocols other than those defined in this document.
Once started, the OS loader continues to boot the complete operating system. To do so, it may use
the EFI boot services and interfaces defined by this or other required specifications to survey, comprehend, and initialize the various platform components and the OS software that manages
them. EFI runtime services are also available to the OS loader during the boot phase.
The basic take away is that UEFI is actually an interface specification
{ENTER}
The platform firmware produces this set (point to the box below UEFI Boot Services)
The closet thing to legacy is the “Int” interfaces like Int 10 int 16 Int 13
In UEFI there are a set of defined interfaces like the UEFI OS Loader, pre boot applications
{point to OS loader}
There is also a new extensible mechanism to support option ROMs that will work across multiple processors
{point to Option ROM}
Regarding the framework: It is all about is you producing a system that has all of these UEFI interfaces
The UEFI Spec itself is just an API
How does one component talk to another
How does the OS loader talk to the platform
How does the Option ROM talk to the platform
How does the utility talk to the platform
That’s what UEFI is all about
This slide shows the principal components of UEFI and their relationship to platform hardware and OS software
This Slide illustrates the interactions of the various components of an UEFI specification-compliant system that are used to accomplish platform and OS boot.
The platform firmware is able to retrieve the OS loader image from the System Partition. The specification provides for a variety of mass storage device types including disk, CD-ROM, and DVD as well as remote boot via a network. Through the extensible protocol interfaces, it is possible to add other boot media types, although these may require OS loader modifications if they require use of protocols other than those defined in this document.
Once started, the OS loader continues to boot the complete operating system. To do so, it may use the EFI boot services and interfaces defined by this or other required specifications to survey,
UEFI Drivers
UEFI
Drivers
UEFI / PI Overview

6. Agenda What is UEFI? How does UEFI firmware work? What is Intel® BLDK?
How Intel® BLDK address embedded challenges?

7. Architecture Execution Flow
UEFI
Interface
Pre Verifier
OS-Absent App
CPU Init
Device, Bus, or Service Driver
Transient OS Environment
verify
Chipset Init
Board Init
Transient OS Boot Loader
EFI Driver Dispatcher
Boot Manager
OS-Present App
Intrinsic Services
Final OS Boot Loader
Final OS Environment ?
Summary to this point.
On the most basic level. Framework has these phases.
SEC is the security phase. This is the first phase after platform reset or power on to ensure that firmware integrity is intact. Not much goes on here so we will not spend a lot of time on it.
PEI stands for Pre-EFI Initialization Phase. It does what it says, pre-EFI initialization. It’s main purpose is to do minimal processor, chipset, and platform configuration for the purpose of discovering memory. It sets up the basic environment for the next phase. In fact, PEI code are gone when it moves on to the next phase. The only thing passed on to the next phase are the hoblists which describes the initialization done in the PEI phase.
DXE stands for driver execution phase. This is the phase where everything happens. Devices will be enumerated and initialized. EFI services will be supported and the protocols and the drivers will be implemented. This is where all the tables that make up the EFI interface will be created.
BDS stands for Boot Device Selection Phase and it is responsible for determining how and where you want to boot the OS.
Security (SEC)
Pre EFI
Initialization (PEI)
Driver Execution Environment (DXE)
Boot Dev
Select (BDS)
Transient System Load
(TSL)
Run Time
(RT)
After Life
(AL)
Power on
[ . . Platform initialization . . ]
[ OS boot ]
Shutdown

8. POST Execution Flow Normal Boot POST Boot Dev Dispatch Select Reset OS
Console
Init
Legacy OS
Load OS
Runtime
CPU Init
Device Init
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
Boot
Mode
Normal Boot
Flow of previous slide—what most BIOS do.
Use AMI BIOS example which has a Post Exec function to dispatch modules. The beginning code does the CPU init and starts out in the boot block
Framework can be thought of as execution and dispatching execution modules like other BIOS today. The Framework will still need to process the same and similar instillation similar to what is already done in today’s assembly 16 bit BIOSs. S3
Resume
Recovery

9. POST Execution Flow PEI Firmware Volumes Cache as RAM PEIM
Console
Init
Device Init
Bus Init
POST
Dispatch
Boot Dev
Select
EFI Pre-boot
Application
Legacy OS
Load OS
Runtime
POST
Dispatch
Boot Dev
Select
Reset
Console
Init
Legacy OS
Load OS
Runtime
Firmware
Volumes
CPU Init
Device Init
Cache as RAM
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
PEIM
Boot
Mode
Normal Boot
Handoff Blocks HOB
GUID
NVRAM
The PRE EFI Interface (PEI) foundation is the layer formally known as the Recover or Boot block section of a BIOS.
This phase is concerned about either Normal boot, S3, or Recovery, Just as in a legacy BIOS
The same functions and activities occur in this phase as any other BIOS, CPU init (CACHE init), Memory INIT, CS init.
With the Framework we also introduce new Terms PEIM, HOB, and GUID
PEIM – how a low level PEI communicates information between other PEIs
HOB – Data Structure for keeping track of resources
GUID – Identification mechanism S3
Resume
Capsules
Recovery

10. POST Execution Flow DXE EFI Driver Dispatcher EFI/DXE Drivers
Boot Dev
Select
EFI Pre-boot
Application
Legacy OS
Load OS
Runtime
Boot Dev
Select
EFI Driver
Dispatcher
Reset
CPU Init
Memory Init
CS Init
Boot
Mode
Recovery S3
Resume
Reset
Console
Init
Legacy OS
Load OS
Runtime
EFI/DXE Drivers
CPU Init
Device Init
EFI Boot Services
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
Boot
Mode
Normal Boot
Like most BIOSs have some sort of Post execution flow dispatcher, most are table driven), The Device execution environment (DXE) foundation that is the driver or kernel for dispatching and executing the different drivers and or modules. In addition to just dispatching code the DXE foundation will also determine if a module or driver will be executed based on dependency expressions evaluated at runtime. Other BIOSs do this during Build time.
The mechanics behind the Framework are the EFI Drivers and in the DXE foundation these drivers get more abstract to the hardware.
There are fundamental EFI Boot services that are used by DXE S3
Resume
Recovery

11. POST Execution Flow BDS Platform Policy EFI Boot Manager
Reset
CPU Init
Memory Init
CS Init
Boot
Mode
Recovery S3
Resume
Console
Init
Device Init
Bus Init
POST
Dispatch
POST
Dispatch
Boot Dev
Select
Reset
Platform Policy
Console
Init
Legacy OS
Load
EFI Pre-boot
Application
Legacy OS
Load OS
Runtime OS
Runtime
CPU Init
Device Init
EFI Boot Manager
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
Boot
Mode
Normal Boot
Normal Boot
Human Interface HII
Most legacy BIOS will have the feature BIOS Boot Spec (BBS) where the policy is to store a list of know boot devices and the last know boot device is know from successive boots. The framework has this same policy with the Boot Device Selection (BDS) except that the BBS is a subset of what the BDS can do as a feature.
The BDS is where Platform policy decisions will take action, and most customization is done here. S3
Resume
Recovery

12. Compatibility Support Module
POST Execution Flow
TSL
Reset
CPU Init
Memory Init
CS Init
Boot
Mode
Recovery S3
Resume
Console
Init
Device Init
Bus Init
POST
Dispatch
Boot Dev
Select
POST
Dispatch
Boot Dev
Select
Reset
Console
Init
Legacy OS
Load OS
Runtime
Compatibility Support Module
CSM
CPU Init
Device Init
EFI Pre-boot
Application
Memory Init
CS Init
Bus Init
EFI Preboot
Boot
Mode
Normal Boot
EFI Runtime Services
The goal of most BIOSs is to Boot to the OS. In the Framework there is also the ability to run in the Transient System Load phase. In this phase the boot manager with continue and has selected a EFI OS loader and will start running the EFI Compliant OS or if desired run an EFI application. S3
Resume
Recovery

13. Architecture Execution Flow
UEFI
Interface
Pre Verifier
OS-Absent App
CPU Init
Device, Bus, or Service Driver
Transient OS Environment
verify
Chipset Init
Board Init
Transient OS Boot Loader
EFI Driver Dispatcher
Boot Manager
OS-Present App
Intrinsic Services
Final OS Boot Loader
Final OS Environment ?
Summary to this point.
On the most basic level. Framework has these phases.
SEC is the security phase. This is the first phase after platform reset or power on to ensure that firmware integrity is intact. Not much goes on here so we will not spend a lot of time on it.
PEI stands for Pre-EFI Initialization Phase. It does what it says, pre-EFI initialization. It’s main purpose is to do minimal processor, chipset, and platform configuration for the purpose of discovering memory. It sets up the basic environment for the next phase. In fact, PEI code are gone when it moves on to the next phase. The only thing passed on to the next phase are the hoblists which describes the initialization done in the PEI phase.
DXE stands for driver execution phase. This is the phase where everything happens. Devices will be enumerated and initialized. EFI services will be supported and the protocols and the drivers will be implemented. This is where all the tables that make up the EFI interface will be created.
BDS stands for Boot Device Selection Phase and it is responsible for determining how and where you want to boot the OS.
Security (SEC)
Pre EFI
Initialization (PEI)
Driver Execution Environment (DXE)
Boot Dev
Select (BDS)
Transient System Load
(TSL)
Run Time
(RT)
After Life
(AL)
Power on
[ . . Platform initialization . . ]
[ OS boot ]
Shutdown

14. Boot Sequence High Level

15. Agenda What is UEFI? How does UEFI firmware work? What is Intel® BLDK?
How Intel® BLDK address embedded challenges?

16. Intel® Boot Loader Development Kit
Intel® UDK2010
Source code
Intel® BLDK firmware package
Intel® BLDK GUI
Platform BSF
Intel® BLDK
source code
CPU and Chipset
Bnianry
Bootloader
Binary
User
Doc
[Drew]

17. Intel® BLDK GUI
Intel® BLDK Development Application is used to build and customize target boot loader images.
Main Features
Graphical User Interface (GUI)
Project driven
Build environment
Binary configuration
Enable/Disable FW features
Configure feature settings
Source code editor with syntax
highlighting
Menu & Toolbar
Main Window
Output Window
Help Window
Navigation Pane
[Cris]

18. Intel® BLDK firmware package
Code Base Build Tree
Package concept for each directory
Platform is contained in a package
Operating System
Build machine runs Microsoft* Windows XP* with SP3
Compiler Tool Chains
iASL
Microsoft* Visual Studio .NET Team Suite Edition
Microsoft* Windows Server DDK version
Platform related packages
[Cris]
*Other names and brands may be claimed as the property of others.

19. Agenda What is UEFI? How does UEFI firmware work? What is Intel® BLDK?
How Intel® BLDK address embedded challenges?

20. Embedded Device Boot loader Challenges
Configurability
(Device in Diversity)
Performance
(Speed is everything)
Closed Source
(Limits accessibility)
Debuggability
(Reduces TTM)
Challenges
Let’s find a real UEFI logo……..either that or gotta clean this one up 20
Intel® UEFI Development Kit 2010 (Intel® UDK2010)

21. Binary Configurability
Intel® BLDK offers a way to configure firmware settings by patching binary without rebuilding.
Intel BLDK has hundreds of feature setting options.
Intel BLDK Development Application makes the patching process easy.
[Cris]
There will be a demo in the next section.
Intel® BLDK: Intel® Boot Loader Development Kit

22. Closed Source Limited access to certain source material
Traditionally, closed source code and distribution restrictions in a Boot Loader has made distribution to a wide audience a challenge.
forwards
user to a Source Forge repository
UEFI introduces a large amount of open source, >80%
Relatively small portion remains
With source & distribution restrictions 22

23. FLASH Closed Source SIO MRC PCI USB
By extending the configurability of binary components, we can enable much broader usage.
Configure?
SIO
MRC
PCI
USB
FLASH Map
UEFI Boot Loader in FLASH block
Binary image manipulation removes source restriction hurdles so a large variety of clients can use solution
Binary Patchable Element
FLASH
Restricted Files without source
File with open source reference 23

24. Boot Performance Make good use of system cache
Avoid initializing unnecessary devices
Organize the FLASH layout effectively
Use saved data during boot time
Whitepaper: “Reducing Platform Boot Time” (

25. Debuggability Software-only debugger solution
New Intel® UEFI Development Kit Debugger Tool available
Provides ability to debug target without need for exposed JTAG
Leverage various debug ports
Supports WinDbg as a front-end
Few differences between this solution and a high-end HW-based debugger
To break into target, SEC startup code must have established a stack.
Typically a few dozen instructions from the reset vector.
This is also true of first few dozen instructions in SMI entry.
Some Processor mode transitions are difficult to debug.
UEFI-based open source debugger solutions available 25