mirror of https://github.com/acidanthera/audk.git
0a4aa20e8d
The AmlToHex script and Posix/WindowsLike wrappers convert an AML file to a .hex file, containing a C array storing AML bytecode. This ".hex" file can then be included in a C file, allowing to access the AML bytecode from this C file. The EDK2 build system doesn't allow to a depict dependency orders between files of different languages. For instance, in a module containing a ".c" file and a ".asl", the ".c" file may or may not be built prior to the ".asl" file. This prevents any inclusion of a generated ".hex" in a ".c" file since this later ".hex" file may or may not have been created yet. This patch modifies the AmlToC script to generate a C file instead of a ".hex" file. It also adds the generation of an intermediate ".amli" file when compiling an ASL file, and adds a rule to convert this ".amli" to a C file. This allows to generate a C file containing the AML bytecode from an ASL file. This C file will then be handled by the EDK2 build system to generate an object file. Thus, no file inclusion will be required anymore. The C file requiring the AML bytecode as a C array, and the ASL file, will be compiled independently. The C array must be defined as an external symbol. The linker is resolving the reference to the C array symbol. To summarize, the flow goes as: -1. ASL file is compiled to AML; -2. AML file is copied to a ".amli" intermediate file; -3. EDK2 build system applies the rule relevant to ".amli" files. This is, calling the "AmlToC" script, generating a C file from the ".amli" file; -4. EDK2 build system applies the rule relevant to C files. This is creating an object file. -5. EDK2 build system links the object file containing the AML bytecode with the object file requiring it. Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com> Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> |
||
---|---|---|
.. | ||
Bin | ||
BinWrappers | ||
Conf | ||
Plugin | ||
Scripts | ||
Source | ||
Tests | ||
UserManuals | ||
.gitignore | ||
BuildEnv | ||
Edk2ToolsBuild.py | ||
GNUmakefile | ||
Makefile | ||
ReadMe.txt | ||
basetools_calling_path_env.yaml | ||
basetools_path_env.yaml | ||
get_vsvars.bat | ||
set_vsprefix_envs.bat | ||
toolsetup.bat |
ReadMe.txt
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, other directory contains tools source. 1. Build step to generate the binary tools. === Windows/Visual Studio Notes === To build the BaseTools, you should run the standard vsvars32.bat script from your preferred Visual Studio installation or you can run get_vsvars.bat to use latest automatically detected version. In addition to this, you should set the following environment variables: * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree * BASE_TOOLS_PATH - The directory where the BaseTools source is located. (It is the same directory where this README.txt is located.) After this, you can run the toolsetup.bat file, which is in the same directory as this file. It should setup the remainder of the environment, and build the tools if necessary. Please also refer to the 'BuildNotes.txt' file for more information on building under Windows. === Unix-like operating systems === To build on Unix-like operating systems, you only need to type 'make' in the base directory of the project. === Ubuntu Notes === On Ubuntu, the following command should install all the necessary build packages to build all the C BaseTools: sudo apt-get install build-essential uuid-dev === Python sqlite3 module === On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen binary directory (the same directory as build.exe and GenFds.exe). Please copy it manually from <PythonHome>\DLLs. The Python distributed with most recent Linux will have sqlite3 module built in. If not, please install sqlit3 package separately. 26-OCT-2011