---?image=assets/images/gitpitch-audience.jpg @title[Title-UEFI Overview]

UEFI & EDK II Training

EDK II Build Process

Note: PITCHME.md for UEFI / EDK II Training EDK II Build Process

Redistribution and use in source (original document form) and 'compiled' forms (converted to PDF, epub, HTML and other formats) with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code (original document form) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
Redistributions in compiled form (transformed to other DTDs, converted to PDF, epub, HTML and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

@title[Lesson Objective]

<p align="center"Lesson Objective

@fa[certificate gp-bullet-green]  Define EDK II

@fa[certificate gp-bullet-cyan]  Describe EDK II’s elements including file extensions,
         directories, modules, packages, and libraries

@fa[certificate gp-bullet-yellow]  Explain the EDK II build process

@fa[certificate gp-bullet-magenta]  Explain the Build tools

---?image=assets/images/binary-strings-black2.jpg @title[EDK II Overview Section]

EDK II Overview

The EDK II Infrastructure

@title[Philosophy of EDK II]

Philosophy of EDK II

@snap[north-west span-35]

@box[bg-royal text-white waved fragment](Support UEFI & PI needs

) @snapend

@snap[north span-35]

@box[bg-green text-white waved fragment](Separate tool & source code

) @snapend

@snap[north-east span-35]

@box[bg-blue text-white waved fragment](Package Definition file: DEC
) @snapend

@snap[south-west span-35] @box[bg-yellow text-blue waved fragment](Flash Mapping Tool

)

@snapend

@snap[south span-35] @box[bg-lt-orange text-white waved fragment](Move as much code to C

)

@snapend

@snap[south-east span-35] @box[bg-purple-pp text-white waved fragment](Open source
EDK II on tianocore.org
)

@snapend

Note: Support all UEFI and PI development needs
Separate tool code from source code

note : only older Intel Platforms:<br>
   Build existing EDK modules<br>

Via EDK Compatibility Package (ECP)
Package Definition File: DEC
DEC defines package of modules
FLASH Mapping Tool
Move as much code as possible to C
Open source EDK II on http://tianocore.org

EDK II Goals

so the main goal for EDK II to make it easer in porting of platforms and building UEFI Drivers
First off EDK II is open source on tianocore.org

One goal is to Support all UEFI and PI development needs
UEFI Stands Unified Extensible Firmware Interface and UEFI and PI are making references to the Specifications that are managed by the UEFI Form on www.UEFI.org. The goal of EDK II is to support the implementations of these specs, and to make the implementation useful in a way to support one stand alone Driver or stand alone application or to build one Platform. We wanted to Separate tool code from product code On tianocore there is one storage for the Tools and a separate one for the Product code Because there are a lot of people using the EDK and there is a lot investment in EDK 1, (ie 1117) we wanted to make sure EDK II would build existing EDK modules Via EDK Compatibility Package (ECP)

We have a new Package Definition File: DEC
One level between a platform and a single piece of code or a module DEC defines package of modules Example – 3 drivers all related to the same piece of hardware they would go inside a logical package i.e. the NIC driver a NIC.DEC

We have a FLASH Mapping Tool – we made improvements on this from the previous EDK build process. There is more emphasis on what the flash device layout will look like.

We waned to Move as much as possible to C code Eliminated a lot of the java Eliminated a lot of the Assembly

---?image=/assets/images/slides/Slide5.JPG @title[Implementation of EDK II]

Implementation of EDK II

@snap[west span-90] @box[bg-blue-trans text-white rounded fragment](
@color[yellow](EDK II == UEFI / PI Implementation)

) @snapend

Note: You’ve already learned about the UEFI/PI specification from the web-based training. Now, let’s talk about EDK II, the implementation of UEFI/PI

The primary purpose of the firmware boot loader is to initialize a platform and boot to a shell application or operating system.

EDK II architecture discussions primarily focus on UEFI (OS-to-firmware interface) and PI (firmware-to-firmware interface)

@title[EDK II File Extensions]

EDK II File Extensions
- Located on tianocore.org project edk2

@color[#00ffff](.DSC) .DEC @color[#00ffff](.INF) .FDF	@color[#00ffff](- Platform Description ) - Package Declaration @color[#00ffff](- Module Definition define a component) - Flash Description

+++

@title[EDK II File Extensions]

EDK II File Extensions
- Located on tianocore.org project edk2

@color[#00ffff](.DSC) .DEC @color[#00ffff](.INF) .FDF	@color[#00ffff](- Platform Description ) - Package Declaration @color[#00ffff](- Module Definition define a component) - Flash Description
.VFR .UNI .c & .h	- Visual Forms Representation for User interface - Unicode String text files w/ ease of localization - Source code files
.FD .FV	- Final Flash Device Image - Firmware Volume File

@snap[north-east span-30] @css[ text-yellow fragment](

@color[yellow](EDK II Spec)

@coloryellow

@coloryellow ) @snapend

Note: So for file extensions

-So first we have a DSC file this is for platform description. This is an extension of the existing DSC file from EDK 1. This describes the build rules, libraries and components that are going to get Built. -We have the DEC file which is the Package Declaration. Each package has a package declaration or DEC file, and it declares all the interfaces that the package has. This is one of the new files Next we have INF file - Module Definition this is a description of one module and what it has Next we have a FDF file -Flash Description File – this information used to be part of the original DSC file but has been split off into a new file. This describes which module or modules weather it was built as part of the DSC or included in a binary – it describes which module gets to go where in the flash – which one is comprised – which one goes in to recover - it is a or mapping of the flash device – Next we have a DXS file which is a Dependency expression file - this is used by the DXE and in PEI modules to Define what prerequisites they have before they can run Finally we have the FV file - Firmware Volume image file -

First four have a specification file located on tianocore.org.

See EDK II Build Specification Documentation: http://tianocore.org/

---?image=/assets/images/slides/Slide8.JPG

@title[EDK II Directory Structure]

@size[1.1em]( EDK II Directory Structure )

@snap[north-east span-65]

Package concept for each EDK II sub-directory
Platforms are contained in an EDK II package
EDK II build process reflects the package
Concept of "Work Space" :
$HOME/src/edk2-ws/edk2

@snapend

@snap[south-east span-39 fragment] @box[bg-grey-15 text-white my-box-pad2 ](

bash$ cd $HOME/src/edk2-ws/edk2
bash$ . edksetup.sh
bash$ make –C BaseTools/
Bash$ build

)
@snapend

Note: EXPLAINS WHAT IS IN THE DIRECTORY

Coding explains Workspace Build commands

EDK II build process reflects the package structure … the build command specifies the .DSC file for a platform
These directories are from the github edk2 project

@title[Organization Directory Structure]

@size[1.1em](Organization Directory Structure)

@snap[north span-50 ]

@box[bg-grey-15 text-white rounded my-box-pad2 ](

) @box[bg-grey-15 text-white rounded my-box-pad2 ](

) @snapend

@snap[north-west span-30 ]

@box[bg-gold2 text-white rounded my-box-pad2 ](

Common

) @box[bg-gold2 text-white rounded my-box-pad2 ](

Platform

) @box[bg-gold2 text-white rounded my-box-pad2 ](

Board

) @box[bg-gold2 text-white rounded my-box-pad2 ](

Silicon

) @snapend

@snap[north-east span-67 ]

@css[text-white fragment](

• No direct HW requirements

) @css[text-white fragment](

• Enable a specific
platform's capabilities

) @css[text-white fragment](

• Board specific code

) @css[text-white fragment](

• Hardware specific code

) @snapend

Note: The architecture makes use of four primary classifications of code that are generally instantiated in different EDK II packages.

Common (EDK II) is code that does not have any direct HW requirements other than the basics required to execute machine code on the processor (stack, memory, IA registers, etc).
- Producer(s): TianoCore.org
Platform defines the actions needed to enable a specific platform's capabilities. In this architecture, capabilities are divided into mandatory and advanced features. Mandatory features are enabled in stages prior to Stage VI. Advanced features are enabled in Stage VI and later.
- Minimum Platform Producer(s): TianoCore.org
- Advance Feature Producer(s): TianoCore.org, OEM, BIOS vendor
- Board packages contains board specific code for one or more motherboards.
- Producer(s): Device manufacturer, BIOS vendor, Board user
Silicon, also often called hardware code, has some tie to a specific class of physical hardware. Sometimes governed by industry standards, sometimes proprietary. Silicon or hardware code is usually not intended to have multiple implementations for the same hardware.
- Producer(s): Silicon vendor

@title[Open Source EDK II Workspace - directories]

@size[1.1em](Open Source EDK II Workspace
- directories)

@snap[north-west span-50 ]

@box[bg-black text-white rounded my-box-pad2 ](

) @snapend

@snap[north span-30 ]

@box[bg-gold2 text-white rounded my-box-pad2 fragment ](

Common

) @box[bg-gold2 text-white rounded my-box-pad2 fragment ](

Platform

) @box[bg-gold2 text-white rounded my-box-pad2 fragment ](

Board

) @box[bg-gold2 text-white rounded my-box-pad2 fragment ](

Silicon

) @snapend

@snap[north-west span-60 ]

MyWorkSpace/
   @color[yellow](edk2)/
     - "@color[#FFC000](edk2 Common)"
   @color[yellow](edk2-platforms)/
     Platform/ "@color[#FFC000](Platform)"
       Intel/
         MinPlatformPkg/
           BoardX/ “@color[#FFC000](Board)”
     Silicon/ "@color[#FFC000](Silicon)"
       Intel/
         MinPlatformPkg/
   @color[yellow](edk2-non-osi)/
     Silicon/
       Intel/
   @color[yellow](FSP)/"@color[#FFC000](Silicon)"
     . . ./

@snapend

Note: The build process creates this directory -> Build/ MyWorkSpace – directory from the “git” of repositories

Build –p .dsc from the BOARD Directory

The architecture is designed to support a maintainer ownership model. For example, board developers should not directly modify (fork) the platform, silicon, or common code. More details on conventional usage of the package classifications can be found in supplemental literature from UEFI Forum, TianoCore.org, and others.

@title[ EDK II Open Board Tree Structure]

@size[1.1em](EDK II Open Board Tree Structure )
- KabyLake w/ FSP

@snap[north-west span-70 ]

@box[bg-black text-white rounded my-box-pad2 ](

) @snapend

@snap[north-west span-70 ]

   @color[yellow](edk2)/ github.com/edk2
     . . .
   @color[yellow](edk2-platforms)/ github.com/edk2-platforms
     Platform/
       Intel/
         AdvancedFeaturePkg/
         KabylakeOpenBoardPkg/
             KabylakeRvp3/
         MinPlatformPkg/
         Vlv2TbltDevicePkg/
     Silicon/
       Intel/
         KabylakeSiliconPkg/
         . . ./
         Vlv2DeviceRefCodePkg/
   @color[yellow](edk2-non-osi)/github.com/edk2-non-osi
     Silicon/
   @color[yellow](FSP)/github.com/Intel/FSP
     KabylakeFspBinPkg/

@snapend

@snap[north-east span-60 fragment ]

@color[#A8ff60](←) @color[#FFC000](Common)

@color[#A8ff60](←) @color[#FFC000](Platform)
@color[#A8ff60](←) @color[#FFC000](Board)
@color[#A8ff60](←) @color[#FFC000](Common)

@color[#A8ff60](←) @color[#FFC000](Silicon)

@color[#A8ff60](←) @color[#FFC000](Silicon)

@snapend

Note: This is an example of the MinPlatform for the Intel Architecture (IA) With Kabylake and Vlv2TbltDevicePkg (Minnowboard MAX) as examples

Notice the 3 different repositories for the different sources align similarly to the COMMON, PLATFORM, BOARD & SILICON layout

Not shown is the edk2 repository since this should always be considered as common

---?image=/assets/images/slides/Slide12.JPG @title[Directory Structure - Real Platform]

@size[1.1em](Directory Structure - Real Platform )

@snap[north-east span-20 ]

@box[bg-grey-15 text-white my-box-pad2 ](

) @snapend

@snap[north-east span-18 ]

@color[yellow](Key)
@color[#75deFF](slicon/Chipset)
@color[cyan](Platform)
@color[yellow](Repository)

@snapend

@snap[north-west span-70 ]

@color[#87E2A9](Open Source Directories)

MyWorkSpace /
   Build /
   @color[yellow](edk2)/
     - "edk2 common Source"
   @color[yellow](edk2-platforms)/
     Platform/ Intel
       AdvancedFeaturePkg/
       @color[cyan](Vlv2TbltDevicePkg) /
         - "All platform modules"
     Silicon/ Intel
       @color[#75deFF](Vlv2DeviceRefCodePkg)/
        @color[#75deFF](ValleyView2Soc) /
   @color[yellow](edk2-non-osi)/
     Silicon/ Intel
       @color[#75deFF](Vlv2SocBinPkg)

@size[1.1em](Non- MinPlatformPkg & Non - FSP)

@snapend

Note: Open Source Directory COLUMN 1 Platform and Silicon Directory COLUMN 2

Minnowboard MAX (Native EDK II) is the example directory structure

---?image=/assets/images/slides/Slide13.JPG @title[Modules]

Modules

@css[text-white fragment]( Smallest separate object compiled in EDK II)

@css[text-yellow fragment](@color[yellow](Compiles to)
@color[yellow](.EFI File))

@snap[east span-35] @css[ text-white fragment](UEFI/DXE Driver
@coloryellow
@color[orange](UEFI App.) or
@color#00ffff ) @snapend

Note:

Image - Creative commons https://leadinginnovation11a.wikispaces.com/Where+is+Your+Hardhat%3F+-+Leadership+in+a+21st+Century+School
So the first thing we have in trying to break EDK II down is Modules:

A module is the smallest separate object compiled in the EDK II. A module is a single resultant .EFI file.
Module examples:
A UEFI/DXE driver
A PEIM
A UEFI application
A Library

All of these could be a module. A modules could be one entity

---?image=/assets/images/slides/Slide14.JPG

@title[Packages]

Packages

@div[Left-50]

@ul[brighten]

EDK II projects are made
up of packages
Make your own packages
Package contains only the
necessities
Remove packages from
projects when not required @ulend @divend @div[Right-50]

@divend

Note:

EDK II projects are made up of packages
EDK II Enable developers to make their own packages
Package contains only what is needed
Remove packages from projects when not required

We have this Package Philosophy and what do we mean by a package?
So what we wanted to do is as we get more standards and specifications and as these standards evolve there is a need to target your development on the set of standards you care about. For example, maybe you need some things from the PI specification and others from the UEFI 2.x Specifications and you want to put those things together. So one of the things we wanted to do is provide a mechanism for doing this. So it allows, for instance, a platform developer to get just the things he needs off the shelf and not get the things he dosen’t need. We did this with this concept of using packages
Some history about EDKI :
The EDK I was kind of this monolithic block- it had this environment to build a module – it had the generic code for the green “H” and this NT32 emulation but one thing that was not so good was you need the WHOLE thing in order to build just one thing. Ie, like just building a driver. It would be nice if it came in pieces instead of one big module. If you are developing just drivers you May not care if you have the code for the green “H” or not. SO instead it would be nice if the things came in packages instead of a large source tree.

Another advantage where packages will help, is for example, if you want to add new functions/features - you could package your source together and distribute it as a package instead a monolithic tree. Then you could give this to a customer that has an EDK II build environment allowing them to build with your new functions and features.
Grouping the things together that you need with out the WHOLE kitchen sink Lets leave the Kitchen sink behind

EDK II Enable developers to make their own packages
Package contains only what is needed
Remove packages from projects when not required

We have this Package Philosophy and what do we mean by a package? So what we wanted to do is as we get more standards and specifications and as these standards evolve there is a need to target your development on the set of standards you care about. For example, maybe you need some things from the PI specification and others from the UEFI 2.x Specifications and you want to put those things together. So one of the things we wanted to do is provide a mechanism for doing this. So it allows, for instance, a platform developer to get just the things he needs off the shelf and not get the things he dosen’t need. We did this with this concept of using packages Some history about EDKI : The EDK I was kind of this monolithic block- it had this environment to build a module – it had the generic code for the green “H” and this NT32 emulation but one thing that was not so good was you need the WHOLE thing in order to build just one thing. Ie, like just building a driver. It would be nice if it came in pieces instead of one big module. If you are developing just drivers you May not care if you have the code for the green “H” or not. SO instead it would be nice if the things came in packages instead of a large source tree.

Another advantage where packages will help, is for example, if you want to add new functions/features - you could package your source together and distribute it as a package instead a monolithic tree. Then you could give this to a customer that has an EDK II build environment allowing them to build with your new functions and features.
Grouping the things together that you need with out the WHOLE kitchen sink Lets leave the Kitchen sink behind

@title[EDK II Package Examples: Specs]

EDK II Package Examples: Specs

@snap[west span-45 fragment] @box[bg-blue text-white rounded](MdePkg#Includes files and libraries for Industry Standard Specifications

) @snapend

@snap[east span-45 fragment] @box[bg-orange text-white rounded ](MdeModulePkg#Modules only definitions from the Industry Standard Specification defined in the MdePkg) @snapend

Note:

MdePkg
Include files and libraries for Industry Standard Specifications (i.e. UEFI, PI, PCI, USB, SMBIOS, ACPI, SMBIOS, etc)
MdeModulePkg
Modules (PEIMs + DXE Drivers + UEFI Drivers + UEFI Applications) that only definitions from the Industry Standard Specification defined in the MdePkg
IntelFrameworkPkg
Include files and libraries for those parts of the Intel Platform Innovation Framework for EFI specifications that were not adopted “as is” by the UEFI or PI specifications
IntelFrameworkModulePkg
Contains modules (PEIMs + DXE Drivers + UEFI Drivers) that make reference to one or more definitions in the IntelFrameworkPkg

@title[Additional Package Examples: ]

Additional EDK II Package Examples:

@ul[no-bullet] - @fa[certificate gp-bullet-gold]  Platforms
               @color[#00ffff](EmulatorPkg)     &     @color[#00ffff](OvmfPkg)

- @fa[certificate gp-bullet-magenta]  Chipset/Processor
                @color[#00ffff](IntelSiliconPkg)    &    @color[#00ffff](KabylakeSiliconPkg)

- @fa[certificate gp-bullet-green]  Functionality
                @color[#00ffff](ShellPkg)    &     @color[#00ffff](NetworkPkg)
@ulend

Note: Platforms
Nt32Pkg – contains drivers and applications required for running over Windows
OvmfPkg – Virtual Machine Firmware

Chipset/Processor
IA32FamilyCpuPkg.- Intel Architecture
Ich9Pkg – Intel I/O controller hub (ICH9 )

Functionality
ShellPkg – Application - command line interface
NetworkPkg – Network drivers and Applications

---?image=/assets/images/slides/Slide17.JPG

@title[Libraries ]

Libraries

Note:

Famous Time line picture
SEC –Platform code to Turn on the Cache so having libraries would be useful
PEI – Executing from the Flash device - No memory – constrained environment – turn on memory control – Set libraries to help write code in this environment
DXE – Main phase of Firmware – Platform interfaces – DXE Drivers, UEFI 2.x interfaces – Run EFI option roms – So we have libraries that are common between these environments

Base Libraries – generic libraries that can run anywhere – not only in the EDK II but anywhere – generic environment for writing stand alone C code

BDS – Policy happens – Screen turns – boot policy
“Same lib classes exist across multiple phases but can have different lib instances”

+++?image=/assets/images/slides/Slide18.JPG

@title[Libraries 02]

Libraries

Note: Famous Time line picture
SEC –Platform code to Turn on the Cache so having libraries would be useful
PEI – Executing from the Flash device - No memory – constrained environment – turn on memory control – Set libraries to help write code in this environment
DXE – Main phase of Firmware – Platform interfaces – DXE Drivers, UEFI 2.x interfaces – Run EFI option roms – So we have libraries that are common between these environments

Base Libraries – generic libraries that can run anywhere – not only in the EDK II but anywhere – generic environment for writing stand alone C code

BDS – Policy happens – Screen turns – boot policy
“Same lib classes exist across multiple phases but can have different lib instances”

+++?image=/assets/images/slides/Slide19.JPG

@title[Libraries 03]

Libraries

Note: Famous Time line picture
SEC –Platform code to Turn on the Cache so having libraries would be useful
PEI – Executing from the Flash device - No memory – constrained environment – turn on memory control – Set libraries to help write code in this environment
DXE – Main phase of Firmware – Platform interfaces – DXE Drivers, UEFI 2.x interfaces – Run EFI option roms – So we have libraries that are common between these environments

Base Libraries – generic libraries that can run anywhere – not only in the EDK II but anywhere – generic environment for writing stand alone C code

BDS – Policy happens – Screen turns – boot policy
“Same lib classes exist across multiple phases but can have different lib instances”

+++?image=/assets/images/slides/Slide20.JPG

@title[Libraries 04]

Libraries

Note: Famous Time line picture
SEC –Platform code to Turn on the Cache so having libraries would be useful
PEI – Executing from the Flash device - No memory – constrained environment – turn on memory control – Set libraries to help write code in this environment
DXE – Main phase of Firmware – Platform interfaces – DXE Drivers, UEFI 2.x interfaces – Run EFI option roms – So we have libraries that are common between these environments

Base Libraries – generic libraries that can run anywhere – not only in the EDK II but anywhere – generic environment for writing stand alone C code

BDS – Policy happens – Screen turns – boot policy
“Same lib classes exist across multiple phases but can have different lib instances”

---?image=/assets/images/slides/Slide_Libraries.jpg @title[Example-Library-Debuglib]

Example - Library Debuglib

@snap[north-west span-25 fragment]

@box[bg-lt-orange-trans text-black ](NULL

) @snapend

@snap[north span-40 fragment]

@box[bg-blue-trans text-black ](Robust Functions
Port 80
Serial Output
Data Hub
etc. . .

) @snapend

Note: DebugLib library class name
The debugging characteristics might be different during the different boot up phases.
SEC PEI – Null or no code but all reffernces will be resolved with the BaseDebugLibNull Implementation of the DebugLib
DXE-BDS – Code to output to serial port/ port 80 codes
Library Class names can be linked with different Processor resolutions (IA32/ x64) & different boot phases

---?image=/assets/images/slides/Slide22.JPG

@title[PCD Title page]

Platform Configuration Database (PCD)

Note: Defining database - like global variables

Many components of a database to help fine tune the BIOS or Firmware - build & runtime

@title[Platform Configuration Database-Goals]

Platform Configuration Database (PCD)

@box[bg-royal text-white rounded my-box-pad2 ](Goals)

@snap[west span-45 ] @box[bg-brick text-white rounded fragment](Define module parameters
Store module / platform configurations)
@snapend

@snap[east span-45 ] @box[bg-brick text-white rounded fragment](Reduce source edits

Maximize module reuse across platforms)
@snapend

@snap[south-west span-45] @box[bg-brick text-white rounded fragment](Remove #define
No searching for "magic" #define statements ) @snapend

@snap[south-east span-45 ] @box[bg-brick text-white rounded fragment](API functions
Get and Set functions for access to PCD variable DB) @snapend

Note: So what is the platform configuration database goal?

First off, PDC entries are used for module parameterization. Examples are define statements, variables etc.

What are the benefits, we want to reduce the need to edit the source code.
Also there is no need for searching for a magic #define statement, for example like base address registers. These can all be PCD values.
Purporting we want to maximize the module reuse across platforms and also will have APIs for accessing the PCD entries

What the PCD store, the store platform information like the vital product data serial number, we can use variable PCBs for setup options etc.

@title[Platform Configuration Database - Advantages]

Platform Configuration Database (PCD)

@box[bg-yellow text-blue rounded my-box-pad2 ](Advantages)

@snap[west span-45 ] @box[bg-purple-pp text-white rounded fragment](Binary Modularity
Configure firmware settings in binaries without building ) @snapend

@snap[east span-45 ] @box[bg-purple-pp text-white rounded fragment](Configure
Provide for options to configure firmware features) @snapend

@snap[south span-45] @box[bg-purple-pp text-white rounded fragment](Patching
Simplify the binary patching process ) @snapend

Note:

What are the Advantages and the purpose of the platform configuration database?

It has common definitions that are established for platform component settings in the database. The contents of this database are intended to standardize the exposure of platform and module settings which can in-turn facilitate platform porting. One of the goals is to help us with platform porting.

There are some build time aspects –
A collection of component information is established from the PCD component definitions that will be associated with a given module.

There are run time aspects –
by providing APIs which allow common access to component settings during the operation of the platform, we can allow for binary distribution models which are PCD compliant. In other words, Not everyone has the source!

And finally, there are binary edit aspects -
One of the stated goals is that a module can carry their own PCD data in their binary image and have it exposed so that they can be edited in the flash image.

@title[EDK II Infrastructure Summary]

EDK II Infrastructure Summary

@snap[west span-30 ] @box[bg-royal text-white waved fragment](@color[yellow](Packages)
List of related modules ) @snapend

@snap[north-west span-45 fragment] @css[text-yellow](

+) @snapend

@snap[midpoint span-30 ] @box[bg-royal text-white waved fragment](@color[yellow](Libraries) Same name & interface) @snapend

@snap[north span-45 fragment] @css[text-yellow](

+) @snapend

@snap[east span-30] @box[bg-royal text-white waved fragment](@color[yellow](PCDs)
Platform Config. DB ) @snapend

Note:

Summary

Packages
- list of modules
Libraries
- Same Names with different implementation but same interface
PCD
- Platform configuration database

---?image=assets/images/binary-strings-black2.jpg @title[Build Tools Section]

Build Tools

EDK II Build Tools and Configuration Files

@title[Development Environment]

Development Environment

@snap[west span-45 ] @box[bg-brick text-white rounded](Compiler Tool Chains)

<br >

@snapend

@snap[east span-45 ] @box[bg-green-pp text-white rounded](Operating Systems)

<br >

@snapend

@color[#fcb813](Microsoft Visual Studio (VS2017, VS2015, VS2013, VS2012, VS2010, etc.) )
@color[#fcb813]( Microsoft WDK)
@color[#fcb813]( Intel C/C++ compiler)
@color[#fcb813](Intel C EFI Byte Code (EBC) compiler )
@color[#fcb813]( GCC V5.x or later)

@color[#A6ce39](Microsoft Windows XP/7/8/10 )
@color[#A6ce39](Apple Mac OS X )
@color[#A6ce39](RedHat Enterprise Linux)
@color[#A6ce39](Novell SuSE Linux)
@color[#A6ce39](Ubuntu 16.04 )
@color[#A6ce39](Clear Linux* Project )

@snap[south-west span-45 ]

@color[white]( Python 3.7.n & Nasm)

@snapend

Note: The development environment is one of the primary changes to EDK II.
We wanted a change, build wood work dramatically
We have Compiler tool chains:
we still support Microsoft C compiler and WDK and Intel C/C++ compiler
now we also support GCC
We still support Intel C UEFI Byte code compiler
You can build across multiple Operating Systems –Windows, Mac, Linux flavors
All of these are supported across all the modules in the write.
NOTE: this does not mean someone can write some assembly language code that was specific to the Microsoft compiler or assembler that in turn does not work on GCC. The standards we set for the core components are that they will work across everything. It is up to you as a developer to make sure the code you write meets the requirements of what ever compiler you use.
For example, the byte code compiler does not do floating point. So if you add code that does floating point, be aware that you cannot compile that into byte code.

---?image=/assets/images/BK_grey-box-bottom.jpg @title[Environment Variables]

Environment Variables

@snap[north span-35 ] @css[text-yellow](
) @box[bg-blue text-white rounded my-box-pad2 ](Set by @coloryellow
Window = .bat
Linux = .sh ) @snapend

1. EDK_TOOLS_PATH
2. PATH
3. WORKSPACE
4. EFI_SOURCE / EDK_SOURCE
Outside @color[yellow](edksetup )
@color[orange](* ) PACKAGES_PATH @color[black]((optional ))

Note: EDK II depends on Environment variables –
The EDK_TOOLS_PATH –tells the build system the location of the binary tools directory. By default they will be in the build tools directory. However, there may be a difference if you are on a server and you share build tools. Or, for example, if you compile build tools for Linux and another for windows, and you want to set your build path based on which OS you are building from.

The PATH is the directory location for any binary tools needed for the operating system.

The WORKSPACE –tells EDK II your workspace . You would want to set it to the location where you downloaded the source code.

EFI_SOURCE and EDK_SOURCE are used for the EDK compatibility package ECP when you are building an old module from EDK 1.
The last two are not used for native EDK II at all.

@title[Configuration Files - Scripts]

Configuration Files - Scripts

@fa[circle gp-bullet-gold] edksetup.bat or edksetup.sh
@fa[circle gp-bullet-magenta]  First time use will set up the configuration files:
          Conf/@color[#87E2A9](build_rule).txt
          Conf/@color[#00ffff](target).txt
          Conf/@color[yellow](tools_def).txt
@fa[circle gp-bullet-green] Setup & verify a developer's workspace

@snap[north span-50 fragment] @css[text-yellow](

) @snapend

Note: edksetup.bat or edksetup.sh
2. First time use will set up configuration files
Conf/build_rule.txt (SIMPLE NOTHING TO SAY)
Conf/target.txt (WILL GO INTO DETAIL NEXT SLIDE)
Conf/tools_def.txt (WILL GO INTO DETAIL TWO SLIDES)

3.Setup & verify a developer’s workspace

This slide describes some script files
edksetup (.bat or .sh)— used to setup and verify your workspace
These also set the environment variables like the WORKSPACE and EDK_TOOLS_PATH, etc.
When you run these scripts, the files set up your workspace and some configuration files (if they are not already there).
If you run this script file and those files are already there, it won’t do anything. But if it doesn’t find these three files— target.txt, tools_def.txt, build_rule.txt—it will create them from templates.

@title[Multiple Workspace Environment Variable]

Multiple Workspace Environment Variable

@snap[north span-40 ]

@box[bg-green-pp text-white rounded my-box-pad2]( PACKAGES_PATH) @snapend

@snap[north-west span-50 fragment]

@color[#A8ff60](WORKSPACE)
@color[#A8ff60](PACKAGES_PATH )- Optional

Multiple paths that will be searched when attempting to resolve the location of packages.

@snapend

@snap[north-east span-50 fragment]

Highest search Priority / Build Directory
Additional Paths in Priority order. Must be set before @color[#87E2A9](edksetup) and @color[red](NOT) set by @color[#87E2A9](edksetup)

@snapend

@snap[south-east span-97 fragment]

@color[yellow](Example:)

@box[bg-black text-white rounded my-box-pad2 ](

bash$ export WORKSPACE=$PWD
bash$ export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-libc

)
@snapend

@snap[south-east span-35 fragment]

@snapend

Note:

Package_Path

An update to the EDKII build tools now allows the setting of multiple paths that will be searched when attempting to resolve the location of packages. This new feature allows for more flexibility when designing a tree layout or combining sources from different sources. The new functionality is enabled through the addition of a new environment variable (PACKAGES_PATH). The PACKAGES_PATH variable is an ordered list of additional search paths using the default path separator of the host OS between each entry. The first path in the list has the highest priority and the last path has the lowest priority. The path specified by the WORKSPACE variable always has the highest search priority over any PACKAGE_PATH entries. To use this feature, the PACKAGES_PATH environment variable must be set prior to running the edksetup script. The reason for this is that the edksetup script determines the location of the Conf and BaseTools directory location based on the values of the WORKSPACE and PACKAGES_PATH environment variables. The use of the PACKAGES_PATH environment variable is optional and if it is not defined the build will function like it has in the past.

Why and when: In this case WORKSPACE is the container for two trees as well as the location of the Build directory. The example assumes the set of code packages for a given platform are contained in the platform directory. While the code packages from the open source repository are contained in the edk2 directory.

When the build tools are run with this configuration the directories will be scanned in the following order to find packages listed in the DSC and FDF files.

@title[Using target.txt]

@size[1.1em](Using target.txt )

@snap[north-west span-100 ]

Tag	Description
ACTIVE_PLATFORM	Pointer to DSC file being built
TARGET	Build mode: DEBUG or RELEASE
TARGET_ARCH	Build architecture (IA32, IPF, X64, EBC, ARM)
@color[#FFC000](TOOL_CHAIN_TAG)	Compiler/tool set to use, based on definitions in tools_def.txt

@snapend

@snap[south span-95 fragment ]

MAX_CONCURRENT_THREAD_NUMBER - defaults to Number of threads available to the build process (multi-threaded build)

@snapend

Note:

You may considering changing these based on your compiler and platform

So let’s go over each of these files, starting with target.txt

target.txt contains six pieces of information that are important for your entire workspace
One - What DSC file represents the platform that you are building?
So are you trying to build by default a particular platform? For example, a Lakeport? Or the NT32 emulation. When you type build you do not have to do anything else. You can type build and go on.

Two, the Target – are you trying to build a release build or a debug build?

Three, the Target architecture- are you trying to build IA32, Itanium, X64? We have this in the target.txt file is so you do not have to type in a long build command line.
Most of these have the option on the build command line to give it a target architecture or target, but having it in the target.txt file it allows you to type in minimal on the command line.

The next three are less commonly changed:
Four, the Path to the tools_def or tools default file – so if you want to move that to the tools default to a shared location
Five, the TOOL_CHAIN_TAG – says in the tools default file which section or compiler tools we are using
Six, is how many threads to use to do the build – so if you have a brand-new Core i7 processor to do the build you set this to the number of processors, and that’s how you can get the build down to less than 30 seconds

@title[Using Tools_Def.txt 03]

@size[1.1em](Using tools_def.txt )

@ul[no-bullet]

@fa[certificate gp-bullet-magenta] Paths for compilers, assemblers, and linkers
- @color[#00ffff](Comes with definitions for all compilers )
@fa[certificate gp-bullet-gold]  Only modify this file when …
     -    @color[#00ffff](Tools are installed in a non-default location)
     -    @color[#00ffff](Different compilers/tools need to be added)
@fa[certificate gp-bullet-ltgreen]  Default values are set by edksetup script
     -    @color[#00ffff](Default values will cover most compiler needs)
     -    @color[#00ffff](If there are problems with the file after editing, just delete)
             @color[#00ffff]( and re-run edksetup (restores default))
@ulend

Note: Paths for compilers, assemblers, and linkers
Comes with definitions for all compilers
Only modify this file when …
Tools are installed in a non-default location
Different compilers/tools need to be added
Default values are set by edksetup script
Default values will cover most compiler needs
If there are problems with the file after editing, just delete and re-run edksetup (restores default)

@title[BaseTools]

@size[1.1em](First Make )BaseTools

@snap[north span-35 ] @css[text-yellow](
) @box[bg-royal text-white rounded my-box-pad2]( @color[yellow](BaseTools) ) @snapend

The first step is to make / "nmake" the "BaseTools" with the host OS & compiler environment.

For @fa[linux gp-bullet-gold] Linux GCC5 the command is: @box[bg-grey-05 text-white rounded my-box-pad2](

bash$ make -C BaseTools

)

For @fa[windows gp-bullet-cyan] Windows Visual Studio with Python 3.7 the command is:

@box[bg-grey-05 text-white rounded my-box-pad2](

> edksetup.bat Rebuild

)

@snap[south-west span-100 ]

@color[white](Building "BaseTools" only needs to be done once )

@snapend

Note: the first step is to make / nmake the BaseTools with the host OS / compiler environment.

For GCC the command is: make -C BaseTools

For Windows the command is:

```
   set PYTHON_HOME=C:\Python27
```
```
   edksetup.bat Rebuild
```

---?image=assets/images/binary-strings-black2.jpg @title[Build Process Section]

Build Process

EDK II Build Process and Build Text Files

---?image=/assets/images/slides/Slide35.JPG

@title[Build Process Overview]

Build Process Overview

Note:

+++?image=/assets/images/slides/Slide36.JPG

@title[Build Process Overview 03]

Build Process Overview

Note:

+++?image=/assets/images/slides/Slide37.JPG

@title[Build Process Overview 04]

Build Process Overview

Note: +++?image=/assets/images/slides/Slide38.JPG

@title[Build Process Overview 05]

Build Process Overview

Note: +++?image=/assets/images/slides/Slide39.JPG

@title[Build Process Overview 06]

Build Process Overview

Note: +++?image=/assets/images/slides/Slide40.JPG

@title[Build Process Overview 07]

Build Process Overview

Note: +++?image=/assets/images/slides/Slide41.JPG

@title[Build Process Overview 08]

Build Process Overview

Note:

+++?image=/assets/images/slides/Slide42.JPG

@title[Build Process Overview 08]

Build Process Overview

Note:

@title[Basic Build Steps]

@size[1.1em](Basic Build Steps )

@snap[west span-45 ] @box[bg-royal text-white rounded](Platform)

<br >

@snapend

@snap[east span-45 ] @box[bg-brick text-white rounded](Module)

<br >

@snapend

@snap[north-west span-50 ]

1. Navigate (CD) to root of EDK II
workspace
2. Make the BaseTools
3. Run @color[#87E2A9](edksetup)
4. Run build
5. @color[cyan](Output): firmware image (FD)
file under Build directory

@snapend

@snap[north-east span-48 ]

1. Navigate (CD) to root of EDK II
workspace
2. Make the BaseTools
3. Run @color[#87E2A9](edksetup)
4. @color[yellow](Change to directory with
desired INF file )
5. Run build
6. @color[cyan](Output): .EFI file under Build
directory

@snapend

@snap[south-west span-45 ] Note: Module .inf must be in .dsc components

@snapend

Note:

Platform:

Open Terminal prompt
Navigate to root of EDK II workspace
Run edksetup
Edit Conf/target.txt
Run build
Output: firmware image (FD) file under Build directory

Module:
SAME except - Change to a directory with the proper INF also NOTE the inf file MUST be a in the components section of the .DSC file

---?image=/assets/images/slides/Slide44.JPG

@title[Build Output Location]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide45.JPG

@title[Build Output Location 02]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide46.JPG

@title[Build Output Location 03]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide47.JPG

@title[Build Output Location 04]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide48.JPG

@title[Build Output Location 05]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide49.JPG

@title[Build Output Location 06]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide50.JPG

@title[Build Output Location 07]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide51.JPG

@title[Build Output Location 08]

Build Output Location

Note:

+++?image=/assets/images/slides/Slide52.JPG

@title[Build Output Location 09]

Build Output Location

Note:

@title[EDK II Build Process Stages]

EDK II Build Process Stages

@snap[north-west span-15 fragment] @css[text-yellow](
) @snapend

@snap[north span-65 fragment] @css[text-yellow](

)

Parse meta-data files to generate some C source code files and the make files

@snapend

@snap[west span-15 fragment] @snapend

@snap[midpoint span-65 fragment]

Process source code files to create PE32/PE32+/COFF images processed to UEFI format using $(MAKE) tool

@snapend

@snap[south-west span-15 fragment] @css[text-yellow](

) @snapend

@snap[south span-65 fragment]

Takes the UEFI format files, creates UEFI “FLASH” images, UEFI apps, or UEFI PCI option ROMs

@snapend

Note: Parse meta-data files to generate some C source code files and the make files

Process source code files to create PE32/PE32+/COFF images processed to UEFI format using $(MAKE) tool

Takes the UEFI format files, creates UEFI “FLASH” images, UEFI apps, or UEFI PCI option ROMs

---?image=/assets/images/slides/Slide54.JPG

@title[EDK II Build AutoGen Stage]

EDK II Build: AutoGen Stage

@snap[south-east span-90 ]

build -p OvmfPkg/OvmfX64Pkg.dsc

@snapend

Note: Build –p OvmfPkg/OvmfX64Pkg.dsc
Parse – .DSC, .DEC, .FDF, .INF
DSC File …
Points to own .DEC & .FDF & .INF
Points to other packages (.DEC) and Modules (.INF)

ONE DSC per Build command

DSC points to all the components, Libraries, PCDs, etc needed to build a PACKAGE

@title[EDK II Build Make Stage]

EDK II Build: Make Stage

@snap[north span-65 ] @css[text-yellow](

) @box[ bg-green-pp text-white rounded my-box-pad2 ](Uses assemblers/compilers/linkers to generate PE32/PE32+ COFF image file
) @snapend

@snap[midpoint span-90 ]
@box[ bg-lt-blue-pp text-white rounded my-box-pad2 ](Uses ImageGen tools to modify PE32/PE32+/COFF image file
Creates UEFI file (EFI_IMAGE_SECTION_HEADER structure)
) @snapend

@snap[south-west span-20 ] @csstext-black @css[text-black](
) @snapend

@snap[south span-20 ] @csstext-black @css[text-black](
) @snapend

@snap[south-west span-25 ] @css[text-black]( GenFW

) @snapend

@snap[south span-25 ] @css[text-black](GenFds

) @snapend

Note: Uses assemblers, compilers and linkers commonly available to generate a PE32/PE32+/COFF image file
Uses the ImageGen tools modify the PE32/PE32+/COFF image file to create an UEFI file (EFI_IMAGE_SECTION_HEADER structure)
GenFw tool must specify the component type derived from the INF meta-data’s Module Type statement
GenFds application initiates the third stage of the EDK II build

The build process stages
The first stage is the autogen stage,which parses the meta-data files: the DEC DSC and INF files. It parses the meta-data files to generate your autogen.C and autogen.h files.
Additionally we generate the makefiles. There will be one makefile for each INF file we to be compiled and an additional makefile for the overall process. (The whole build itself gets one makefile.)

The second stage, the binary makes stage, processes the source code. Now we use the makefiles and your source code to generate the images which are then processed into UEFI format images using the make tool. We end up with .EFI files.

third and final stage, the ImageGen stage, we take these UEFI formatted files and create the flash image, or leave them as UEFI applications, or perhaps make UEFI-compliant PCI option ROMs.
This last stage is also configurable.

---?image=/assets/images/slides/Slide56.JPG

@title[EDK II Build Image GEN Stage]

EDK II Build: ImageGen Stage

@div[left-50]

Builds one image for each specified firmware volume (FV)
The FDF file supports all syntax available in the PI Specification Vol. 3

@divend @div[right-50]
@divend

Note: Builds one image for each specified firmware volume (FV)

The FDF file supports all syntax available in the PI Specification Vol. 3

the modular build process allows this stage to be changed for different outputs
Example: how to combine a UEFI Driver & Legacy PCI OpROM into a single binary image for a PCIe card? See next slide …

third and final stage, the ImageGen stage, we take these UEFI formatted files and create the flash image, or leave them as UEFI applications, or perhaps make UEFI-compliant PCI option ROMs.
This last stage is also configurable.

---?image=/assets/images/slides/Slide57.JPG

@title[Build Flow For OpROM]

Build Flow For OpROM

Note:

+++?image=/assets/images/slides/Slide58.JPG

@title[Build Flow For OpROM 02]

Build Flow For OpROM

Note:

@title[Build Command]

@size[1.1em](The @color[white](build) Command )

Accepts command line arguments to support scripted builds
Overrides most settings found in target.txt
Overrides DSC with a minimal INF build
Overrides some settings in DSC file (.FDF)
Choose settings from the FDF file (ROMIMAGE, FVIMAGE)
Choose $(make) options (silent, verbose, quiet)

Note:

THIS IS A BUILD SLIDE - Press Right arrow
Advanced building usage The build tool is the main interface to the complete build process. This is a compiled tool downloaded as part of EDK II, or built if you are running on a non-Windows system.
It runs the rest of the build tools for you
There are command-line tools that are designed for the scripting of the build. For example, in our group, we scripted it to run the build every night and send out a report. This way so we can see if something has been checked in that could cause the build to break
The goal is to enable enough features to script the build successfully, not to enable absolutely every feature. You can override most of the settings of the target.txt file. For example, you can change the architecture from high x64 to IA64.

You can change which DSC file you are building.
You can change the target.txt for the toolchain.
You can change the thread count to build with four threads, not one thread, etc.
You can override the DSC and Say “please only build my INF file”.
You can change which FDF file you want for the build.
From inside the FDS file you can change the ROMIMAGE or FVIMAGE settings
You can change the messaging output from the make settings for instance, making it silent, or verbose, or quiet.
Outside of changing the number of the threads used – if you are building the same code—unlike EDK, we don’t see a dramatic increase in the amount of time required. For example, if you are letting it output to the screen, the text outputting does not have the same level of impact as an EDK text output.
In advanced build usage you can type build –h, or build –help, and it will give you this information. Although there are more options that you can list, they are used less frequently.

---?image=/assets/images/slides/Slide60.JPG

@title[Using EDK II build Command]

@size[1.1em](Using EDK II @color[white](build) Command )

@snap[south span-35 ]

bash$ build -h

@snapend

Note:

This is not the complete list … run build --help from the command prompt to see all of the build options

+++?image=/assets/images/slides/Slide61.JPG

@title[Using EDK II build Command 02]

@size[1.1em](Using EDK II @color[white](build) Command )

@snap[south span-35 ]

bash$ build -h

@snapend

Note:

This is not the complete list … run build --help from the command prompt to see all of the build options

+++?code=sample/buildoutput.txt&lang=shell&title=

build -h Command

@[1,5-25](options to overide .DSC, .INF and .FDF and Target.txt settings) @[60,65-74](Using the -Y and -y options for Reports)

Note: output from Build -h command

---?image=/assets/images/slides/Slide63.JPG @title[Using Build-Y Reports]

@size[1.1em](Using @color[white](build -Y) Reports )

@snap[south-west span-75 ]

Example:
   @size[.7em](bash$ build –Y PCD –y pcd.log)
For all reports:
   @size[.7em](bash$ build –y MyReport.log )

@snapend

Note: build –Y PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS

-Y REPORTTYPE
--report-type=REPORTTYPE

Flags that control the type of build report to generate. Must be one of: [PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS, EXECUTION_ORDER].

To specify more than one flag, repeat this option on the command line and the default flag set is [PCD, LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS]

EXEC ORDER is best done on the Host build machine

+++ @title[Using Build-Y Reports Example]

@size[1.1em](Using @color[white](build -Y) Reports )

@size[.8em](Scroll through examples of reports from the build -Y commands)

Note: TBD

+++?code=sample/Reports/depex.log&lang=shell&title=

build -Y DEPEX Command

Note:

+++?code=sample/Reports/pcd.log&lang=shell&title=

build -Y PCD Command

Note:

+++?code=sample/Reports/library.log&lang=shell&title=

build -Y LIBRARY Command

Note:

+++?code=sample/Reports/flash.log&lang=shell&title=

build -Y FLASH Command

Note:

+++?code=sample/Reports/build_flag.log&lang=shell&title=

build -Y BUILD_FLAGS Command

Note:

+++?code=sample/Reports/fixed_address.log&lang=shell&title=

build -Y FIXED_ADDRESS Command

Note:

+++?code=sample/Reports/ExecOrder_EmulatorPkg.log&lang=shell&title=

build -Y EXECUTION_ORDER Command

Report.html is generated on the host build machine - pop up this in the Browser window.

Note: This is best done on the Host build machine

+++?code=sample/Reports/Emulator.report&lang=shell&title=

build -y MyReport.log Command

Note:

@title[Build Tool Binaries]

Build Tool Binaries

Utility	Description
Build.exe	Tool is written in Python and calls AutoGen.exe, then it calls $(MAKE) –f Makefile.out, and finally, it calls GenFds.exe
EfiRom.exe	used to build an option ROM image
PatchModule.exe	used to patch a binary module that has a PCD of type PATCHABLE_IN_MODULE
PatchPlatform.exe	used to modify either the PCD Database or the VPD settings in a flash device image

Note: The build tool binary files
There are four main build tools that we expect people to use frequently
Everybody will use Build.exe. This is the tool that runs the entire build.
EfiRom.exe is good for building EFI ROM images. It is possible to configure build.exe to call EfiRom.exe, but this is not required.
The patch programs PatchModule and PatchPlatform are used for changing PCD values that were defined as patchable.
When you make a PCD it is possible to make it patchable.
The following instructions show you how to do the patching.

All of the tools listed here can be run manually.

Other tools run as part of these 4

@title[Summary]

<p align="center"Summary

@fa[certificate gp-bullet-green]  Define EDK II

@fa[certificate gp-bullet-cyan]  Describe EDK II’s elements including file extensions,
         directories, modules, packages, and libraries

@fa[certificate gp-bullet-yellow]  Explain the EDK II build process

@fa[certificate gp-bullet-magenta]  Explain the Build tools

---?image=assets/images/gitpitch-audience.jpg @title[Questions]
![Questions](/assets/images/questions.JPG =10x)

@title[return to main]

@size[1.2em](Return to Main Training Page)

Return to Training Table of contents for next presentation link

@snap[north span-30 ]

@snapend

---?image=assets/images/gitpitch-audience.jpg @title[Logo Slide]

![Logo Slide](/assets/images/TianocoreLogo.png =10x)

@title[Backup]

<p align="center"Backup

@title[Acknowledgements]

<p align="center"Acknowledgements

/**
Redistribution and use in source (original document form) and 'compiled' forms (converted
to PDF, epub, HTML and other formats) with or without modification, are permitted provided
that the following conditions are met:

Redistributions of source code (original document form) must retain the above copyright 
notice, this list of conditions and the following disclaimer as the first lines of this 
file unmodified.

Redistributions in compiled form (transformed to other DTDs, converted to PDF, epub, HTML
and other formats) must reproduce the above copyright notice, this list of conditions and 
the following disclaimer in the documentation and/or other materials provided with the 
distribution.

THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL TIANOCORE PROJECT BE 
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY 
OF SUCH DAMAGE.

Copyright (c) 2020, Intel Corporation. All rights reserved.
**/

---?image=assets/images/binary-strings-black2.jpg @title[Backup Section]

Backup

@title[EDK II vs. UDK]

EDK II vs. UDK(2010|2017 .. 2018)

@box[bg-blue text-white rounded](UEFI Developer's Kit 2018 (UDK2018) )
@box[bg-purple-pp text-white rounded](Stable build of the EDK II project )
@box[bg-brick text-white rounded](Neither contain Intel silicon or platform code)
wiki on tianocore.org: Differences between UDK - EDK II

Note:

The UEFI Developer's Kit 2010 (UDK2010) is an open-source driver & application development kit built on validated EDK II code
UDK2018 is a stable build of the EDK II project
Based on a snapshot of the EDK II project
Validated on a variety of Intel platforms
Validated with different OS & application software
The open-source EDK II & UDK2010 do not contain code for Intel silicon or platforms

Explain differences here so references later in the presentation make more sense.

UEFI Developer's Kit 2010 (UDK2018) = open-source driver & application development kit containing EDK II (second generation EFI development kit) validated common-core sample code. The open-source UDK2010 is a stable build of the EDK II project, and has been validated on a variety of Intel platforms, operating systems, and application software.

Intel® UEFI Developer’s Kit 2018 (Intel® UDK 2018, also called the Intel® UDK2018), Intel Corporation, 2018.

Files

PITCHME.md

Latest commit

History

PITCHME.md

File metadata and controls

UEFI & EDK II Training

EDK II Build Process

<p align="center"Lesson Objective

EDK II Overview

Philosophy of EDK II

Implementation of EDK II

Modules

Packages

EDK II Package Examples: Specs

Additional EDK II Package Examples:

Libraries

Libraries

Libraries

Libraries

Example - Library Debuglib

Platform Configuration Database (PCD)

Platform Configuration Database (PCD)

Platform Configuration Database (PCD)

EDK II Infrastructure Summary

Build Tools

Development Environment

Environment Variables

Configuration Files - Scripts

Build Process

Build Process Overview

Build Process Overview

Build Process Overview

Build Process Overview

Build Process Overview

Build Process Overview

Build Process Overview

Build Process Overview

Build Output Location

Build Output Location

Build Output Location

Build Output Location

Build Output Location

Build Output Location

Build Output Location

Build Output Location

Build Output Location

EDK II Build Process Stages

EDK II Build: AutoGen Stage

EDK II Build: Make Stage

EDK II Build: ImageGen Stage

Build Flow For OpROM

Build Flow For OpROM

Build Tool Binaries

<p align="center"Summary

<p align="center"Backup

<p align="center"Acknowledgements

Backup

EDK II vs. UDK(2010|2017 .. 2018)