diff options
| -rw-r--r-- | documentation/edk documentation/edk module writer guide | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/documentation/edk documentation/edk module writer guide b/documentation/edk documentation/edk module writer guide new file mode 100644 index 0000000..626b1d0 --- /dev/null +++ b/documentation/edk documentation/edk module writer guide @@ -0,0 +1,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 + ---------------------- + + + + + + |