1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
EDK II Module Writer's Guide
March 2010
Revision 0.7
A package must contain a package metadata file (DEC), and possibly a platform metadata file (DSC). These metadata files and the module’s INF files are used by the EDK II build system to automatically generate makefiles and a single module tip or whole flash tip, according to the build options used. The FDF is only required if flash output is required.
1.1.3 EDK II Development Lifecycle
1.1.3.1 Phase 1: Create a package
------------------------------
Don't place into MdePkg, MdeModulePkg, IntelFrameworkPkg, IntelFrameworkModulePkg
DEC file to define the package's interfaces, including:
- include directories for modules from other packages
- value of GUIDs
- value of Protocol GUIDs
- value of PPI GUIDs
- declaration of the PCD entries published by this package
1.1.3.2 Phase 2: Create module metadata/Implement basic functionality
------------------------------------------------------------------
INF file to indicate the module's behaviour, including:
- module type
- required library classes
- required ppi/protocol/guid/PCD
- dependency relationship with other modules
1.1.3.3 Phase 3: Create DSC to build
---------------------------------
DSC describes build behaviour of the package, including:
- modules needed to be built
- chosen library instances for the various module type
- the configuration of the PCD entries used by modules
1.1.3.4 Phase 4: Tune modules
-----------------------
To tune modules
- use EDK II librries for code reuse
- use EDK II PCD mechanism for configuration
Note: In the EDK II module development, developers are strongly discouraged from
using a conditional macro to control procedure behavior. The PCD mechanism
provides a unified interface, and developers should use it to configure a module’s
behavior.
1.1.4 Build Infrastructure
------------------------
In brief, the EDK II build tool parses the metadata files (DSC, DECs, and INFs) to
generate corresponding one top-level makefile and a separate set of makefile and
autogen.c/autogen.h files for every module.
In the autogen files, the EDK II build tool generates all definitions of guids, protocols,
ppis, and PCDs used by the module, and automatically invokes all of the constructors
of used library instances in the module’s entry point implementations.
2.1.2 Package Directory
--------------------
Include: All public header
Library: Directories for each library instance included
Application: Directories for each UEFI application module included
Driver: Directories for each driver group and for each driver.
A module is not permitted to depend on source files from another module directory. Only depends on files under its directory or on public header files.
3.1 What is an EDK II module?
--------------------------
- A driver or application which is built to *.efi binary file and put into FFS file as EFI_PE_SECTION
- Raw data binary. For example, $(WORKSPACE)\MdeModulePkg\Logo\Logo.inf is a raw binary module which
contains logo bitmap image.
- An option ROM driver that is put into a device’s option ROM.
- A standalone UEFI driver
- A standalone UEFI application.
- A library instance that is built to a library object file (.lib) and statically linked to another module.
3.1.1 Module Types
--------------
UEFI_APPLICATION This module type is used by UEFI Applications that are compliant with the UEFI Specification.
UEFI Applications are always unloaded when they exit.
3.2.6.1 PCD Types
------------
EDK II provides the following types of PCDs:
Feature flag type PCD This PCD type replaces a switch MACRO to enable or disable a feature.
This is a Boolean value, and is either TRUE or FALSE.
Fixed at build type PCD This PCD type replaces a macro that produced a customizable value, such
as the PCI Express base address. The value of this PCD type is determined
at build time and is stored in the code section of a module’s PE image.
Patchable in module type PCD This PCD type is very similar to the fixed at build PCD type, but the value
is stored in the data section, rather than the code section, of the module’s
PE image.
Dynamic type PCD This PCD type is different from the other PCD types listed. The value is
assigned by one module and is accessed by other modules in execution
time. The PEIM PcdPeim and the DXE Driver PcdDXE each maintain a PCD
database that contains all dynamic PCD information used by platform in
their respective phase.
3.7.5 Build module image
----------------------
|
