mirror of https://github.com/acidanthera/audk.git
96 lines
5.6 KiB
Plaintext
96 lines
5.6 KiB
Plaintext
This directory contains the next generation of EDK II build tools and template files.
|
||
Templates are located in the Conf directory, while the tools executables for
|
||
Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory.
|
||
|
||
The binary tools will be updated only after passing developer testing.
|
||
|
||
The BaseTools package will be updated with new tools only after all testing on a set
|
||
of binary tools has successfully completed.
|
||
|
||
Current state of the tools is Proto-Type - not all tool functions have been implemented
|
||
and there may be bugs in these tools. These tools are under constant development at
|
||
this time.
|
||
|
||
BaseTools Simple Usage:
|
||
1) Change the directory to the EDK2 root directory, where the edksetup.bat is
|
||
2) Run "edksetup.bat NewBuild"
|
||
3) Set the ACTIVE_PLATFORM to your desired platform description file
|
||
(%WORKSPACE%\Conf\target.txt)
|
||
4) To build platform, run "build" command in non-module directory
|
||
5) To build module individually, run "build" command in module directory, i.e. where the
|
||
*.inf file is
|
||
|
||
Notes:
|
||
1) Only *.efi files can be generated. Flash image cannot be generated at present.
|
||
2) Only "clean" and "cleanall" build target are supported, in both top level
|
||
makefile and module's makefile.
|
||
3) Not all tool chains and target architectures are tested. Due to both tools
|
||
and source code limitations, ther must be bugs in it. Please report any issue
|
||
ASAP so we can fix it soon.
|
||
4) The tree structure generated by build tools is similar to Ant build system.
|
||
5) Makefile can be called directly by nmake for both top level platform and module. But
|
||
after you call "nmake cleanall", you have to call "build" command to rebuild platform
|
||
or modules because the AutoGen.* files have been be removed. The "makefile" itself
|
||
cannot generate AutoGen.* files. Only "build" command can.
|
||
|
||
|
||
Brief usage for Module Migration Tool msa2inf.exe:
|
||
1. Command line format:
|
||
msa2inf [options]
|
||
2. Input Files:
|
||
A syntactically valid MSA file
|
||
3. Output Files:
|
||
An extended INF file with possible auto-generated EntryPoint.c, CommonHeader.h/CommonHeader.txt, depending on options and module contents.
|
||
4. Prerequisite:
|
||
a. The workspace directory must be specified either by environment variable or <20>w option.
|
||
b. The Framework Database file must exist to specify the available packages in current workspace.
|
||
Two possible locations are: (The first location overrides the second)
|
||
$(WORKSPACE)\Tools\Conf\FrameworkDatabase.db
|
||
$(WORKSPACE)\Conf\FrameworkDatabase.db.
|
||
The <PackageList> field in FrameworkDatabase.db lists all available packages in current workspace.
|
||
One example:
|
||
<PackageList>
|
||
<Filename>MdePkg/MdePkg.nspd</Filename>
|
||
<Filename>MdeModulePkg/MdeModulePkg.spd</Filename>
|
||
<Filename>IntelFrameworkPkg/IntelFrameworkPkg.spd</Filename>
|
||
</PackageList>
|
||
The package list in FrameworkDatabase.db is important to the final quality of migration:
|
||
(1) It suggests the new package location: Translate package dependency Guid in MSA to Workspace relative path.
|
||
If the package dependency Guid cannot be found in current workspace a warning message is raised.
|
||
(2) It collects the Protocol/Guid/Ppi GuidCName a package contains.
|
||
The GuidCName acts as "clue" to add e.g. #include <Protocol/DiskIo.h> in CommonHeader.h
|
||
|
||
5. Example:
|
||
WORKSAPCE has already been set: $(WORKSPACE) = c:\work\EdkII.
|
||
|
||
a. msa2inf <20>f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa <20>o c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.inf
|
||
b. msa2inf <20>f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa <20>a
|
||
Example a & b are equivalent to migrate WinNtThunk driver from EDKII to EDKII' code base.
|
||
|
||
c. msa2inf <20>f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa <20>a -c
|
||
The extra "-c" option performs several hardcode mapping due to the naming change in EDKII<49>:
|
||
OldMdePkg Guid -> MdePkgGuid,
|
||
EdkModulePkg Guid -> MdeModulePkgGuid,
|
||
EdkGraphicsLib -> GraphicsLib
|
||
HiiLib -> HiiLibFramework
|
||
...
|
||
|
||
d. msa2inf <20>f c:\work\EdkII\Nt32Pkg\WinNtThunkDxe\WinNtThunk.msa <20>m
|
||
The extra "-m" option suppresses the generation of "CommonHeader.h" and leave all C files intact.
|
||
Instead, it generates "CommonHeader.txt". Developers can manually copy its content to a local common header file in a module.
|
||
|
||
6. Known Limitations:
|
||
a. Tool does not Exit Boot Services Callback & Virtual Address Changed Event. Developers need to handle it manually.
|
||
b. The #include <Library/AbcLib.h> is based on library class naming convention: The header filename for "AbcLib" class are "AbcLib.h" by convention.
|
||
c. The #include <Guid/Xyz.h>, <Protocol/Xyz.h> and <Ppi/Xyz.h> are added based on gGuidCName listed in MSA.
|
||
If a GuidCName cannot map to a package Guid/Protocol/Ppi header file, a warning message is raised.
|
||
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.
|
||
d. The [Depex] sections are generated from DXS files with Guid Macro translated to Guid CName by naming convention, etc.
|
||
If tool fails to "guess" the Guid CName from Guid Macro, it will leave the GuidMacro in [Depex] section for manual resolution.
|
||
e. When tool generates [Sources] section, the modifiers for source files are lost. (Need to add proper tool chain, etc)
|
||
f. When tool generates [LibraryClasses] section, the recommended library instances are lost. (No impact to build)
|
||
|
||
|
||
|
||
13-August-2007
|