]>
Commit | Line | Data |
---|---|---|
056b0f1b | 1 | # Dynamic Tables Framework\r |
dacba2b2 SM |
2 | \r |
3 | Dynamic Tables Framework provides mechanisms to reduce the amount\r | |
4 | of effort required in porting firmware to new platforms. The aim is\r | |
5 | to provide an implementation capable of generating the firmware\r | |
6 | tables from an external source. This is potentially a management\r | |
7 | node, either local or remote, or, where suitable, a file that might\r | |
8 | be generated from the system construction. This initial release\r | |
9 | does not fully implement that - the configuration is held in local\r | |
10 | UEFI modules.\r | |
11 | \r | |
056b0f1b SM |
12 | # Feature Summary\r |
13 | \r | |
dacba2b2 SM |
14 | The dynamic tables framework is designed to generate standardised\r |
15 | firmware tables that describe the hardware information at\r | |
16 | run-time. A goal of standardised firmware is to have a common\r | |
17 | firmware for a platform capable of booting both Windows and Linux\r | |
18 | operating systems.\r | |
19 | \r | |
20 | Traditionally the firmware tables are handcrafted using ACPI\r | |
21 | Source Language (ASL), Table Definition Language (TDL) and\r | |
22 | C-code. This approach can be error prone and involves time\r | |
23 | consuming debugging. In addition, it may be desirable to configure\r | |
24 | platform hardware at runtime such as: configuring the number of\r | |
25 | cores available for use by the OS, or turning SoC features ON or\r | |
26 | OFF.\r | |
27 | \r | |
28 | The dynamic tables framework simplifies this by providing a set\r | |
29 | of standard table generators, that are implemented as libraries.\r | |
30 | These generators query a platform specific component, the\r | |
31 | 'Configuration Manager', to collate the information required\r | |
32 | for generating the tables at run-time.\r | |
33 | \r | |
34 | The framework also provides the ability to implement custom/OEM\r | |
35 | generators; thereby facilitating support for custom tables. The\r | |
36 | custom generators can also utilize the existing standard generators\r | |
37 | and override any functionality if needed.\r | |
38 | \r | |
39 | The framework currently implements a set of standard ACPI table\r | |
40 | generators for ARM architecture, that can generate Server Base Boot\r | |
41 | Requirement (SBBR) compliant tables. Although, the set of standard\r | |
42 | generators implement the functionality required for ARM architecture;\r | |
43 | the framework is extensible, and support for other architectures can\r | |
44 | be added easily.\r | |
45 | \r | |
46 | The framework currently supports the following table generators for ARM:\r | |
47 | * DBG2 - Debug Port Table 2\r | |
48 | * DSDT - Differentiated system description table. This is essentially\r | |
49 | a RAW table generator.\r | |
50 | * FADT - Fixed ACPI Description Table\r | |
51 | * GTDT - Generic Timer Description Table\r | |
52 | * IORT - IO Remapping Table\r | |
53 | * MADT - Multiple APIC Description Table\r | |
54 | * MCFG - PCI Express memory mapped configuration space base address\r | |
55 | Description Table\r | |
56 | * SPCR - Serial Port Console Redirection Table\r | |
57 | * SSDT - Secondary System Description Table. This is essentially\r | |
58 | a RAW table generator.\r | |
59 | \r | |
056b0f1b SM |
60 | ## Dynamic AML\r |
61 | \r | |
62 | ACPI Definition block (e.g. DSDT or SSDT) tables are used to describe system\r | |
63 | devices along with other control and power management information. These tables\r | |
64 | are written using ACPI Source Language (ASL). The ASL code is compiled using an\r | |
65 | ASL compiler (e.g. Intel iASL compiler) to generate ACPI Machine Language (AML)\r | |
66 | bytecode.\r | |
67 | \r | |
68 | Since, definition blocks are represented using AML grammar, run-time generation\r | |
69 | of definition blocks is complex. Dynamic AML is a feature of Dynamic Tables\r | |
70 | framework that provides a solution for dynamic generation of ACPI Definition\r | |
71 | block tables.\r | |
72 | \r | |
73 | Dynamic AML introduces the following techniques:\r | |
74 | * AML Fixup\r | |
75 | * AML Codegen\r | |
76 | * AML Fixup + Codegen\r | |
77 | \r | |
78 | ### AML Fixup\r | |
79 | AML fixup is a technique that involves compiling an ASL template file to\r | |
80 | generate AML bytecode. This template AML bytecode can be parsed at run-time\r | |
81 | and a fixup code can update the required fields in the AML template.\r | |
82 | \r | |
83 | To simplify AML Fixup, the Dynamic Tables Framework provides an *AmlLib*\r | |
84 | library with a rich set of APIs that can be used to fixup the AML code.\r | |
85 | \r | |
86 | ### AML Codegen\r | |
87 | AML Codegen employs generating small segments of AML code. The *AmlLib*\r | |
88 | library provides AML Codegen APIs that generate the AML code segments.\r | |
89 | \r | |
90 | Example: The following table depicts the AML Codegen APIs and the\r | |
91 | corresponding ASL code that would be generated.\r | |
92 | \r | |
93 | | AML Codegen API | ASL Code |\r | |
94 | |--------------------------------|--------------------------------|\r | |
95 | | AmlCodeGenDefinitionBlock ( | DefinitionBlock ( |\r | |
96 | | .., | ... |\r | |
97 | | &RootNode); | ) { |\r | |
98 | | AmlCodeGenScope ( | Scope (_SB) { |\r | |
99 | | "\_SB", | |\r | |
100 | | RootNode, | |\r | |
101 | | &ScopeNode); | |\r | |
102 | | AmlCodeGenDevice ( | Device (CPU0) { |\r | |
103 | | "CPU0", | |\r | |
104 | | ScopeNode, | |\r | |
105 | | &CpuNode); | |\r | |
106 | | AmlCodeGenNameString ( | Name (_HID, "ACPI0007") |\r | |
107 | | "_HID", | |\r | |
108 | | "ACPI0007", | |\r | |
109 | | CpuNode, | |\r | |
110 | | &HidNode); | |\r | |
111 | | AmlCodeGenNameInteger ( | Name (_UID, Zero) |\r | |
112 | | "_UID", | |\r | |
113 | | 0, | |\r | |
114 | | CpuNode, | |\r | |
115 | | &UidNode); | |\r | |
116 | | | } // Device |\r | |
117 | | | } // Scope |\r | |
118 | | | } // DefinitionBlock |\r | |
119 | \r | |
120 | ### AML Fixup + Codegen\r | |
121 | A combination of AML Fixup and AML Codegen could be used for generating\r | |
122 | Definition Blocks. For example the AML Fixup could be used to fixup certain\r | |
123 | parts of the AML template while the AML Codegen APIs could be used to inserted\r | |
124 | small fragments of AML code in the AML template.\r | |
125 | \r | |
126 | ### AmlLib Library\r | |
127 | Since, AML bytecode represents complex AML grammar, an **AmlLib** library is\r | |
128 | introduced to assist parsing and traversing of the AML bytecode at run-time.\r | |
129 | \r | |
130 | The AmlLib library parses a definition block and represents it as an AML\r | |
131 | tree. This tree representation is based on the AML grammar defined by the\r | |
132 | ACPI 6.3 specification, section - 20 'ACPI Machine Language (AML)\r | |
133 | Specification'.\r | |
134 | \r | |
135 | AML objects, methods and data are represented as tree nodes. Since the AML\r | |
136 | data is represented as tree nodes, it is possible to traverse the tree, locate\r | |
137 | a node and modify the node data. The tree can then be serialized to a buffer\r | |
138 | (that represents the definition block). This definition block containing\r | |
139 | the fixed up AML code can then be installed as an ACPI table (DSDT/SSDT).\r | |
140 | \r | |
141 | AmlLib provides a rich API to operate on AML data. For example it provides\r | |
142 | APIs to update a device's name, the value of a "_UID" object, and the memory\r | |
143 | and interrupt number stored in a "_CRS" node.\r | |
144 | \r | |
145 | Although the AmlLib performs checks to a reasonable extent while modifying a\r | |
146 | definition block, these checks may not cover all aspects due to the complexity\r | |
147 | of the ASL/AML language. It is therefore recommended to review any operation\r | |
148 | performed, and validate the generated output.\r | |
149 | \r | |
150 | Example: The serialized AML code could be validated by\r | |
151 | - Saving the generated AML to a file and comparing with\r | |
152 | a reference output.\r | |
153 | or\r | |
154 | - Disassemble the generated AML using the iASL compiler\r | |
155 | and verifying the output.\r | |
156 | \r | |
157 | # Roadmap\r | |
158 | \r | |
dacba2b2 SM |
159 | The current implementation of the Configuration Manager populates the\r |
160 | platform information statically as a C structure. Further enhancements\r | |
161 | to introduce runtime loading of platform information from a platform\r | |
162 | information file is planned.\r | |
163 | \r | |
164 | Also support for generating SMBIOS tables is planned and will be added\r | |
165 | subsequently.\r | |
166 | \r | |
056b0f1b SM |
167 | # Supported Platforms\r |
168 | \r | |
dacba2b2 SM |
169 | 1. Juno\r |
170 | 2. FVP Models\r | |
171 | \r | |
056b0f1b SM |
172 | # Build Instructions\r |
173 | \r | |
dacba2b2 SM |
174 | 1. Set path for the iASL compiler with support for generating a C header\r |
175 | file as output.\r | |
176 | \r | |
177 | 2. Set PACKAGES_PATH to point to the locations of the following repositories:\r | |
178 | \r | |
179 | Example:\r | |
180 | \r | |
181 | > set PACKAGES_PATH=%CD%\edk2;%CD%\edk2-platforms;\r | |
182 | \r | |
183 | or\r | |
184 | \r | |
185 | > export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms\r | |
186 | \r | |
187 | 3. To enable Dynamic tables framework the *'DYNAMIC_TABLES_FRAMEWORK'*\r | |
188 | option must be defined. This can be passed as a command line\r | |
189 | parameter to the edk2 build system.\r | |
190 | \r | |
191 | Example:\r | |
192 | \r | |
193 | >build -a AARCH64 -p Platform\ARM\JunoPkg\ArmJuno.dsc\r | |
194 | -t GCC5 **-D DYNAMIC_TABLES_FRAMEWORK**\r | |
195 | \r | |
196 | or\r | |
197 | \r | |
198 | >build -a AARCH64 -p Platform\ARM\VExpressPkg\ArmVExpress-FVP-AArch64.dsc\r | |
199 | -t GCC5 **-D DYNAMIC_TABLES_FRAMEWORK**\r | |
200 | \r | |
056b0f1b SM |
201 | # Prerequisites\r |
202 | \r | |
b88d95bb PG |
203 | Ensure that the latest ACPICA iASL compiler is used for building *Dynamic Tables Framework*.\r |
204 | *Dynamic Tables Framework* has been tested using the following iASL compiler version:\r | |
056b0f1b | 205 | [Version 20200717](https://www.acpica.org/node/183), dated 17 July, 2020.\r |
dacba2b2 | 206 | \r |
2d0c42fd | 207 | \r |
056b0f1b | 208 | #Running CI builds locally\r |
2d0c42fd SM |
209 | \r |
210 | The TianoCore EDKII project has introduced Core CI infrastructure using TianoCore EDKII Tools PIP modules:\r | |
211 | \r | |
212 | - *[edk2-pytool-library](https://pypi.org/project/edk2-pytool-library)*\r | |
213 | \r | |
214 | - *[edk2-pytool-extensions](https://pypi.org/project/edk2-pytool-extensions)*\r | |
215 | \r | |
216 | \r | |
217 | The instructions to setup the CI environment are in *'edk2\\.pytool\\Readme.md'*\r | |
218 | \r | |
219 | ## Building DynamicTablesPkg with Pytools\r | |
220 | \r | |
221 | 1. [Optional] Create a Python Virtual Environment - generally once per workspace\r | |
222 | \r | |
223 | ```\r | |
224 | python -m venv <name of virtual environment>\r | |
225 | \r | |
226 | e.g. python -m venv edk2-ci\r | |
227 | ```\r | |
228 | \r | |
229 | 2. [Optional] Activate Virtual Environment - each time new shell/command window is opened\r | |
230 | \r | |
231 | ```\r | |
232 | <name of virtual environment>/Scripts/activate\r | |
233 | \r | |
234 | e.g. On a windows host PC run:\r | |
235 | edk2-ci\Scripts\activate.bat\r | |
236 | ```\r | |
237 | 3. Install Pytools - generally once per virtual env or whenever pip-requirements.txt changes\r | |
238 | \r | |
239 | ```\r | |
240 | pip install --upgrade -r pip-requirements.txt\r | |
241 | ```\r | |
242 | \r | |
243 | 4. Initialize & Update Submodules - only when submodules updated\r | |
244 | \r | |
245 | ```\r | |
246 | stuart_setup -c .pytool/CISettings.py TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>\r | |
247 | \r | |
248 | e.g. stuart_setup -c .pytool/CISettings.py TOOL_CHAIN_TAG=GCC5\r | |
249 | ```\r | |
250 | \r | |
251 | 5. Initialize & Update Dependencies - only as needed when ext_deps change\r | |
252 | \r | |
253 | ```\r | |
254 | stuart_update -c .pytool/CISettings.py TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>\r | |
255 | \r | |
256 | e.g. stuart_update -c .pytool/CISettings.py TOOL_CHAIN_TAG=GCC5\r | |
257 | ```\r | |
258 | \r | |
259 | 6. Compile the basetools if necessary - only when basetools C source files change\r | |
260 | \r | |
261 | ```\r | |
262 | python BaseTools/Edk2ToolsBuild.py -t <ToolChainTag>\r | |
263 | ```\r | |
264 | \r | |
265 | 7. Compile DynamicTablesPkg\r | |
266 | \r | |
267 | ```\r | |
268 | stuart_build-c .pytool/CISettings.py TOOL_CHAIN_TAG=<TOOL_CHAIN_TAG> -a <TARGET_ARCH>\r | |
269 | \r | |
270 | e.g. stuart_ci_build -c .pytool/CISettings.py TOOL_CHAIN_TAG=GCC5 -p DynamicTablesPkg -a AARCH64 --verbose\r | |
271 | ```\r | |
272 | \r | |
273 | - use `stuart_build -c .pytool/CISettings.py -h` option to see help on additional options.\r | |
274 | \r | |
275 | \r | |
056b0f1b | 276 | # Documentation\r |
dacba2b2 SM |
277 | \r |
278 | Refer to the following presentation from *UEFI Plugfest Seattle 2018*:\r | |
279 | \r | |
e3f8605a | 280 | [Dynamic Tables Framework: A Step Towards Automatic Generation of Advanced Configuration and Power Interface (ACPI) & System Management BIOS (SMBIOS) Tables](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic%20Tables%20Framework%20A%20Step%20Towards%20Automatic%20Generation%20of%20Advanced%20Configuration%20and%20Power%20Interface%20%28ACPI%29%20%26%20System%20Management%20BIOS%20%28SMBIOS%29%20Tables%20_0.pdf)\r |
2d0c42fd | 281 | \r |