]> git.proxmox.com Git - mirror_edk2.git/blobdiff - BaseTools/ReadMe.txt
Patch from open source community for CryptoPkg to allow it to build for ARM using...
[mirror_edk2.git] / BaseTools / ReadMe.txt
index 81c52ef773a18d3438f732f29723be2bfb7f6bfb..37691e98fd985b01d06e72ccb5347a1238ddf8aa 100644 (file)
 This directory contains the next generation of EDK II build tools and template files.\r
 Templates are located in the Conf directory, while the tools executables for\r
-Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory.\r
+Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other \r
+directory contatins tools source.\r
 \r
-The binary tools will be updated only after passing developer testing.\r
+1. Build step to generate the binary tools.\r
 \r
-The BaseTools package will be updated with new tools only after all testing on a set\r
-of binary tools has successfully completed.\r
+=== Windows/Visual Studio Notes ===\r
+\r
+To build the BaseTools, you should run the standard vsvars32.bat script.\r
+\r
+In addition to this, you should set the following environment variables:\r
+\r
+ * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree\r
+ * BASE_TOOLS_PATH - The directory where the BaseTools source is located.\r
+   (It is the same directory where this README.txt is located.)\r
+ * PYTHON_FREEZER_PATH - Path to where the python freezer tool is installed\r
+\r
+After this, you can run the toolsetup.bat file, which is in the same\r
+directory as this file.  It should setup the remainder of the environment,\r
+and build the tools if necessary.\r
+\r
+Please also refer to the 'BuildNotes.txt' file for more information on\r
+building under Windows.\r
+\r
+=== Unix-like operating systems ===\r
+\r
+To build on Unix-like operating systems, you only need to type 'make' in\r
+the base directory of the project.\r
+\r
+=== Ubuntu Notes ===\r
+\r
+On Ubuntu, the following command should install all the necessary build\r
+packages to build all the C BaseTools:\r
+\r
+  sudo apt-get install build-essentials uuid-dev\r
+\r
+=== Python sqlite3 module ===\r
+On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen \r
+binary directory (the same directory as build.exe and GenFds.exe). \r
+Please copy it manually from <PythonHome>\DLLs.\r
+\r
+The Python distributed with most recent Linux will have sqlite3 module\r
+built in. If not, please install sqlit3 package separately.\r
+\r
+2. The binary tools will be updated only after passing developer testing.\r
 \r
 Current state of the tools is Proto-Type - not all tool functions have been implemented\r
 and there may be bugs in these tools.  These tools are under constant development at\r
 this time.\r
 \r
-20-Jun-2007\r
+3. Tool usage introduction.\r
+BaseTools Simple Usage:\r
+1) Change the directory to the EDK2 root directory, where the edksetup.bat is\r
+2) Run "edksetup.bat NewBuild"\r
+3) Set the ACTIVE_PLATFORM to your desired platform description file \r
+   (%WORKSPACE%\Conf\target.txt)\r
+4) To build platform, run "build" command in non-module directory\r
+5) To build module individually, run "build" command in module directory, i.e. where the \r
+   *.inf file is\r
+\r
+Notes:\r
+1) The tree structure generated by build tools is similar to Ant build system.\r
+2) Makefile can be called directly by nmake for both top level platform and module. But\r
+   after you call "nmake cleanall", you have to call "build" command to rebuild platform\r
+        or modules because the AutoGen.* files have been be removed. The "makefile" itself\r
+        cannot generate AutoGen.* files. Only "build" command can.\r
+3) All .exe binary file including C and python tools are generated from:\r
+    r1911 <buildtools_project>\BaseTools\Source\.\r
+\r
+Brief usage for Migration Tool MigrationMsa2Inf.exe:\r
+1. Command line format:\r
+  MigrationMsa2Inf [options]\r
+2. Input Files:\r
+  A syntactically valid MSA file\r
+3. Output Files:\r
+  An extended INF file with possible auto-generated EntryPoint.c, CommonHeader.h/CommonHeader.txt, depending on options and module contents.\r
+4. Prerequisite:\r
+   a. The workspace directory must be specified either by environment variable or -w option.  \r
+   b. The Framework Database file must exist to specify the available packages in current workspace. \r
+      Two possible locations are: (The first location overrides the second)\r
+            $(WORKSPACE)\Tools\Conf\FrameworkDatabase.db\r
+            $(WORKSPACE)\Conf\FrameworkDatabase.db.  \r
+      The <PackageList> field in FrameworkDatabase.db lists all available packages in current workspace. \r
+      One example:\r
+      <PackageList>\r
+        <Filename>MdePkg/MdePkg.nspd</Filename>\r
+        <Filename>MdeModulePkg/MdeModulePkg.spd</Filename>\r
+        <Filename>IntelFrameworkPkg/IntelFrameworkPkg.spd</Filename>\r
+      </PackageList>\r
+      The package list in FrameworkDatabase.db is important to the final quality of migration:\r
+      (1) It suggests the new package location: Translate package dependency Guid in MSA to Workspace relative path. \r
+         If the package dependency Guid cannot be found in current workspace a warning message is raised. \r
+      (2) It collects the Protocol/Guid/Ppi GuidCName a package contains. \r
+         The GuidCName acts as "clue" to add e.g. #include <Protocol/DiskIo.h> in CommonHeader.h\r
+     \r
+5. Example:\r
+   WORKSAPCE has already been set: $(WORKSPACE) = c:\work\EdkII. \r
\r
+   a. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -o c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.inf\r
+   b. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -a\r
+   Example a & b are equivalent to migrate WinNtThunk driver from EDKII to EDKII' code base.\r
+  \r
+   c. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -a -c\r
+   The extra "-c" option performs several hardcode mapping due to the naming change in EDKII': \r
+      OldMdePkg Guid -> MdePkgGuid, \r
+      EdkModulePkg Guid -> MdeModulePkgGuid, \r
+      EdkGraphicsLib -> GraphicsLib\r
+      HiiLib -> HiiLibFramework\r
+      ...\r
+   \r
+   d. MigrationMsa2Inf -f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa -m\r
+   The extra "-m" option suppresses the generation of "CommonHeader.h" and leave all C files intact. \r
+   Instead, it generates "CommonHeader.txt". Developers can manually copy its content to a local common header file in a module. \r
\r
+6. Known Limitations:\r
+   a. Tool does not handle Exit Boot Services Callback & Virtual Address Changed Event. Developers need  to handle it manually.\r
+   b. The #include <Library/AbcLib.h> is based on library class naming convention: The header filename for "AbcLib" class are "AbcLib.h" by convention.\r
+   c. The #include <Guid/Xyz.h>, <Protocol/Xyz.h> and <Ppi/Xyz.h> are added based on gGuidCName listed in MSA. \r
+      If a GuidCName cannot map to a package Guid/Protocol/Ppi header file, a warning message is raised.\r
+      If a module uses the definition in a pakcage Guid/Protocol/Ppi header file without list its associative GuidCName, the build will beak. Developer needs to       manually add the include statement.\r
+   d. The [Depex] sections are generated from DXS files with Guid Macro translated to Guid CName by naming convention, etc.\r
+    If tool fails to "guess" the Guid CName from Guid Macro, it will leave the GuidMacro in [Depex] section for manual resolution.\r
+   e. When tool generates [Sources] section, the modifiers for source files are lost. (Need to add proper tool chain, etc)\r
+   f. When tool generates [LibraryClasses] section, the recommended library instances are lost. (No impact to build)\r
\r
+7. Pyton Source\r
+   BaseTools\Source\Python\MigrationMsa2Inf\r
+\r
+Brief usage for Migration Tool Spd2Dec.exe:\r
+1. Command line format:\r
+  Spd2Dec [options] input_filename\r
+2. Input File:\r
+  A syntactically valid SPD file\r
+3. Output Files:\r
+  A DEC file whose syntax confirms to DEC spec.\r
+     \r
+4. Example:\r
+   a. Spd2Dec -o c:\work\EdkII\Nt32Pkg\Nt32.spd c:\work\EdkII\Nt32Pkg\Nt32.dec\r
+   b. Spd2Dec -a c:\work\EdkII\Nt32Pkg\Nt32.spd\r
+   Example a & b are equivalent to migrate Nt32 package SPD file from EDKII to EDKII' snytax.\r
+  \r
+6. Pyton Source\r
+   BaseTools\Source\Python\spd2dec\r
+\r
+Brief usage for Migration Tool Fpd2Dsc.exe:\r
+1. Command line format:\r
+  Fpd2Dsc [options] input_filename\r
+2. Input File:\r
+  A syntactically valid FPD file\r
+3. Output Files:\r
+  A DSC file which syntax confirms to DSC spec.\r
+4. Prerequisite:\r
+   a. The workspace directory must be specified either by environment variable or -w option.\r
+     \r
+5. Example:\r
+   WORKSAPCE has already been set: $(WORKSPACE) = c:\work\EdkII. \r
\r
+   a. Fpd2Dsc -o c:\work\EdkII\Nt32Pkg\Nt32.dsc c:\work\EdkII\Nt32Pkg\Nt32.fpd\r
+   b. Fpd2Dsc -a c:\work\EdkII\Nt32Pkg\Nt32.fpd\r
+   Example a & b are equivalent to migrate Nt32 platform description file from EDKII to EDKII' snytax.\r
+  \r
+6. Known Limitations:\r
+   a. Tool does not handle Libraries Section since no related info in original FPD file. Developers need  to handle it manually in the output DSC file.\r
+   b. If MSA file which is corresponds to module guid could not be found in currect workspace, tool will dump the module guid.\r
\r
+7. Pyton Source\r
+   BaseTools\Source\Python\fpd2dsc\r
+\r
+4-Mar-2010\r