Tel : 69589584 同济大学软件学院 UEFI 与固件程序设计.

Slides:



Advertisements
Similar presentations
Basic Input Output System
Advertisements

Contiki A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff.
OS Fall ’ 02 Introduction Operating Systems Fall 2002.
Home: Phones OFF Please Unix Kernel Parminder Singh Kang Home:
OS Spring’03 Introduction Operating Systems Spring 2003.
1/28/2004CSCI 315 Operating Systems Design1 Operating System Structures & Processes Notice: The slides for this lecture have been largely based on those.
Figure 1.1 Interaction between applications and the operating system.
Operating Systems (CSCI2413) Lecture 3 Processes phones off (please)
OS Spring’04 Introduction Operating Systems Spring 2004.
Software Development and Software Loading in Embedded Systems.
Copyright Arshi Khan1 System Programming Instructor Arshi Khan.
What do operating systems do? manage processes manage memory and computer resources provide security features execute user programs make solving user.
I/O Tanenbaum, ch. 5 p. 329 – 427 Silberschatz, ch. 13 p
Joe Chen Sr. Manager, Insyde Software
Operating systems.
Operating Systems What do you have left on your computer after you strip away all of the games and application programs you bought and installed? Name.
Tel : 同济大学软件学院 UEFI 与固件程序设计.
Chapter 8 Windows Outline Programming Windows 2000 System structure Processes and threads in Windows 2000 Memory management The Windows 2000 file.
Protection and the Kernel: Mode, Space, and Context.
Session Agenda Designed to address BIOS Limitations Needed for the larger server platforms (Intel-HP Itanium) First called Intel Boot Initiative.
UEFI与固件程序设计 Tel: 同济大学软件学院.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 3: Operating Systems Computer Science: An Overview Tenth Edition.
Three fundamental concepts in computer security: Reference Monitors: An access control concept that refers to an abstract machine that mediates all accesses.
From UEFI Shell to Linux - UEFI Linux BootLoader Zhang Rui Software Engineer Sep 28 th 2011.
Architecture Support for OS CSCI 444/544 Operating Systems Fall 2008.
Contact Information Office: 225 Neville Hall Office Hours: Monday and Wednesday 12:00-1:00 and by appointment.
User Interface BDS and HII: Technical Overview
Tel : 同济大学软件学院 UEFI 与固件程序设计.
Recall: Three I/O Methods Synchronous: Wait for I/O operation to complete. Asynchronous: Post I/O request and switch to other work. DMA (Direct Memory.
Hardware Boot Sequence. Vocabulary BIOS = Basic Input Output System UEFI = Unified Extensible Firmware Interface POST= Power On Self Test BR = Boot Record.
Firmware Storage : Technical Overview Copyright © Intel Corporation Intel Corporation Software and Services Group.
Power onPlatform initialization Operating system (OS) boot Shutdown Run Time (RT) OS-Present Application Final OS Environment Final OS Boot Loader.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 7 OS System Structure.
Hardware process When the computer is powered up, it begins to execute fetch-execute cycle for the program that is stored in memory at the boot strap entry.
DMTF and UEFI A Partnership for Platform Manageability
Device Drivers CPU I/O Interface Device Driver DEVICECONTROL OPERATIONSDATA TRANSFER OPERATIONS Disk Seek to Sector, Track, Cyl. Seek Home Position.
Computers Operating System Essentials. Operating Systems PROGRAM HARDWARE OPERATING SYSTEM.
EEE440 Computer Architecture
1 CSE451 Architectural Supports for Operating Systems Autumn 2002 Gary Kimura Lecture #2 October 2, 2002.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 3: Process-Concept.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
System Components ● There are three main protected modules of the System  The Hardware Abstraction Layer ● A virtual machine to configure all devices.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
Hardware process When the computer is powered up, it begins to execute fetch-execute cycle for the program that is stored in memory at the boot strap entry.
Interrupt driven I/O Computer Organization and Assembly Language: Module 12.
1 Process Description and Control Chapter 3. 2 Process A program in execution An instance of a program running on a computer The entity that can be assigned.
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
Embedded Real-Time Systems Introduction to embedded software development Lecturer Department University.
2014 Redefining the Data Center: White-Box Networking Jennifer Casella October 9, 2014 #GHC
Big Picture Lab 4 Operating Systems C Andras Moritz
Chap. 4 ARM Boot Loader Internals. 2 S3C2500 ARM940T Core module ARM9TDMI CoreIC.
Overview A) Power on or reset B) 1st stage boot loader C) 2nd stage boot loader D) Operate system.
Introduction to Operating Systems Concepts
Muen Policy & Toolchain
Process Management Process Concept Why only the global variables?
From Zero to UEFI Shell Jason Jin Technical Marketing Engineer/ECG
Real-time Software Design
Lecture Topics: 11/1 General Operating System Concepts Processes
Operating Systems Lecture 3.
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
Operating Systems: A Modern Perspective, Chapter 6
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
Chapter 13: I/O Systems.
In Today’s Class.. General Kernel Responsibilities Kernel Organization
Chapter 3: Process Management
Chapter 13: I/O Systems “The two main jobs of a computer are I/O and [CPU] processing. In many cases, the main job is I/O, and the [CPU] processing is.
Presentation transcript:

Tel : 同济大学软件学院 UEFI 与固件程序设计

Agenda Overview DXE Core DXE Dispatcher DXE Architectural Protocol DXE Services DXE Drivers

Boot Flow Power on Security (SEC) [.. Platform initialization.. ] Pre EFI Initialization (PEI) Driver Execution Environment (DXE) Boot Dev Select (BDS) [.... OS boot.... ] Transient System Load (TSL) Shutdown After Life (AL) Run Time (RT) ? OS-Present App Final OS Environment Final OS Boot Loader OS-Absent App Transient OS Environment Transient OS Boot Loader Boot Manager CPU Init Chipset Init Board Init verify Device, Bus, or Service Driver Exposed Platform Interface Pre Verifier EFI Driver Dispatcher Intrinsic Services security DXE IPLDXE MAIN

Why DXE  No DXE –BIOS features coded in proprietary fashion  ODM has to port features from IBV to IBV  Third parties can not provide value added pre OS features –Single source file controls boot flow  With DXE –Works like OS, large group of companies can write drivers –Modular systems enabled  FLASH on a plug in module to support module

Properties of DXE Foundation  Depends only on HOB list –State initialization passed in from PEI  No hard coded addresses in DXE –Foundation code can be loaded anywhere  No hardware specifics in DXE Foundation –Access to hardware abstracted by a set of architectural protocols (APs) –APs implemented as drivers –Only DXE Foundation may call APs –APs encapsulate CPU, chipset, board specifics

DXE Components  DXE Core – The main DXE executable binary responsible for dispatching drivers and provide basic services.  DXE Driver – code loaded by the core to do various initializations, produce protocols and other services.  DXE Dispatcher – The part of the DXE core that searches for and executes the drivers in the correct order.  DXE Architectural Protocols – Produced by DXE drivers to abstract DXE from hardware.  UEFI System Table – Contains pointers to all the EFI service tables, configuration tables, handle database, and console device.

Agenda Overview DXE Core DXE Dispatcher DXE Architectural Protocol DXE Services DXE Drivers

DXE Core  No hard coded addresses allowed  Single Binary for each CPU Architecture  Well specified and validated  Written in C. No assembly allowed  Consumes  HOB List  Architectural Protocols  Produces  Dispatcher  EFI Boot Services  EFI Runtime Services

DXE Core Block Diagram

DXE Core Functional Blocks DXE Core EFI Boot ServicesDXE Services DXE Dispatcher Dependency Expression Evaluator Firmware Volume Driver Firmware Volume Block Driver (Read-Only) (Memory Mapped) Section Extraction Protocol Driver Decompress Driver PE/COFF Loader Flush Instruction Cache SetJump LongJump Switch Stacks Global Coherency Domain Services Dispatcher Services Task Priority Services Memory Services Event and Timer Services Protocol Handler Services Image Services Driver Support Services HOB Parser

DXE Core Data Structures System Configuration Table ACPI Table UEFI System Table UEFI Boot Services Table UEFI Runtime Services Table Variable Services Real Time Clock Services Reset Services Status Code Services Virtual Memory Services Task Priority Level Services Memory Services Event and Timer Services Protocol Handler Services Image Services Driver Support Services Global Coherency Domain Services SMBIOS Table … SAL System Table Input Console Active Consoles Output Console Standard Error Console Version Information UEFI Specification Version Firmware Vendor Firmware Revision Handle Database Protocol Interface Boot Services and Structures Only available prior to OS runtime Runtime Services and Structures Available before and during OS runtime DXE Services Table Dispatcher Services DXE Services Table HOB List

DXE Main  Responsible for Initializing DXE Core  Consumes HOB List  Builds EFI System Table  Builds EFI Boot Services Table  Builds EFI Runtime Services Table  Builds DXE Services Table  Makes Memory-Only Boot Services Available  Hands off control to the DXE Dispatcher  Requires access to Firmware Volumes  Requires LoadImage(), StartImage(), Exit()  May require decompression service

DXE Core Initialization  Initialize EFI Boot Services Table  Global Variable in DXE Core  All services return EFI_NOT_AVAILABLE_YET  Initialize DXE Services Table  Global Variable in DXE Core  All services return EFI_NOT_AVAILABLE_YET  Initialize Memory-Only TPL Services  RaiseTPL(), RestoreTPL()  Initialize Memory Services (Parses HOB List)  AllocatePages(), AllocatePool(), FreePages(), FreePool()  Allocate EFI System Table  Allocated from EfiRuntimeServicesData  Allocate EFI Runtime Service Table  Allocated from EfiRuntimeServicesData  All services return EFI_NOT_AVAILABLE_YET

DXE Core Initialization  Initialize GCD Services (Parses HOB List)  Initialize Driver Support Services  Initialize Event Services  Initialize Protocol Services  Initialize Miscellaneous Services  Add HOB List to System Configuration Table  Part of EFI System Table  Provides other component access to HOB List  Initialize Image Services  Creates Image Handle for DXE Core itself

DXE Core Initialization  Create event for each Architectural Protocol  Informs DXE Core when AP is installed  Used to complete EFI Boot Services  Used to complete EFI Runtime Services  Initialize Firmware Volume Drivers  Provides file access to FVs discovered by PEI  Initialize File Decompression (Optional)  Hand control to DXE Dispatcher

Agenda Overview DXE Core DXE Dispatcher DXE Architectural Protocol DXE Services DXE Drivers

Dispatcher Goals  Resolve Execution Ordering Among DXE Drivers  Drivers may be written by different organizations  Different divisions  Different companies  Support Known Business Issues  Emergency patches  “ Control of Destiny ” for  System developer  Add-in card developer  Driver developer  Expansion Hooks for e.g. Security

DXE Dispatcher Model  Some of each  A Priori list of drivers to be run first  Defined by system developers  May be null  Generally implemented as pre-load dispatch queue  Requirements based dispatching for the rest  General Concept: Driver provides a list of requirements that must be met before it can be dispatched.  A syntax that gets the ordering to about 90% is ok  EFI primitives exist to do finer granularity ordering

Requirements  Protocols are the “ Requirements ”  Represented by their GUIDs  The fundamental primitive is  “ Does this protocol exist? ”  Hits the 90% target  Driver may have to do RequestProtocolNotify for finer granularity  “ List of Requirements ” : Boolean Expressions  Operators: And, Or, Not (&, |, !)  Special operators: Before, After  Run this driver just before or just after that one  Used for patching  Internally, stored in driver header as Postfix (RPN) for quicker processing  Tool support planned

DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B C Driver Execution Environment

DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B C TRUE Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B C TRUE B C CPU_AP AND TIMER_AP FALSE Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B C TRUE B C CPU_AP AND TIMER_AP FALSE B 2 CPU Architectural Protocol Driver B Initializes Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B C TRUE B C CPU_AP AND TIMER_AP FALSE B 2 CPU Architectural Protocol Driver B Initializes CPU_AP TRUE Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B C TRUE B C CPU_AP AND TIMER_AP FALSE B 2 CPU Architectural Protocol CPU_AP TRUE A C CPU_AP AND TIMER_AP FALSE Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: CPU_AP Evaluates To: FALSE Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A TRUE CPU_AP AND TIMER_AP FALSE B 2 CPU Architectural Protocol CPU_AP TRUE C CPU_AP AND TIMER_AP FALSE A 3 Timer Architectural Protocol Driver A Initializes Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE DispatcherHandle Database Dependency Expression: Evaluates To: Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B 2 CPU Architectural Protocol C A 3 Timer Architectural Protocol Driver A Initializes CPU_AP AND TIMER_AP TRUE Driver Execution Environment

` DXE Foundation Dispatcher Loaded Image Protocol 1 Main Firmware Volume DXE Dispatcher Handle Database Dependency Expression: Evaluates To: Dependent: Scheduled: Initializing: Initialized: Driver B (CPU_AP) Driver A (Timer_AP) Driver C DXE Foundation A B B 2 CPU Architectural Protocol C A 3 Timer Architectural Protocol CPU_AP AND TIMER_AP TRUE C Driver C Initializes Execution Order Determined at Runtime Based on Dependencies Driver Execution Environment

Agenda Overview DXE Core DXE Dispatcher DXE Architectural Protocol DXE Services DXE Drivers

DXE – Architectural Protocols What are Architectural Protocols?  Low level protocols that support DXE APIs  Provide support for boot services and runtime services  Typically touch hardware  Only called by DXE core (directly)

DXE Core

DXE – Architectural Protocols  Boot Service APs  CPU – cache, interrupts, reset, timers  Metronome – periodic signals  Timer – event services  Boot Device Selection (BDS)  Watchdog Timer  Security  Runtime Service APs  Runtime – virtual addressing  Real Time Clock  Reset  Variable Services – nonvolatile storage access  Monotonic Counter  Status Code

DXE – Architectural Protocols  Some APs have dependencies on others.  Timer requires interrupts (CPU) and IO access  Watchdog timer requires timer and IO access  Reset requires CPU and IO access  Dependencies can be satisfied by using one or more of the following methods to control load order  Dependency grammar to have DXE load in the correct order  RegisterProtocolNotify() to be notified when required AP gets loaded  Apriori list – file in the file system containing list of filename GUIDs

DXE – Architectural Protocols Load Order CPU Timer Metronome Realtime Clock PCI I/O Abstraction Reset Watchdog Timer Variable Services Runtime Services BDS DXE CoreFDVP Status Code Security

DXE – Architectural Protocols  CPU APs  FlushDataCache()  EnableInterrupt()/DisableInterrupt()/GetInterruptState()  RaiseTPL() and RestoreTPL()  Init()  reset control  RegisterInterruptHandler()  Used by timer initialization  GetTimerValue()  SetMemoryAttributes()

DXE – Architectural Protocols  Watchdog Timer  RegisterHandler()  SetTimer()  GetTimer()  Boot Device Select (BDS)  Entry()  to hand off system to OS loader or system utility  Security  FileAuthenticationState()

DXE – Architectural Protocols  Real Time Clock APs  RT->GetTime()  RT->SetTime()  RT->GetWakeupTime()  RT->SetWakeupTime()  Reset APs  RT->ResetSystem() – for cold or warm system reset  Status Code  RT->ReportStatusCode()

Agenda Overview DXE Core DXE Dispatcher DXE Architectural Protocol DXE Services DXE Drivers

DXE Services  Dispatcher Services  Dispatch()  Schedule()  Trust()  Global Coherency Domain Services  Used to manage CPU visible memory resources  Used to manage CPU visible I/O resources

DXE GCD Services  GCD Memory Services  AddMemorySpace()  AllocateMemorySpace()  FreeMemorySpace()  RemoveMemorySpace()  GetMemorySpaceDescriptor()  SetMemorySpaceAttributes()  GetMemorySpaceMap()  GCD I/O Services  AddIoSpace()  AllocateIoSpace()  FreeIoSpace()  RemoveIoSpace()  GetIoSpaceDescriptor()  GetIoSpaceMap()

Agenda Overview DXE Core DXE Dispatcher DXE Architectural Protocol DXE Services DXE Drivers

 DXE drivers are DXE Components that  Initialize the platform  Provide the services required to  boot an UEFI-compliant operating system  Or  a set of UEFI-compliant system utilities.  DXE drivers may consume  UEFI Boot Services  UEFI Runtime Services  DXE Services

Classification of DXE Drivers  According to Functionality  Early DXE Drivers  DXE Drivers that follow the UEFI Driver Model  According to Life Cycle  Boot service drivers  Runtime drivers

Early DXE Drivers  Early DXE Drivers  Basic services  Processor initialization code  Chipset initialization code  Platform initialization code  DXE Architectural Protocols  Not all services are available  Execution order depends on dependency expressions  As much initialization should be deferred to DXE drivers that follow UEFI Driver Model

DXE Drivers that Follow the UEFI Driver Model  DXE Drivers that follow the UEFI Driver Model  Do not touch any hardware resources when they initialize  Register a Driver Binding Protocol interface  Ultimately provide software abstraction for console devices and boot devices  Do not need to be concerned with dependency expressions  Selected by BDS