1. Advanced Porting The Framework
Intel Corporation
Software and Services Group

2. Agenda Create a New Platform Build
Minimal porting job to run EFI Shell
Platform specific porting features

3. Create a New Project Directory
New Platform Build
Create a New Project Directory
Identify the Platform that this Project is a part of, PROJECT_PLATFORM. Platforms are usually closely tied to a processor/north bridge/south bridge combination.
Choose a Project name, PROJECT_NAME. This is often defined in the PlatformTools.env. Currently we are describing Bearlake as an example project name.
Choose a Project family, PROJECT_FAMILY. This is often defined in the PlatformTools.env.
The Platform\PROJECT_FAMILY\
PROJECT_PLATFORM directory to Platform\PROJECT_FAMILY \PROJECT_NAME. In the case of the Bearlake example platform, the source directory to copy is Platform\IntelDpg\PROJECT_PLATFORM.

4. The Framework Directory Tree 8.x code base
Application
Bus
Chipset
Lakeport - MemoryInit
Blackford - MemoryInit
ESB2
IntelIch ICHX SmBus
SMC
CPU
CSM
GUID
Include
Library
Platform
IntelDpg – Lakeport Pei – Dxe - Platform
IntelEsg – StarLake Pei – Dxe - Platform
IntelSSG
Lakeport - Build
Ppi
Protocol
Tools
The Framework Directory Tree 8.x code base
Bearlake
ICHX
Bearlake
Bearlake

5. Agenda Create a New Platform Build
Minimal porting job to run EFI Shell
Platform specific porting features
\$(PLATFORM_SOUTH_PATH) for LAKEPORT is \IntelDpg\Lakeport

6. General Overview SEC PEI DXE BDS OS PWR ON SECurity
Pre-Efi Initialization
Driver Xecution Environment
Boot Device Selection

7. Device, Bus, or Service Driver
Boot Flow
Exposed
Platform 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 ?
security
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.
The Operational model from reset and represents the boot flow.
1. This slide will describe the pieces needed to boot to an OS and here is the time line that it represents
2. In the beginning will be the SEC Pre Verifier section. This section will establish security by verifying the processor and Flash. There are several different models established today between MS and Intel for instance LaGrand. There is a pre verifier spec. Signatures are checked
SEC allows for support of inspection of the very first op-code that will be executed on the system to ensure that the chosen platform firmware image is not corrupted
the first task of the design is to find an initialize memory for use as stack to enable C code to be started as close to the reset vector as is practical on any given system
3. Next the PEI runs to initialize the CPU and Chipset and Board init to get to the point of some minimal amount of memory and chipset initialized enough to execute out of flash.
PreEFI Initialization Environment (PEI) represents the smallest amount of code possible that is able to find and initialize memory and other resources needed to switch execution into C language code
4. Once memory is discovered, PEI marshals a set of handoff state information describing the platform resource map and then initializes and jumps to the DXE
PEI-to-DXE handoff is a one way transition ‑ once the initial program loader for DXE is complete the PEI code is no longer available for use on the platform and DXE becomes a self-contained operating environment.
At this point the DXE driver starts to dispatch the EFI drivers in the system. This section is where the EFI 1.10 drivers will be dispatched to establish the console (see something) and establish the boot device whether it is the LAN or the Hard drive or Floppy or CD ROM.
6. Then the Framework version of the boot manager is established. The Boot Device Select or BDS. This is a newer version of the boot manager that exist in Framework that takes care of the different modes of booting. Also the phase for adding personalities
7. Device Bus, or Service driver - The boot manager depending on the boot path, may require the system to go back and dispatch some more EFI drivers if more are required to be defined.
As these drivers get loaded there maybe more drivers hidden behind some devices like out on the hard drive. For instance if the Hard drive driver is loaded the BDS will check for dependencies and may go back to the DXE to load more EFI 1.10 drivers enough to boot the operating system.
There exists another exposed Specification between the BDS and the DXE.
8. At the Transient System Load the boot manager with continue and has selected a EFI OS loader and will start running the EFI Compliant OS. This phase includes provisions for service interfaces to be available to operating system loaders prior to the platform being taken over completely by the operating system kernel
After the Final EFI OS loader for an operating system comes up then it will transfer control will go to the Final OS environment or Runtime stage. At that point in time then Framework will disappear from the system just as EFI 1.10 would be gone after OS boots.
There are some Runtime services that exist. For instance Runtime monitoring. It does not currently exist in Framework but may in the future.
Linix does have a OS runtime environment for the UGA. Get mode / set mode are available to to the OS. It requires an OS VM to EFI to be inside the system.
11. After life concept is for recovery. For instance if the system crashes dropping back to a known good copy of EFI / Framework. Not part of the spec currently.
12. Finally perhaps as part of the After life there is a system reset where the whole cycle will restart.
Technology issues:
BIOS Technology antiquated ans is in the criticcal path for product release
- Interfaces designed for MHz PC
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. System Block Diagram
Loader
legacy OS
Hardware
Pre-EFI Modules
Hardware Specific
Compatibility Support Module
EFI OS Loader
Drivers
Platform
EFI
Architectural Protocols
PEI Foundation
DXE Foundation
Framework Drivers
Pre-EFI Initiialization (PEI)
Foundations
legacy Option ROMs
Driver Execution Environment
Here we have a system generic block diagram of a typical Intel chipset platform.
The framework is very module in nature and thus porting the framework from platform to platform is fairly simple because of this. You will be able to re-use much of your code from say a desktop port to a notebook or a server. Even if there are differences in the chipsets on the platforms.

9. The Framework Directory Tree 8.x code base
Application
Bus
Chipset
BearLake - MemoryInit
Blackford - MemoryInit
ESB2
IntelIch ICHX SmBus
SMC
CPU
CSM
GUID
Include
Library
Platform
IntelDpg – Bearlake Pei – Dxe - Platform
IntelEsg – StarLake Pei – Dxe - Platform
IntelSSG
Bearlake - Build
StarLake - Build
Ppi
Protocol
Tools
The Framework Directory Tree 8.x code base

10. Porting SEC Reset Fetches Code from FLASH SEC Enables Temp Memory
Minimal porting job to run EFI Shell
Porting SEC
Reset Fetches Code from FLASH
Enables Flat Protected Mode Execution
SEC Enables Temp Memory
Data and Stack Cached
Enables Execution of C Code
Transfers Control to PEI Foundation
Looking at the SEC now.
What this practically means is that SEC can have many layers: - Save BIST information (optional) - Transition to 32-bit flat mode (IA32) - Bsp selection ON multiple FSB. (On server platform)
- Disable shadowing
- Start AP on hyper-threading
- Enable cache-as-RAM - Convert Warm to cold start (some IA32 optionally) - Create PPI list for PEI (optional) - Issue TPM_Start and issue first hash-extend (Optional) - Create PEI Hand-off state - Push embedded boot-firmware volume address on stack - Call into PEI Core entry point
This is the first piece of code that gets executed on the platform. It’s basic purpose is to enable the cache for temporary memory and switch the processor in the case of IA32 from 16 bit mode to 32 bit mode. Other things like MTRR programming and APIC setup is done in the SEC. This is assembly language code.
Once this is done, control is transferred to PEI.

11. Temporary Memory 0xFFFF_FFFF System ROM (16 MB) 0x0000_0000
Minimal porting job to run EFI Shell
Temporary Memory
0xFFFF_FFFF
System ROM (16 MB)
0x0000_0000
0xFF00_0000
0xFEC0_0000
0xZZZ0_0000
0xYYY0_0000
Low Top Of Memory
0xFEF0_0000
0xFEE0_0000
0xFED0_0000
System FLASH (512 KB)
0xFFF8_0000
SEC Maps Unused
Region as Temporary
Memory
Temp Memory
Local APIC
I/O APIC
PCI Resources
System Memory
Framework Code
and Data Stored Here
Here is the temporary memory map created by SEC. The SEC uses memory at FEF0_0000 as it’s temporary memory until main memory is found.
As mentioned a temporary memory map is created by SEC to provide stack and local variable data storage. The SEC uses the processor’s cache in Non-Eviction Mode (NEM) and maps the cache at FEF0_0000 as temporary memory until main memory is found. Note this address is just below the system FLASH device. This slide shows this memory map. Note that the map shows a 512KB FLASH part, space is reserved in the map to accommodate a 1024KB FLASH part also

12. SEC phase Currently SEC phase is where the Reset vector will start
Minimal porting job to run EFI Shell
SEC phase
Currently SEC phase is where the Reset vector will start
\Platform\$(PLATFORM_SOUTH_PATH)\Common\Sec\Ia32\ResetVec.asm
\Platform\$(PLATFORM_SOUTH_PATH)\Common\Sec\Ia32\Flat32.asm
For any port work having the schematic as you know is required.
From the schematic we get information about where the GPIO’s are, how the PCI routing is done on the board, what bus is the flash on and what is connected to the SMBUS

13. PEI Phase The PEI phase’s purpose is to: Determine the boot mode
Minimal porting job to run EFI Shell
PEI Phase
The PEI phase’s purpose is to:
Determine the boot mode
Perform low-level initialization of the platform
Discover and initialization main memory
Invoke recovery if desired
Transfer control to DXE or S3 waking vector

14. PEI Phase Overall Initialization
Minimal porting job to run EFI Shell
PEI Phase Overall Initialization
Two PEIMs contain the majority of the platform’s initialization code :
Platform\$(SOUTH_PLATFORM_PATH)\Pei\Platform\Stage1
Platform\$(SOUTH_PLATFORM_PATH)\Pei\Platform\Stage2
The Platform Stage1 PEIM module does the platform initialization according to platform policy or board layout. Stage1 focuses on ICH related platform initialization, such as ICH GPIO initialize, since GPIO usage and initialize value is according to board layout design.
The Platform Stage2 PEIM module does the platform initialization according to platform policy or board layout. Platform Stage2 focuses on MCH related platform initialization, such as onboard Graphics enable/disable.

15. Platform Specifics in Platform.h
Minimal porting job to run EFI Shell
Platform Specifics in Platform.h
\Platform\$(PLATFORM_SOUTH_PATH)\Common\Pei\Platform\Platform.h
Memory DIMM SMBUS address
Firmware Hub GPIO base address and recovery jumper number
ICH ACPI base address, ICH GPIO base address, SIO base address, ICH RCBA base address
Early resource address such as AC97 audio memory mapped IO base address, ICH SMBUS base address, ICH IDE base address.
ICH GPIO mappings
PEI memory usage
ICH ACPI timer related settings such as resolution, address, and max value.
Based on the new platform settings following items should be considered:
Memory DIMM SMBUS address
Firmware Hub GPIO base address and recovery jumper number
ICH ACPI base address, ICH GPIO base address, SIO base address, ICH RCBA base address
Early resource address such as AC97 audio memory mapped IO base address, ICH SMBUS base address, ICH IDE base address.
ICH GPIO mappings
PEI memory usage
ICH ACPI timer related settings such as resolution, address, and max value.
Even though this file is defined under PEI folder in the platform specified directory and there are many functions definition used in PEI phase, actually it is recommended that this file is defined under platform\include folder and only includes the platform specific constant definition so it can be included by all the platform drivers no matter the PEI or DXE driver phase

16. GPIO Initialization PEIM for ICH GPIO initialization
Minimal porting job to run EFI Shell
GPIO Initialization
PEIM for ICH GPIO initialization
Table - mIchGpioInitTable
Register OFFSET
Value
GPIO_USE_SEL
0x1F3DF7C1
GPIO_IO_SEL
0xE6FFFFFF
GPIO_INV
0x0000A000
GPIO_IO_SEL2
0x000000FF
GPIO initialization is done in the PEI stage during the chipset initialization in the file IchInit.c
The GPIO pins programming is defined in the GPIO init table. GPIO pins are used for many functions – power, recovery jumper, hard disks, wi-fi, fans and etc. This table allows you to define the register offset and value that is needed to program the GPIO’s.
You can set them up for input/output/tri-state, set the high/low values
GPIO_USE_SEL – which GPIO’s to program
GPIO_IO_SEL – which direction
GPIO_INV – switch High/Low state(setting)

17. Minimal porting job to run EFI Shell
Code Example
FILE: Platform\ \$(PLATFORM_SOUTH_PATH)\ Common\Pei\Platform\Stage1\IchInit.c
static const ICH_GPIO_DEV mIchGpioInitTable [] = {
// Register OFFSET,Value
// 0/1 - Native function/GPIO
GPIO_USE_SEL, GPIO_USE_SEL_VAL,
GPIO_USE_SEL2, GPIO_USE_SEL2_VAL,
// 0/1 - Output/Input
GPIO_IO_SEL, GPIO_IO_SEL_VAL,
GPIO_IO_SEL2, GPIO_IO_SEL2_VAL,
// 0/1 - Active High/Low
GPIO_INV, GPIO_INV_VAL };

18. Minimal porting job to run EFI Shell
GPIO Values
The table allows you to define the register offset and value that is needed to program the GPIO’s. You can set them up for input/output/tri-state and set the high/low values using the following defines:
GPIO_USE_SEL – which GPIO’s to program
GPIO_IO_SEL – which direction
GPIO_INV – switch High/Low state(setting)
These values – GPIO_USE_SEL, GPIO_IO_SEL, and GPIO_INV are defined in the file:
\Platform\$(PLATFORM_SOUTH_PATH)\Common\Pei\Platform\Platform.h

19. ICH Initialization Power-on ICH initialization is performed in PEI to:
Minimal porting job to run EFI Shell
ICH Initialization
Power-on ICH initialization is performed in PEI to:
Initialize the system buses (LPC, PCI, SMBUS)
Turn-off the watchdog timer
Program the interrupt pins
Other miscellaneous chipset initialization needed prior to memory detection
This initialization is performed in the file:
Platform\ $(PLATFORM_SOUTH_PATH)\Pei\Platform\Stage1\IchInit.c
ICH address constants and additional ICH constants are declared in the file:
Platform\ $(PLATFORM_SOUTH_PATH)\Pei\Platform\Platform.h
Platform component initialization based on user setup preferences is performed later in the DXE ICH initialization.
Resetting of the ICH is performed in the file:
Chipset\IntelIch\IchX\IchInit\Pei\IchReset.c

20. Super I/O Initialization
Minimal porting job to run EFI Shell
Super I/O Initialization
Power-on Super I/O initialization is performed in the file:
Platform\($(PLATFORM_SOURCE_PATH)\Pei\Platform\Stage1\SioInit.c
Devices connected to the LPC bus (e.g. fans, floppy) component initialization is performed later in the DXE Super I/O initialization

21. PCI Routing PCI IRQ routing table is required by some legacy OSes
Minimal porting job to run EFI Shell
PCI Routing
PCI IRQ routing table is required by some legacy OSes
DXE driver that perform PCI devices routing
Platform\$(PLATFORM_SOUTH_PATH)\Common\Dxe\LegacyBios\platform.c
Table – PirqTableHead
Pin 1
Pin 2
Pin 3
Pin 4
Bus
Dev
Reg
Map
Slot
0x00
0x08
0x60
0xDEB8
0x61
0x0000
0x02
0x10
0x62
0x63
0x03
This is a legacy component – we still need it for Non-ACPI OS’s (Windows 98, DOS, Linux?). Or if you choose not to have ACPI tables in your implementation. The PCI routing is needed for these OS’s.
This correlates to the information in the ACPI tables.
This is done in LegacyBios which is part of the CSM32 interface. The CSM will use this table to program the 8259’s
Typical information that is included in this table I/O controller information, PCI/PCI Express and onboard controllers for example LAN.
This information available to OS in at least two ways. The first is the Windows9x PCI IRQ information tables, which also have PCI device to slot label information. The table is so named because Microsoft defined it for Win9x, but many OS seem to make use of the table. The second manner that this information is provided is via the ACPI tables.

22. PIRQ Table Code . . . Example in File:
Platform\$(PLATFORM_SOUTH_PATH)\Common\Dxe
\LegacyBios\platform.c
EFI_LEGACY_PIRQ_TABLE PirqTableHead = {
{0x ,00,01,0000,00,00,0000,0x8086,
0x122e, ,00,00,00,00,00,00,00,
00,00,00,00,00}, {
// Memory Controller devices //
DEFINE_PCI_ROUTINE (0, 1, PIRQA, PIRQB, PIRQC, PIRQD, 0, 0), // PEG graphics port
DEFINE_PCI_ROUTINE (1, 0, PIRQA, PIRQB, PIRQC, PIRQD, 0x7, 0xFF), // PEG slot
DEFINE_PCI_ROUTINE (0, 2, PIRQA, 0, 0, 0, 0, 0), // On-board graphics
DEFINE_PCI_ROUTINE (0, 3, PIRQA, PIRQB, PIRQC, 0, 0, 0), // HECI
. . .

23. PCI IRQ routing in the ACPI Tables
Example in File:
Platform\$(PLATFORM_SOUTH_PATH)\Common\Dxe\AcpiTables\asl\OnBoardPrt.asi
It contains the internal PCI devices and onboard PCI devices IRQ routing information. Generally, all internal PCI devices with ICH or MCH should be listed. For example, USB, IDE, SATA and AC97 controllers in ICH and graphics controller in MCH
PCI IRQ routing information is an important part of the ACPI table. It is included in the DSDT table, which is usually described by ASL language. Typically, during a platform porting, ASL code needs to be updated to provide the correct IRQ routing information for all internal PCI devices, onboard PCI devices and PCI slots. Further, the PCI IRQ routing information should be presented for both APIC mode and PIC mode.

24. Flash ROM Implement EFI_FIRMWARE_VOLUME_ BLOCK_PROTOCOL
Minimal porting job to run EFI Shell
Implement EFI_FIRMWARE_VOLUME_ BLOCK_PROTOCOL
Enables Variable Write Services
Initializes platform specific flash device
Platform\Generic\RuntimeDxe\FvbServices\<Platform>
FWBlockService.c
Possible functions for FWH or SPI access
EnableFvbWrites ( )
EnablePlatformFvb ( )
PlatformGetFvbWriteBase ( )
SetPlatformFvbLock ( )
The firmware volume block protocol provides access to the flash device. The basic Firmware volume and firmware volume block Services are common to all the platforms, the things that may change in different platform are the low level Flash device and flash lock related settings.
EnableFvbWrites – enable writes to the device. For Intel ICH, write to the ICH register
This driver will publish a protocol for the flash device. This interface will manage the flash device. Allowing other components to read/write/erase the flash device.
The reference implementation assumes that FLASH is directly accessible through the memory address space of the proc (the ICH routes the addresses through the LPC bus automatically).
In this directory you will find the file
FvbInfo..c
FvbInfo.c defines the firmware volume headers which can be used to restore the firmware volume header when this module detects the firmware volume crashed. So the EFI_FVB_MEDIA_INFO structure array should be changed based on the new platform firmware volume layout
If the new platform uses different flash devices or different interface other than FWH or SPI, the low level function such as FlashFdWrite, FlashFdErase in FWBlockService.c Should be ported based on the new flash device hardware specification.

25. SMBus PEIM for ICH SMBus initialize
Minimal porting job to run EFI Shell
SM Bus
SMBus
PEIM for ICH SMBus initialize
Chipset\IntelIch\IchX\Smbus IchSmbus.c
Functions to provide a standard way to access SMBus
SmbusExecute ( )
SmbusIoRead ( )
SmbusIoWrite ( )
In the PEI phase the SMBUS must be initialized so that you can initialize/access memory and other devices on the SMBUS.
The PEIM initializes the SMBUS and then publishes protocols for executing commands and reading/writing to devices on the SMBUS.

26. DXE IPL Shadow DXE IPL in permanent memory
Minimal porting job to run EFI Shell
DXE IPL
Shadow DXE IPL in permanent memory
To allow sharing of decompression algorithm with DXE
Allocate 128KB stack for DXE
Create HOBs
Decompression protocol passed as HOB
Firmware Volumes
Passed in HOB
Handle S3 transition
Switch Stacks to call DXE Main
The DXE IPL PEIM performs several tasks
Shadows DXE IPL into permanent memory to allow sharing of the decompression algorithm and several other library routines (e.g. security)
Allocates 128KB of stack for the DXE phase
Creates HOBs for passing library routines and the firmware volumes discovered during the PEI phase. Most commonly this is the main FV and any other FVs that DXE will use to load drivers from (for example backup block)
If S3, then the OS waking vector is called
Locate DXE Main in the FVs
If not S3 then switch stacks and call DXE Main

27. Initialize System Memory
Minimal porting job to run EFI Shell
SM Bus
Initialize System Memory
PEIM that performs system memory initialization
Chipset\<Chipset>
Memory detection
PEI_DUAL_CHANNEL_DDR_MEMORY_CONTROLLER_PPI
Reset
RowInfo
GetMemoryMap
DetectMemory
ConfigureMemory
Memory clock control
PEI_DUAL_CHANNEL_DDR_CLOCK_GENERATOR_PPI
Capabilities
GetFrequency
SetFrequency
Initializing system memory is the main thing that PEI must do. Once memory has been discovered and initialized, then control is passed back to the PEI core and it will switch memory from the temporary memory that SEC created to permanent memory that these interfaces discovered.
There are three PEIMs that discover and initialize memory. A generic PEIM that manages the memory detection and a platform specific ones that is based on the chipset.
The chipset specific PEIMs publishes the protocols (PPIs) that contains methods for obtaining information about the memory, detecting and configuring it.

28. Integrating Memory Init Code
Minimal porting job to run EFI Shell
Integrating Memory Init Code
MRC directory Chipset\<Chipset>\MemoryInit
The file MemoryInit.Inf describes the Memory Reference code contained within its description (.dsc) file.
After calling the entry to this memory init routine and successfully exiting, the memory should be ready to use. It builds HOBs to describe the memory address space and their attributes.
Some of the HOB information that is produced by the MRC:
S3 Memory
SMRAM Descriptor HOB
Memory Descriptor HOB
T-size configuration setup option (variable)

29. PEI Modules CPU PEIM Platform Init and CPU I/O DXE IPL PEIM Generic
Minimal porting job to run EFI Shell
SM Bus
PEI Modules
CPU PEIM
Platform
Init and CPU I/O
DXE IPL PEIM
Generic
Starts DXE Foundation
PCI Configuration PEIM
PCAT
Uses I/O 0xCF8, 0xCFC
Stall PEIM
PCAT
Uses 8254 Timer
Status Code PEIM
These are the minimum set of PEI components that must be dispatched during the PEI.
The list here is those PEIMs that encapsulate those. The order shown here is not the dispatch order. The DXE IPL PEIM is dispatched last
The CPU PEIM installs the CPU_IO PPI that provides CPU IO functions
The DXE IPL PEIM hands off control from the PEI Core to DXE
The PCI PEIM provides basic PCI functions to PEI
The Stall PEIM provides a sleep or wait function
The Status Code PEIM is for debug messages (Port80) and serial port if in debug mode
The SMBUS PEIM initializes and provides SMBUS access
The Memory Control PEIMs read the SPD and initialize/configure memory
Additional platform PEIMs for flash map layout, boot policy determination, fan control and misc chipset initialization
Platform
Debug Messages
SMBus PEIM
South Bridge
SMBus Transactions
Memory Controller PEIMs
North Bridge
Read SPD, Init Memory
Motherboard PEIM
Platform
FLASH Map, Boot Policy

30. PPI Example Minimal porting job to run EFI Shell typedef EFI_STATUS
(EFIAPI *PEI_SMBUS_PPI_EXECUTE_OPERATION) (
IN EFI_PEI_SERVICE **PeiServices,
IN struct EFI_PEI_SMBUS_PPI *This,
IN EFI_SMBUS_DEVICE_ADDRESS SlaveAddress,
IN EFI_SMBUS_DEVICE_COMMAND Command,
IN EFI_SMBUS_OPERATION Operation,
IN BOOLEAN PecCheck,
IN OUT UINTN *Length,
IN OUT VOID *Buffer );
typedef struct {
PEI_SMBUS_PPI_EXECUTE_OPERATION Execute;
PEI_SMBUS_PPI_ARP_DEVICE ArpDevice;
} EFI_PEI_SMBUS_PPI;
Here is a sample declaration of a PPI and its respective functions. The actual SMBUS PPI is longer.
For example the function prototype of the Execute() function is shown here

31. PEIM Pseudo Code Minimal porting job to run EFI Shell
#define SMBUS_R_HD0 0xEFA5
#define SMBUS_R_HBD 0xEFA7
EFI_PEI_SERVICES *PeiServices;
SMBUS_PRIVATE_DATA *Private; UINT8 Index, BlockCount *Length;
UINT *Buffer;
BlockCount = Private->CpuIo.IoRead8 (
*PeiServices,Private->CpuIo,SMBUS_R_HD0);
if (*Length < BlockCount) {
return EFI_BUFFER_TOO_SMALL;
} else {
for (Index = 0; Index < BlockCount; Index++) {
Buffer[Index] = Private->CpuIo.IoRead8 (
*PeiServices,Private->CpuIo,SMBUS_R_HBD); }
Here is an example of how a PEIM works. This function uses the Cpu IO protocol to write information to implement the PPI. Prior to using the CPU IO protocol, the function would of looked up (located) the protocol and initialized the variables. Or the function could wait (notified) when the protocol is available and then perform its operation.

32. What Are Architectural Protocols
Minimal porting job to run EFI Shell
What Are Architectural Protocols
Typically functions that isolate platform specific hardware (e.g. real-time clock)
Provide support for boot services and runtime services
Low level protocols that support DXE APIs (e.g. Boot and Runtime services)
Directly called by DXE core
Now let’s move onto the final phase – DXE.
After the DXE IPL PEIM loads the DXE core, we will move into the DXE phase. There are some early drivers that will get dispatched by the DXE core to provide base services.
It will create and provide support for the EFI System Table by creating these tables. These protocols are directly called by the DXE core.

33. DXE Architectural Protocols
Minimal porting job to run EFI Shell
DXE Architectural Protocols
Watchdog
Generic
Uses Timer-based Events
Monotonic Counter
Generic
Uses Variable Services
Runtime
Generic
Platform Independent
CPU
Platform
Processor DXE Driver
BDS
Platform
Platform Policy and TSL phase
Timer
PCAT
Uses 8254 Timer
Metronome
PCAT
Uses 8254 Timer
Reset
PCAT
I/O 0xCF9
Here is a table of the Architectural protocols. The ones in green will typically not require changes if your platform is PCAT based.
The ones in red will need attention if our platform is different that the reference platforms.
CPU – cache, interrupts, reset, timers
Metronome – periodic signals
Timer – event services
Boot Device Selection (BDS)
Hands off system to OS loader or system utility
Watchdog Timer
Timer that can be armed to generate an event – typically used during OS loader launch to catch platform hangs
Security
Authenticates an image. Used in multiple places to authenticate the image that is about to be loaded into memory
Runtime – virtual addressing
Real Time Clock
Reset
Variable Services – nonvolatile storage access
Monotonic Counter – counter value stored in nonvolatile storage
Status Code
Real Time Clock
PCAT
I/O 0x70-0x71
Security
Platform
Platform Specific Authentication
Status Code
Platform
Debug Messages
Variable
Platform
Depends on FLASH Map

34. DXE Drivers Consuming Architectural Protocols
Minimal porting job to run EFI Shell
DXE Drivers Consuming Architectural Protocols
Host bridge driver
Chipset\PcatCompatible\SimplePciHostBridge\Dxe
ICH initialize driver
Chipset\IntelIch\IchX\IchxInit\Dxe
IDE controller driver
Chipset\IntelIch\IchX\IdeController\Dxe
SMBus DXE driver
Chipset\IntelIch\IchX\Smbus\Dxe
Super I/O
Chipset\<SuperIO Vendor>\Dxe
Here are the minimum set of DXE drivers that must be dispatched in order to boot to the EFI Shell.
The first driver provides interface and attributes of the PCI Host bridge
The ICH initialize driver will continue initializing the ICH and associate components based upon setup values – turn AC97, LAN
The IDE controller will discover and manage the IDE devices in the system. It will publish the low-level disk interfaces that other block I/O drivers need.
The SMBus DXE driver is equivalent to its PEI counterpart in that it publishes an interface for reading, writing and executing commands for the SMBus
The Super I/O intializes the Super I/O chip to publish interfaces that access the ISA bus.

35. NT Emulation Timer Arch Protocol
Minimal porting job to run EFI Shell
NT Emulation Timer Arch Protocol
EFI_STATUS
TimerDriverSetTimerPeriod (
IN EFI_TIMER_ARCH_PROTOCOL *This,
IN UINT TimerPeriod ) {
. . .
gWinNt->EnterCriticalSection (&mNtCriticalSection);
mTimerPeriod = TimerPeriod;
mCancelTimerThread = FALSE;
gWinNt->LeaveCriticalSection (&mNtCriticalSection);
mNtLastTick = gWinNt->GetTickCount ();
mNtTimerThreadHandle = gWinNt->CreateThread (
NULL, 0,
NtTimerThread,
&mTimer,
&NtThreadId); }
The next 3 slides show you an example of how the Timer Architectural protocol is implemented on different platforms.
The essence of these implementations is that the DXE foundation does not need to know about the hardware. Thus when this service is used by drivers they do not need to know the details behind the function call. Thus leaving the implementation to the low level driver

36. Itanium Timer Arch Protocol
Minimal porting job to run EFI Shell
Itanium Timer Arch Protocol
EFI_STATUS
TimerDriverSetTimerPeriod (
IN EFI_TIMER_ARCH_PROTOCOL *This,
IN UINT TimerPeriod ) {
. . .
mTimerCount = (mCpuFrequency * TimerPeriod) / NUMBER_OF_100NS_IN_A_SECOND;
SetupItm (mTimerCount);
// mov loc2 = ar.itc;;
// add loc2 = loc2, in0;;
// mov cr.itm = loc2
// srlz.d;;
ItcInterruptControl (TRUE, TIMER_VECTOR_NUMBER);
// mov loc2 = in1
// mov loc3 = 0x1
// mov loc4 = pr
// cmp.eq p6,p7 = in0,r0;; //
// (p7) dep loc2 = r0,loc2,16,1;; // Clear mask to enable intr
// (p6) dep loc2 = loc3,loc2,16,1;; // Set mask to disable intr
// mov cr.itv = loc2;;
// mov pr = loc4,0x1ffff }
The next 3 slides show you an example of how the Timer Architectural protocol is implemented on different platforms.
The essence of these implementations is that the DXE foundation does not need to know about the hardware. Thus when this service is used by drivers they do not need to know the details behind the function call. Thus leaving the implementation to the low level driver

37. XScale Timer Arch Protocol
Minimal porting job to run EFI Shell
XScale Timer Arch Protocol
EFI_STATUS
TimerDriverSetTimerPeriod (
IN EFI_TIMER_ARCH_PROTOCOL *This,
IN UINT TimerPeriod ) {
UINT64 Count;
UINT32 Data;
. . .
Count = DivU64x32 (MultU64x32 (TimerPeriod, OST_CRYSTAL_FREQ) ,
, NULL);
mCpuIo->Mem.Read (mCpuIo,EfiWidthUint32,OSCR_BASE_PHYSICAL,1,&Data);
Data += (UINT32)Count;
mCpuIo->Mem.Write (mCpuIo,EfiWidthUint32,OSMR0_BASE_PHYSICAL,1,&Data);
mCpuIo->Mem.Read (mCpuIo,EfiWidthUint32,OIER_BASE_PHYSICAL,1,&Data);
Data |= (UINT32)1;
mCpuIo->Mem.Write (mCpuIo,EfiWidthUint32,OIER_BASE_PHYSICAL,1,&Data);
mCpuIo->Mem.Read (mCpuIo,EfiWidthUint32,ICMR_PHYSICAL,1,&Data);
Data |= (UINT32)(1 << SA_OST0_IRQ_No);
mCpuIo->Mem.Write (mCpuIo,EfiWidthUint32,ICMR_PHYSICAL,1,&Data); }
Here is the XScale implementation and you see that it is radically different from the previous

38. 8254 Based Timer Arch Protocol
Minimal porting job to run EFI Shell
8254 Based Timer Arch Protocol
EFI_STATUS
TimerDriverSetTimerPeriod (
IN EFI_TIMER_ARCH_PROTOCOL *This,
IN UINT TimerPeriod ) {
UINT64 Count;
UINT8 Data;
. . .
Count = DivU64x32 (MultU64x32(119318, (UINTN) TimerPeriod) ,
, NULL);
Data = 0x36;
mCpuIo->Io.Write(mCpuIo,EfiCpuIoWidthUint8,TIMER_CONTROL_PORT, 1, &Data);
mCpuIo->Io.Write(mCpuIo,EfiCpuIoWidthFifoUint8,TIMER0_COUNT_PORT,2,&Count);
mLegacy8259->EnableIrq (mLegacy8259, Efi8259Irq0, FALSE); }
Here is the 8254 implementation.
The take away is that when you are porting to different platforms and architectures, most of the porting work is abstracted into small drivers for that platform and you do not need to carry the platform specific code from one module to another (allows most code to be platform independent)
Different Implementations
Same Protocol Interface

39. Serial Terminal Console Services
Minimal porting job to run EFI Shell
Serial Terminal Console Services
BDS / EFI Shell
Simple Input
Protocol
Simple Text
Output Protocol
Virtual
Console
Simple Input
Protocol
Simple Text
Output Protocol
Physical
Console
Serial I/O Protocol
ISA I/O Protocol
Here is a picture of the protocol stack for the serial terminal console services. This details the protocols that are necessary for getting output on the serial terminal.
EFI and the Framework do not directly hard code input/output or console devices to another driver or program. They instead rely upon console devices to produce a Simple Text Input and Simple Text Output protocol. They consume from those protocols. Thus you can write your application free of worry where input and output will be going.
To allow many devices to produce input and output, there is a virtual console or console splitter that gathers input from different devices and sends output to different devices. Thus the BDS or EFI Shell is not directly connected to VGA or serial port. It sends output to the virtual console which in turns send that output to any device that is connected to it that has published the Simple Text Output Protocol.
In the porting aspect, once ISA I/O protocol driver is ported and the underlying protocols it depends on, the Serial I/O driver can be ported and then the BDS and/or EFI shell can be used as-is to continue with your porting and debugging effort.
Super I/O
PCI I/O Protocol
PCI Root Bridge
I/O Protocol
PCI Host Bridge Resource
Allocation Protocol
ISA ACPI Protocol

40. Serial Terminal Console Drivers
Minimal porting job to run EFI Shell
Serial Terminal Console Drivers
BDS / EFI Shell
Generic
Console Splitter
Generic
Terminal
Generic
ISA Serial
PCAT
ISA Bus
Generic
Super I/O
PCI Bus
Generic
Console Platform
Platform
Platform Specific Policy
Here is a table of the drivers used. The drivers in green do not require any changes for your platform. You may have changes in your ISA serial if the UARTs are different than the normal PCAT UARTs
The Console splitter may require changes if your default serial port is not the same as the default one – baud rate, COM port, etc.
The red ones are the base protocols that need platform porting if yours is different than our reference implementation.
PCI Root Bridge
North Bridge
Work with Chipset Vendor
PCI Host Bridge
North Bridge
Work with Chipset Vendor
ISA ACPI
Super I/O
Work with Super I/O Vendor

41. DXE Driver for Console Services
Minimal porting job to run EFI Shell
DXE Driver for Console Services
Console Splitter Driver
Edk\Sample\Universal\Console\ConSplitter\Dxe
Graphics Console Driver
Edk\Sample\Universal\Console\GraphicsConsole\Dxe
Terminal Driver
Edk\Sample\Universal\Console\Terminal\Dxe
UGA Driver (optional)
Chipset\<Vendor>\Uga\Dxe
The console splitter is responsible for virtualizing the text in, text out and error out for each device producing these protocols
The Graphics Console driver produces output on Graphic Devices (VGA). It translates the Simple Text Output to graphics characters (UGA).
The Terminal driver produces output on serial or character stream oriented devices.
The UGA driver translates the UGA protocol into the graphics primitives needed for a specific graphics card.

42. Porting Summary Do Minimum to Run EFI Shell
Minimal porting job to run EFI Shell
Porting Summary Do Minimum to Run EFI Shell
Status Code
PEI
Platform
Memory Controller
PEI
North Bridge
SMBUS
PEI
South Bridge
Motherboard
PEI
Platform
Security
DXE
Platform
SM Bus
Status Code
DXE
Platform
Variable
DXE
Platform
Console Platform
DXE
Platform
Here we have a summary of the drivers that will most likely need changing for your port to a new platform to bring up the EFI shell. As you can see the list is not that long. If your platform is similar to one of our reference platforms (same chipset typically) then your porting effort will mostly be in the area of MRC, Super I/O and PCI infrastructure (servers may have multiple root bus bridges)
The goodness about this is that you can bring the shell up and then via serial port interact with the shell to load and test new drivers as well as your port to this point.
PCI Root Bridge
DXE
North Bridge
PCI Host Bridge
DXE
North Bridge
ISA ACPI
DXE
Super I/O

43. Further Information Documents Directory on CD
Framework Mini PortingGuide
FrameworkTechPortingRef
FrameworkPortingList

44. Q & A

46. Back up
Back Up

47. 2009 release Centrino Mobile Technology platform
Porting example
New form footprint no longer North / South Bridge template
Core / Uncore part of the Processor
Platform Control Hub (PCH) integrated successor to MCH + ICH instead of South Bridge
Power management considerations on mobile
Silicon released as Separate UEFI reference modules
PCH Reference code
Core / Uncore CPU Reference code
ACPI
Power Management
Memory Reference code

48. Platform Platform IntelDpg – Bearlake Pei – Dxe - Platform
IntelEsg – StarLake Pei – Dxe - Platform
IntelMpg – MobilePlatform
AcpiTables
Dsdt
SsdtPtid
VaAcpiTables
Build
Include
LegacyBiosPlatform
Library
PciPlatform
PlatformSetup
SmbiosMisc
ACPI Module Package

49. Platform Control Hub - Chipset
IntelIch
IntelPch – Mobile Chipset (IbexPeak)
ActiveBios
Include
IoTrap
LegacyInterrup
Library
PchInit
PchSmiDispatcher
PciExpress
Ppi
Protocol
RaidRom
Reset
S3Support
SampleCOde
SataController
SerialGpio
SmartTimer
SmBus
SmmControl
Spi
Uhci
Veci

50. Core/Uncore IIO Elements-
CPU
UncoreCommon
AcpiTables
Guid
Include
LegacyRegion
Library
PciHostBridge
SmbiosMemory
SmmAccess
FieldUncore
Iio (Integrated I/O )
IioInit
IioInitLib
Protocol

51. Power Management- Platform IntelDpg – Bearlake Pei – Dxe - Platform
IntelEsg – StarLake Pei – Dxe - Platform
IntelMpg – MobilePlatform
. . .
Common
PowerManagement
AcpiTables
Guid
Include
Library
Protocol
Smm

52. Memory Init CPU UncoreCommon . . . FieldUncore Iio (Integrated I/O )
CsiMemoryInit
CSI
PPI
PEI
Memory

53. Others
Microcode updates
CSM

54. Agenda Create a New Platform Build
Minimal porting job to run EFI Shell
Platform specific porting features

55. Add Platform Features - IDE
Platform specific porting features
Add Platform Features - IDE
BDS / EFI Shell
File Sys Protocol
File Sys Protocol
Disk I/O Protocol
Disk I/O Protocol
SM Bus
Block I/O Protocol
Block I/O Protocol
Partition
Disk I/O Protocol
Disk I/O Protocol
Block I/O Protocol
Block I/O Protocol
Physical Disk
This is the protocol stack for the IDE interface.
First thing is to initialize the IDE controller. The driver checks to see if it supports the controller by verifying the Device/Vendor ID.
An IDE Bus driver will then scan each channel of the controller using the published interface and if the media device is supported, then the driver will install a raw or Block I/O protocol on to device handle This allows the entire media device to be accessed with this protocol. Once that is installed the Disk I/O driver will install a Disk I/O protocol on top of the Block I/O handle. The Disk I/O protocol provides an interface that is not block/sector aligned for the media device.
The partition driver will look at each block I/O device to see if a recognizable partition is on the device. If one is found, it will then attach a logical Block I/O protocol for the raw access of the partition on the device. A Disk I/O protocol is then installed on the new logical Block I/O protocol. Currently supported partition types are MBR, GPT and El-Torito.
Finally a file system protocol is installed if the partition contains a FAT file system. This provides file operations to the media device.
PCI I/O Protocol
PCI Root Bridge
I/O Protocol
PCI Host Bridge Resource
Allocation Protocol
IDE Controller Init

56. Add Platform Features - IDE
Platform specific porting features
Add Platform Features - IDE
BDS / EFI Shell
Generic
FAT
Generic
Partition
Generic
Disk I/O
Generic
SM Bus
IDE Bus
PCAT
PCI Bus
Generic
PCI Root Bridge
North Bridge
PCI Host Bridge
North Bridge
IDE Controller Init
South Bridge
IDE Channel Attributes
This is the block diagram of the files required for porting.
As you see the only necessary drivers to port are the ones that deal directly with the IDE controller and the PCI interface. Currently our reference drivers support both PATA and SATA.

57. Add Platform Features Integrated USB Integrated Video Integrated LAN
Platform specific porting features
Add Platform Features
Integrated USB
Work with Chipset Vendor
USB Host Controller Protocol
Integrated Video
UGA Draw and UGA I/O Protocol
Integrated LAN
UNDI Driver
AGP and PCI Slots
Work with IHVs to Provide EFI Drivers
Given the two examples of serial and IDE we can apply those techniques to the other devices in the system that need supporting on the platform.
For devices that have Option ROMS, you can ask the vendors of those devices to provide an EFI driver. For example the video card and SCSI controller.

58. Compatibility Support Module
Platform specific porting features
Compatibility Support Module
Implement Platform and Chipset Specific Protocols
Legacy BIOS Platform
Legacy Region
Legacy Interrupt
Enables POST of Legacy Option ROMs
Video Controllers
Disk Controllers
Network Interface Controllers
Enables Legacy OS Boot
Linux, Windows XP, Windows 2000
Legacy support is still needed to support Legacy OS’s and Option ROMs.
To support the Legacy environment we have a 32 bit component – CSM32 and a 16 bit component. They talk to each other via a thunk that switches the environment (processor mode)
The CSM32 comprises of 3 components:
Legacy BIOS Platform which manages the creation of the environment for a platform, Option ROM posting and other items.
The Legacy Region manages the reading/writing of the legacy region of C000 to F000
The Legacy Interrupt handles the PCI interrupt management such as setting up the PIRQ tables.
The Legacy boot is entered by making a call to the Legacy BIOS platform driver. Which then set’s up the environment and calls the CSM16 INT19 to do the boot.
The currently supported OS’s are the ACPI aware ones of Linux, Windows XP, and Windows Windows 98SE is also supported for the CSM on those platforms that have chipset support in the OS.

59. CSM drivers LegacyBios driver
Platform specific porting features
CSM drivers
LegacyBios driver
Csm\LegacyBios\Dxe
BiosThunk drivers – BIOS drivers for Legacy OS boot
Csm\BiosThunk\VgaMiniPort\Dxe
Csm\BiosThunk\Keyboard\Dxe
Csm\BiosThunk\Snp16\Dxe
Csm\BiosThunk\BlockIo\Dxe
This is where the environment for legacy boot is setup – BDA, EBDA, E820 memory map is setup up.
The Thunk drivers provide the interface between the CSM 16 and the Framework drivers. The CSM 16 portion is essentially hardware independent, it calls back into the framework via these thunk drivers to get the actual data. This allows the 16 bit portion to be used on many different platforms – it is a library.

60. CSM Drivers Cont’d Legacy Interrupt (PIRQ registers)
Platform specific porting features
CSM Drivers Cont’d
Legacy Interrupt (PIRQ registers)
Chipset\IntelIch\LegacyInterrupt\Dxe\LegacyInterrupt.c
Legacy Region (shadow regions)
Chipset\<Vendor>\LegacyRegion\Dxe\LegacyRegion.c
Legacy BIOS Platform
Platform\<Vendor>\<Platform>\Dxe\LegacyBiosPlatform\ LegacyBiosPlatform.c
Functions to prepare different tables (Option ROM services, etc.)
These are the files that pertain to the PIRQ setup, shadowing regions and Option ROM.
The LegacyBiosPlatform driver mates the Legacy environment to the Framework. It is the entry point for legacy operations

61. Add SMM support to DXE Base Protocol Access Protocol Control Protocol
Platform specific porting features
Add SMM support to DXE
Base Protocol
Responsible for Processor state (in SMM) initialization and allocates SMM Memory
Cpu\<Processor>Base\Smm\SmmBase.inf
Access Protocol
Controls the visibility of the SMRAM on the platform
Chipset\<Vendor>\SmmAccess\Dxe\SmmAccess.inf
Control Protocol
Initiate SMI/PMI activations
Chipset\IntelIch\IchX\SmmControl\Dxe\SmmControl.inf
SMM support is required for booting today’s Windows.
The base protocol driver is responsible for publishing the table of routines (I/O, memory allocation) and other services that can be used in the SMM mode
The access protocol controls the visibility of the SMRAM. It works in conjunction with the Northbridge to open, close and lock the area to protect the integrity
The control protocol works with the chipset to initiate the SMI actions

62. ACPI Support Provides ACPI support for a platform
Platform specific porting features
ACPI Support
Provides ACPI support for a platform
Builds FADT table from built AML tables
Allows platform customization (APIC, GV3, OEMID)
Updates EFI System Table with ACPI table pointers
Composed of two drivers:
ACPI Support Driver (generic)
ACPI Platform Driver (platform specific)
Platform Driver runs during DXE phase (before BDS)
ScriptSave driver
DXE drivers call ScriptSave protocol to save the chipset and CPU configuration at normal boot path
The boot script engine in PEIM restores the chipset and CPU configuration done in previous DXE in S3 resume boot path
Universal\Acpi\BootScriptSave\Dxe\ScriptSave.inf
Let’s talk about ACPI support in the framework before we proceed with ACPI porting issues.
As in legacy BIOS, the ACPI drivers publish information in the built AML tables for the Operating System to use.
The FADT table is built from the compiled ASL code (AML Tables). Platform customization is performed on these tables by various methods. The most common is to get a pointer to the table desired and then walk the table updating the fields desired. These updates are typically the OEM ID, MP info, and if mobile the processor frequencies, power states and etc.
Support is composed of two drivers, a generic (architectural) driver that creates the RSDP, RSDT and XSDT structures from the platforms AML tables and updates the EFI System table with the ACPI information (table pointers).
The ScriptSave driver saves the chipset and cpu configuration during normal boot in a script. This script is played back during the S3 resume by a PEIM.

63. Add ACPI support to DXE ACPI tables ASL code
Platform specific porting features
Add ACPI support to DXE
ACPI tables
Platform\<Vendor>\Dxe\AcpiTables
ASL code
Platform\<Vendor>\Dxe\AcpiTables\Asl\*.asi
Update Platform Driver for platform specifics
Platform\<Vendor>\<Platform>\Dxe\AcpiPlatform\AcpiPlatform.c
ACPI porting consists of the following:
ACPI tables and their corresponding Asl code is used to produce the ACPI information for the platform
Updates are typically the OEM ID, MP info, and if mobile the processor frequencies, power states and etc.

64. EFI S3 path SEC PEI DXE BDS Platform specific porting features OS Boot
Normal Boot
Non-volatile
Storage (NVS)
Resume Script
Table in ACPI
NVS
S3 aware PEIMs restore PEI Phase configuration
Boot Script PEIM restores DXE phase configuration
Retrieve
Execute
S3 Resume
S3 Waking Vector
Save
Here we have a diagram that illustrates the S3 process.
During the DXE phase the chipset and processor configuration information is stored in a script table in NVRAM.
During S3 Resume, we still need to restore this information. During platform initialization in PEI phase, the boot mode is detected, if it is S3 Resume then the PEIM responsible for S3 restores the chipset and processor information by playing back this script to initialize the components whose state needs to be restored. Once the script is done, PEI then jumps to the OS Waking Vector – DXE is bypassed since the platform is now initialized to a known state for the OS.

65. Add S3 Support to DXE Architectural Protocol
Platform specific porting features
Add S3 Support to DXE
Architectural Protocol
Universal\Acpi\AcpiS3Save\Dxe
Universal\Acpi\S3Resume\Pei
Platform dependent Protocol
Platform\<Vendor>\Smm\IchS3Save
Here we have a list of the files that compose the S3 Support. The S3Save Driver is responsible for saving the information required during a S3 Resume. This saves memory address of the S3 waking vector, script and memory that can be used during the resume
The S3 resume PEI handles the actual S3 wakeup and uses the previously saved information to restore the platform
For platform specific S3 handling before transition, the IchS3Save driver handles this. This is typically operations that cannot be saved in script form

66. Framework Designed to be Ported
Platform specific porting features
BDS Driver
BDS driver
Edk\Sample\Platform\Generic\Dxe\PlatformBds
Connecting Consoles/Changing Platform Policy
Platform\<Vendor>\<Platform>\PlatformBds\Dxe\BdsPlatform.c
Language
Platform\Generic\Dxe\Bds\*.uni
Memory Test
Porting is centralized in one bds file.
You will need to identify what the language is desired. Based on the language desired, you will want to direct the HII for different keyboard mappings and output displayed.
Checks are made for what type of console is desired – either serial or VGA or both. These settings come typically from NVRAM or hard codings.
Type of memory test desired. While PEI performs a small one for the amount of RAM needed for PEI/DXE, the check of all the memory found during PEI/DXE is checked here. Once again the type of memory testing done is platform specific. This test can be sparse or rigorous.
Framework Designed to be Ported

67. Summary Minimal porting effort for running EFI Shell.
Incrementally add platform specific features.
Modularity of drivers allows easy integration.
Legacy BIOS experience is still useful with the Framework.
Framework knowledge easily transfers to other architectures.
In summary I have shown the minimum porting effort needed to get the platform up to running the EFI Shell. The goodness of booting up to the shell is that you don’t need a disk, legacy environment, keyboard, mouse or VGA support to begin testing your port. The Shell has many commands built-in that allow you to test additional platform drivers by soft-loading them from the shell. This saves you time in the time-consuming effort of burning to ROM, testing and re-burning.
The modularity of the framework reduces the platform porting effort required and allows you to focus on bringing the system up in small stages than all at once.
Your legacy bios experience is very much adaptable to porting and working with the framework. Many of the specific hardware porting information is still needed to work with the existing and new-coming platform components as well as supporting the legacy boot environment.

68. Further Information Documents Directory on CD
Framework Mini PortingGuide
FrameworkTechPortingRef
FrameworkPortingList