some infos about edk modules

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
+		----------------------
+
+
+
+
+
+