b1fe77c9 |
1 | ##\r |
2 | # This file is used to document mismatches between Intel Platform Innovation Framework specification\r |
3 | # (http://www.intel.com/technology/framework/spec.htm) and data structures defind at IntelFrameworkPkg\r |
4 | # package in EdkII Open Source Project (https://edk2.tianocore.org/source/browse/edk2/trunk/edk2/IntelFrameworkPkg)\r |
5 | ##\r |
6 | \r |
7 | ##\r |
8 | # The general consideration about keeping the mismatches in EdkII:\r |
9 | # 1. Some definitions defined in Framework specification may bring a little complexity on implementation. EdkII\r |
10 | # makes changes on them from the view of code development.\r |
11 | # 2. Some definitions are NOT defined in Framework specification, but introduced in Edk. EdkII chooses to keep\r |
12 | # them for backward-compatibility.\r |
13 | # 3. The name of some definitions are NOT consistent with Framework specification. If the name doesn't bring\r |
14 | # misunderstanding literally, EdkII chooses to keep them for backward-compatibility.\r |
15 | # 4. Some defintitions don't exactly match Framework specification, some new field members are introduced in EdkII\r |
16 | # to reflect the latest industry standard.\r |
17 | #\r |
18 | # Note: \r |
19 | # The IntelFrameworkPkg contains Framework specification contents that were not adopted by UEFI/PI, and names may be\r |
20 | # changed (such as adding "FRAMEWORK_") to avoid name collisions with approved UEFI/PI specifications.\r |
21 | ##\r |
22 | \r |
23 | ##\r |
24 | # Mismatch with Intel Platform Innovation Framework for DataHubSubclass Specification (Version 0.90)\r |
25 | ##\r |
26 | 1. Guid/DataHubRecords.h\r |
27 | #define EFI_STRING_TOKEN UINT16\r |
28 | \r |
29 | This macro named "EFI_STRING_TOKEN" is *NOT* defined in Framework specification. Keeping this inconsistency\r |
30 | for backward compatibility.\r |
31 | \r |
32 | 2. Guid/DataHubRecords.h\r |
33 | #pragma pack(1)\r |
34 | typedef struct {\r |
35 | UINT8 LastPciBus;\r |
36 | } EFI_MISC_LAST_PCI_BUS_DATA;\r |
37 | ...\r |
38 | typedef struct {\r |
39 | EFI_SUBCLASS_TYPE1_HEADER Header;\r |
40 | EFI_MISC_SUBCLASS_RECORDS Record;\r |
41 | } EFI_MISC_SUBCLASS_DRIVER_DATA;\r |
42 | #pragma pack()\r |
43 | \r |
44 | Section "Alignment" in DataHubSubclass specification say "Fields in a data hub record should be aligned at their\r |
45 | natural boundaries". But in EdkII, the data structures above are packed. \r |
46 | Keeping this inconsistency for backward compatibility.\r |
47 | \r |
48 | 3. Guid/DataHubRecords.h\r |
49 | #define EFI_SUBCLASS_INSTANCE_RESERVED 0\r |
50 | #define EFI_SUBCLASS_INSTANCE_NON_APPLICABLE 0xFFFF\r |
51 | \r |
52 | The symbols above are *NOT* defined in DataHubSubclass specification. But the values are defined and are meaningful.\r |
53 | According to DataHubSubclass spec, value 0 means Reserved and -1 means Not Applicable. EdkII introduces these macros\r |
54 | to faciliate user development.\r |
55 | \r |
56 | ##\r |
57 | # Mismatch with Intel Platform Innovation Framework for CacheSubclass Specification (Version 0.90)\r |
58 | ##\r |
59 | 1. Guid/DataHubRecords.h\r |
60 | typedef EFI_EXP_BASE2_DATA EFI_MAXIMUM_CACHE_SIZE_DATA;\r |
61 | \r |
62 | The definition named "EFI_MAXIMUM_CACHE_SIZE_DATA" is *NOT* consistent with CacheSubclass specification, in which\r |
63 | the name should be EFI_CACHE_MAXIMUM_SIZE_DATA. Keeping this inconsistency for backward compatibility.\r |
64 | \r |
65 | 2. Guid/DataHubRecords.h\r |
66 | typedef struct {\r |
67 | UINT32 Level :3;\r |
68 | UINT32 Socketed :1;\r |
69 | UINT32 Reserved2 :1;\r |
70 | UINT32 Location :2;\r |
71 | UINT32 Enable :1;\r |
72 | UINT32 OperationalMode :2;\r |
73 | UINT32 Reserved1 :22;\r |
74 | } EFI_CACHE_CONFIGURATION_DATA;\r |
75 | \r |
76 | The field type of the definition is *NOT* consistent with CacheSubclass specification. Specification defines\r |
77 | them as UINT16, which is incorrect and should be UINT32 because the total width of bit-fields is 32bits width.\r |
78 | \r |
79 | 3. Guid/DataHubRecords.h\r |
80 | typedef enum {\r |
81 | CacheSizeRecordType = 1,\r |
82 | MaximumSizeCacheRecordType = 2,\r |
83 | CacheSpeedRecordType = 3,\r |
84 | CacheSocketRecordType = 4,\r |
85 | CacheSramTypeRecordType = 5,\r |
86 | CacheInstalledSramTypeRecordType = 6,\r |
87 | CacheErrorTypeRecordType = 7,\r |
88 | CacheTypeRecordType = 8,\r |
89 | CacheAssociativityRecordType = 9,\r |
90 | CacheConfigRecordType = 10\r |
91 | } EFI_CACHE_VARIABLE_RECORD_TYPE;\r |
92 | \r |
93 | The data structure and all enumeration fields are *NOT* defined in CacheSubclass specification, which only\r |
94 | defines the following macros to specify the record number of the data record:\r |
95 | #define EFI_CACHE_SIZE_RECORD_NUMBER 0x00000001\r |
96 | #define EFI_CACHE_MAXIMUM_SIZE_RECORD_NUMBER 0x00000002\r |
97 | #define EFI_CACHE_SPEED_RECORD_NUMBER 0x00000003\r |
98 | #define EFI_CACHE_SOCKET_RECORD_NUMBER 0x00000004\r |
99 | #define EFI_CACHE_SRAM_SUPPORT_RECORD_NUMBER 0x00000005 \r |
100 | #define EFI_CACHE_SRAM_INSTALL_RECORD_NUMBER 0x00000006 \r |
101 | #define EFI_CACHE_ERROR_SUPPORT_RECORD_NUMBER 0x00000007\r |
102 | #define EFI_CACHE_TYPE_RECORD_NUMBER 0x00000008\r |
103 | #define EFI_CACHE_ASSOCIATIVITY_RECORD_NUMBER 0x00000009\r |
104 | #define EFI_CACHE_CONFIGURATION_RECORD_NUMBER 0x0000000A\r |
105 | Keeping this inconsistency for backward compatibility.\r |
106 | \r |
107 | 4. Guid/DataHubRecords.h\r |
108 | typedef union {\r |
109 | EFI_CACHE_SIZE_DATA CacheSize;\r |
110 | ...\r |
111 | EFI_CACHE_ASSOCIATION_DATA CacheAssociation;\r |
112 | } EFI_CACHE_VARIABLE_RECORD;\r |
113 | \r |
114 | typedef struct {\r |
115 | EFI_SUBCLASS_TYPE1_HEADER DataRecordHeader;\r |
116 | EFI_CACHE_VARIABLE_RECORD VariableRecord;\r |
117 | } EFI_CACHE_DATA_RECORD;\r |
118 | \r |
119 | The definitions above are *NOT* defined in CacheSubclass specification. EdkII introduces them to simplify the\r |
120 | code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r |
121 | Keeping this inconsistency for backward compatibility.\r |
122 | \r |
123 | ##\r |
124 | # Mismatch with Intel Platform Innovation Framework for ProcSubclass Specification (Version 0.90)\r |
125 | ##\r |
126 | 1. Guid/DataHubRecords.h\r |
127 | #define EFI_PROCESSOR_SUBCLASS_VERSION 0x00010000\r |
128 | \r |
129 | The value of the definition is *NOT* consistent with ProcSubclass specification, in which the value is 0x0100.\r |
130 | Keeping this inconsistency from the perspective of binary consistency.\r |
131 | \r |
132 | 2. Guid/DataHubRecords.h\r |
133 | typedef struct {\r |
134 | UINT32 ProcessorBrandIndex :8;\r |
135 | UINT32 ProcessorClflush :8;\r |
136 | UINT32 ProcessorReserved :8;\r |
137 | UINT32 ProcessorDfltApicId :8;\r |
138 | } EFI_PROCESSOR_MISC_INFO;\r |
139 | \r |
140 | The definition is *NOT* consistent with ProcSubclass specification, in which the name of third field is defined\r |
141 | as "LogicalProcessorCount" rather than "ProcessorReserved".\r |
142 | Keeping this inconsistency for backward compatibility.\r |
143 | \r |
144 | 3. Guid/DataHubRecords.h\r |
145 | typedef enum {\r |
146 | ...\r |
147 | EfiProcessorFamilyUltraSparcIIIi = 0x58,\r |
148 | ...\r |
149 | EfiProcessorFamilyIntelPentiumM = 0xB9,\r |
150 | EfiProcessorFamilyIntelCeleronD = 0xBA,\r |
151 | EfiProcessorFamilyIntelPentiumD = 0xBB,\r |
152 | EfiProcessorFamilyIntelPentiumEx = 0xBC,\r |
153 | EfiProcessorFamilyIntelCoreSolo = 0xBD, \r |
154 | EfiProcessorFamilyReserved = 0xBE, \r |
155 | EfiProcessorFamilyIntelCore2 = 0xBF,\r |
156 | ...\r |
157 | EfiProcessorFamilyG6 = 0xCB,\r |
158 | EfiProcessorFamilyzArchitectur = 0xCC,\r |
159 | EfiProcessorFamilyViaC7M = 0xD2,\r |
160 | EfiProcessorFamilyViaC7D = 0xD3,\r |
161 | EfiProcessorFamilyViaC7 = 0xD4,\r |
162 | EfiProcessorFamilyViaEden = 0xD5,\r |
163 | ...\r |
164 | EfiProcessorFamilyIndicatorFamily2 = 0xFE,\r |
165 | EfiProcessorFamilyReserved1 = 0xFF\r |
166 | } EFI_PROCESSOR_FAMILY_DATA;\r |
167 | \r |
168 | a. In ProcSubclass specification 0.9, the field name whose value equals to 0x58 is "EfiProcessorFamilyUltraSparcIIi".\r |
169 | Due to the name has been defined in previous field, changing it to "EfiProcessorFamilyUltraSparcIIIi" to avoid\r |
170 | build break.\r |
171 | b. The other fields listed here are *NOT* defined in ProcSubclass specification 0.9. They are introduced to\r |
172 | support new processor family (type 4) defined in SmBios 2.6 specification.\r |
173 | Keeping this inconsistency to reflect the latest industry standard.\r |
174 | \r |
175 | 4. Guid/DataHubRecords.h\r |
176 | typedef enum {\r |
177 | ...\r |
178 | EfiProcessorSocket939 = 0x12,\r |
179 | EfiProcessorSocketmPGA604 = 0x13,\r |
180 | EfiProcessorSocketLGA771 = 0x14,\r |
181 | EfiProcessorSocketLGA775 = 0x15\r |
182 | } EFI_PROCESSOR_SOCKET_TYPE_DATA;\r |
183 | \r |
184 | The fields listed here are *NOT* defined in ProcSubclass specification 0.9. They are introduced to support\r |
185 | new processor upgrade (type 4 offset 19h) defined in SmBios 2.6 specification. \r |
186 | Keeping this inconsistency to reflect the latest industry standard.\r |
187 | \r |
188 | 5. Guid/DataHubRecords.h\r |
189 | typedef EFI_INTER_LINK_DATA EFI_CACHE_ASSOCIATION_DATA;\r |
190 | \r |
191 | The definition name "EFI_CACHE_ASSOCIATION_DATA" is *NOT* consistent with ProcSubclass specification 0.9, in which\r |
192 | the name should be "EFI_PROCESSOR_CACHE_ASSOCIATION_DATA". Keeping this inconsistency for backward compatibility.\r |
193 | \r |
194 | 6. Guid/DataHubRecords.h\r |
195 | typedef enum {\r |
196 | EfiProcessorHealthy = 1,\r |
197 | EfiProcessorPerfRestricted = 2,\r |
198 | EfiProcessorFuncRestricted = 3 \r |
199 | } EFI_PROCESSOR_HEALTH_STATUS;\r |
200 | \r |
201 | The structure name "EFI_PROCESSOR_HEALTH_STATUS" is *NOT* consistent with ProcSubclass specification 0.9, in which\r |
202 | the name should be "EFI_PROCESSOR_HEALTH_STATUS_DATA". Keeping this inconsistency for backward compatibility.\r |
203 | \r |
204 | 7. Guid/DataHubRecords.h\r |
205 | typedef enum {\r |
206 | ProcessorCoreFrequencyRecordType = 1,\r |
207 | ProcessorFsbFrequencyRecordType = 2,\r |
208 | ProcessorVersionRecordType = 3,\r |
209 | ProcessorManufacturerRecordType = 4,\r |
210 | ProcessorSerialNumberRecordType = 5,\r |
211 | ProcessorIdRecordType = 6,\r |
212 | ProcessorTypeRecordType = 7,\r |
213 | ProcessorFamilyRecordType = 8,\r |
214 | ProcessorVoltageRecordType = 9,\r |
215 | ProcessorApicBaseAddressRecordType = 10,\r |
216 | ProcessorApicIdRecordType = 11,\r |
217 | ProcessorApicVersionNumberRecordType = 12,\r |
218 | CpuUcodeRevisionDataRecordType = 13,\r |
219 | ProcessorStatusRecordType = 14,\r |
220 | ProcessorSocketTypeRecordType = 15,\r |
221 | ProcessorSocketNameRecordType = 16,\r |
222 | CacheAssociationRecordType = 17,\r |
223 | ProcessorMaxCoreFrequencyRecordType = 18,\r |
224 | ProcessorAssetTagRecordType = 19,\r |
225 | ProcessorMaxFsbFrequencyRecordType = 20,\r |
226 | ProcessorPackageNumberRecordType = 21,\r |
227 | ProcessorCoreFrequencyListRecordType = 22,\r |
228 | ProcessorFsbFrequencyListRecordType = 23,\r |
229 | ProcessorHealthStatusRecordType = 24\r |
230 | } EFI_CPU_VARIABLE_RECORD_TYPE;\r |
231 | \r |
232 | The data structure and all enumeration fields are *NOT* defined in ProcSubclass specification 0.9, which only\r |
233 | defines the following macros to specify the record number of the data record:\r |
234 | #define EFI_PROCESSOR_FREQUENCY_RECORD_NUMBER 0x00000001\r |
235 | #define EFI_PROCESSOR_BUS_FREQUENCY_RECORD_NUMBER 0x00000002\r |
236 | #define EFI_PROCESSOR_VERSION_RECORD_NUMBER 0x00000003\r |
237 | #define EFI_PROCESSOR_MANUFACTURER_RECORD_NUMBER 0x00000004\r |
238 | #define EFI_PROCESSOR_SERIAL_NUMBER_RECORD_NUMBER 0x00000005\r |
239 | #define EFI_PROCESSOR_ID_RECORD_NUMBER 0x00000006\r |
240 | #define EFI_PROCESSOR_TYPE_RECORD_NUMBER 0x00000007\r |
241 | #define EFI_PROCESSOR_FAMILY_RECORD_NUMBER 0x00000008\r |
242 | #define EFI_PROCESSOR_VOLTAGE_RECORD_NUMBER 0x00000009\r |
243 | #define EFI_PROCESSOR_APIC_BASE_ADDRESS_RECORD_NUMBER 0x0000000A\r |
244 | #define EFI_PROCESSOR_APIC_ID_RECORD_NUMBER 0x0000000B\r |
245 | #define EFI_PROCESSOR_APIC_VER_NUMBER_RECORD_NUMBER 0x0000000C\r |
246 | #define EFI_PROCESSOR_MICROCODE_REVISION_RECORD_NUMBER 0x0000000D\r |
247 | #define EFI_PROCESSOR_STATUS_RECORD_NUMBER 0x0000000E\r |
248 | #define EFI_PROCESSOR_SOCKET_TYPE_RECORD_NUMBER 0x0000000F\r |
249 | #define EFI_PROCESSOR_SOCKET_NAME_RECORD_NUMBER 0x00000010\r |
250 | #define EFI_PROCESSOR_CACHE_ASSOCIATION_RECORD_NUMBER 0x00000011\r |
251 | #define EFI_PROCESSOR_MAX_FREQUENCY_RECORD_NUMBER 0x00000012\r |
252 | #define EFI_PROCESSOR_ASSET_TAG_RECORD_NUMBER 0x00000013\r |
253 | #define EFI_PROCESSOR_MAX_FSB_FREQUENCY_RECORD_NUMBER 0x00000014\r |
254 | #define EFI_PROCESSOR_PACKAGE_NUMBER_RECORD_NUMBER 0x00000015\r |
255 | #define EFI_PROCESSOR_FREQUENCY_LIST_RECORD_NUMBER 0x00000016\r |
256 | #define EFI_PROCESSOR_FSB_FREQUENCY_LIST_RECORD_NUMBER 0x00000017\r |
257 | #define EFI_PROCESSOR_HEALTH_STATUS_RECORD_NUMBER 0x00000018\r |
258 | Keeping this inconsistency for backward compatibility.\r |
259 | \r |
260 | 8. Guid/DataHubRecords.h\r |
261 | typedef union {\r |
262 | EFI_PROCESSOR_CORE_FREQUENCY_LIST_DATA ProcessorCoreFrequencyList;\r |
263 | ...\r |
264 | EFI_PROCESSOR_PACKAGE_NUMBER_DATA ProcessorPackageNumber;\r |
265 | } EFI_CPU_VARIABLE_RECORD;\r |
266 | \r |
267 | typedef struct {\r |
268 | EFI_SUBCLASS_TYPE1_HEADER DataRecordHeader;\r |
269 | EFI_CPU_VARIABLE_RECORD VariableRecord;\r |
270 | } EFI_CPU_DATA_RECORD;\r |
271 | \r |
272 | The definitions above are *NOT* defined in ProcSubclass specification 0.9. EdkII introduces them to simplify the\r |
273 | code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r |
274 | Keeping this inconsistency for backward compatibility.\r |
275 | \r |
276 | ##\r |
277 | # Mismatch with Intel Platform Innovation Framework for MemSubclass Specification (Version 0.90)\r |
278 | ##\r |
279 | 1. Guid/DataHubRecords.h\r |
280 | typedef enum _EFI_MEMORY_FORM_FACTOR {\r |
281 | ...\r |
282 | EfiMemoryFormFactorFbDimm = 0x0F\r |
283 | } EFI_MEMORY_FORM_FACTOR;\r |
284 | \r |
285 | typedef enum _EFI_MEMORY_ARRAY_TYPE {\r |
286 | ...\r |
287 | EfiMemoryTypeDdr2 = 0x13,\r |
288 | EfiMemoryTypeDdr2FbDimm = 0x14\r |
289 | } EFI_MEMORY_ARRAY_TYPE;\r |
290 | \r |
291 | typedef enum {\r |
292 | ...\r |
293 | EfiMemoryStatePartial = 6\r |
294 | } EFI_MEMORY_STATE;\r |
295 | \r |
296 | The fields listed above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r |
297 | new memory device (type 17) defined in SmBios 2.6 specification. \r |
298 | Keeping this inconsistency to reflect the latest industry standard.\r |
299 | \r |
300 | 2. Guid/DataHubRecords.h\r |
301 | typedef struct { \r |
302 | ...\r |
303 | EFI_EXP_BASE10_DATA MemorySpeed; \r |
304 | ...\r |
305 | } EFI_MEMORY_ARRAY_LINK_DATA;\r |
306 | \r |
307 | The field name "MemorySpeed" in the definition above is *NOT* consistent with MemSubclass specification 0.9,\r |
308 | in which it is defined as MemoryTypeSpeed. Keeping this inconsistency for backward compatibility.\r |
309 | \r |
310 | 3. Guid/DataHubRecords.h\r |
311 | #define EFI_MEMORY_CONTROLLER_INFORMATION_RECORD_NUMBER 0x00000008\r |
312 | \r |
313 | typedef enum { \r |
314 | EfiErrorDetectingMethodOther = 1,\r |
315 | EfiErrorDetectingMethodUnknown = 2,\r |
316 | EfiErrorDetectingMethodNone = 3,\r |
317 | EfiErrorDetectingMethodParity = 4,\r |
318 | EfiErrorDetectingMethod32Ecc = 5,\r |
319 | EfiErrorDetectingMethod64Ecc = 6,\r |
320 | EfiErrorDetectingMethod128Ecc = 7,\r |
321 | EfiErrorDetectingMethodCrc = 8\r |
322 | } EFI_MEMORY_ERROR_DETECT_METHOD_TYPE;\r |
323 | \r |
324 | typedef struct {\r |
325 | UINT8 Other :1;\r |
326 | UINT8 Unknown :1;\r |
327 | UINT8 None :1;\r |
328 | UINT8 SingleBitErrorCorrect :1;\r |
329 | UINT8 DoubleBitErrorCorrect :1;\r |
330 | UINT8 ErrorScrubbing :1;\r |
331 | UINT8 Reserved :2;\r |
332 | } EFI_MEMORY_ERROR_CORRECT_CAPABILITY;\r |
333 | \r |
334 | typedef enum { \r |
335 | EfiMemoryInterleaveOther = 1,\r |
336 | EfiMemoryInterleaveUnknown = 2,\r |
337 | EfiMemoryInterleaveOneWay = 3,\r |
338 | EfiMemoryInterleaveTwoWay = 4,\r |
339 | EfiMemoryInterleaveFourWay = 5,\r |
340 | EfiMemoryInterleaveEightWay = 6,\r |
341 | EfiMemoryInterleaveSixteenWay = 7\r |
342 | } EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE;\r |
343 | \r |
344 | typedef struct {\r |
345 | UINT16 Other :1;\r |
346 | UINT16 Unknown :1;\r |
347 | UINT16 SeventyNs:1;\r |
348 | UINT16 SixtyNs :1;\r |
349 | UINT16 FiftyNs :1;\r |
350 | UINT16 Reserved :11;\r |
351 | } EFI_MEMORY_SPEED_TYPE;\r |
352 | \r |
353 | typedef struct {\r |
354 | UINT16 Other :1;\r |
355 | UINT16 Unknown :1;\r |
356 | UINT16 Standard :1;\r |
357 | UINT16 FastPageMode:1;\r |
358 | UINT16 EDO :1;\r |
359 | UINT16 Parity :1;\r |
360 | UINT16 ECC :1;\r |
361 | UINT16 SIMM :1;\r |
362 | UINT16 DIMM :1;\r |
363 | UINT16 BurstEdo :1;\r |
364 | UINT16 SDRAM :1;\r |
365 | UINT16 Reserved :5;\r |
366 | } EFI_MEMORY_SUPPORTED_TYPE;\r |
367 | \r |
368 | typedef struct {\r |
369 | UINT8 Five :1;\r |
370 | UINT8 Three :1;\r |
371 | UINT8 Two :1;\r |
372 | UINT8 Reserved:5;\r |
373 | } EFI_MEMORY_MODULE_VOLTAGE_TYPE;\r |
374 | \r |
375 | typedef struct {\r |
376 | EFI_MEMORY_ERROR_DETECT_METHOD_TYPE ErrorDetectingMethod;\r |
377 | EFI_MEMORY_ERROR_CORRECT_CAPABILITY ErrorCorrectingCapability;\r |
378 | EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE MemorySupportedInterleave;\r |
379 | EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE MemoryCurrentInterleave;\r |
380 | UINT8 MaxMemoryModuleSize;\r |
381 | EFI_MEMORY_SPEED_TYPE MemorySpeedType;\r |
382 | EFI_MEMORY_SUPPORTED_TYPE MemorySupportedType;\r |
383 | EFI_MEMORY_MODULE_VOLTAGE_TYPE MemoryModuleVoltage;\r |
384 | UINT8 NumberofMemorySlot;\r |
385 | EFI_MEMORY_ERROR_CORRECT_CAPABILITY EnabledCorrectingCapability;\r |
386 | UINT16 *MemoryModuleConfigHandles;\r |
387 | } EFI_MEMORY_CONTROLLER_INFORMATION;\r |
388 | \r |
389 | typedef struct {\r |
390 | EFI_MEMORY_ERROR_DETECT_METHOD_TYPE ErrorDetectingMethod;\r |
391 | EFI_MEMORY_ERROR_CORRECT_CAPABILITY ErrorCorrectingCapability;\r |
392 | EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE MemorySupportedInterleave;\r |
393 | EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE MemoryCurrentInterleave;\r |
394 | UINT8 MaxMemoryModuleSize;\r |
395 | EFI_MEMORY_SPEED_TYPE MemorySpeedType;\r |
396 | EFI_MEMORY_SUPPORTED_TYPE MemorySupportedType;\r |
397 | EFI_MEMORY_MODULE_VOLTAGE_TYPE MemoryModuleVoltage;\r |
398 | UINT8 NumberofMemorySlot;\r |
399 | EFI_MEMORY_ERROR_CORRECT_CAPABILITY EnabledCorrectingCapability;\r |
400 | EFI_INTER_LINK_DATA MemoryModuleConfig[1];\r |
401 | } EFI_MEMORY_CONTROLLER_INFORMATION_DATA;\r |
402 | \r |
403 | The definitions above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r |
404 | new memory controller information (type 5) defined in SmBios 2.6 specification. \r |
405 | Keeping this inconsistency to reflect the latest industry standard.\r |
406 | \r |
407 | 4. Guid/DataHubRecords.h\r |
408 | #define EFI_MEMORY_32BIT_ERROR_INFORMATION_RECORD_NUMBER 0x00000009\r |
409 | \r |
410 | typedef enum { \r |
411 | EfiMemoryErrorOther = 1,\r |
412 | EfiMemoryErrorUnknown = 2,\r |
413 | EfiMemoryErrorOk = 3,\r |
414 | EfiMemoryErrorBadRead = 4,\r |
415 | EfiMemoryErrorParity = 5,\r |
416 | EfiMemoryErrorSigleBit = 6,\r |
417 | EfiMemoryErrorDoubleBit = 7,\r |
418 | EfiMemoryErrorMultiBit = 8,\r |
419 | EfiMemoryErrorNibble = 9,\r |
420 | EfiMemoryErrorChecksum = 10,\r |
421 | EfiMemoryErrorCrc = 11,\r |
422 | EfiMemoryErrorCorrectSingleBit = 12,\r |
423 | EfiMemoryErrorCorrected = 13,\r |
424 | EfiMemoryErrorUnCorrectable = 14\r |
425 | } EFI_MEMORY_ERROR_TYPE;\r |
426 | \r |
427 | typedef enum { \r |
428 | EfiMemoryGranularityOther = 1,\r |
429 | EfiMemoryGranularityOtherUnknown = 2,\r |
430 | EfiMemoryGranularityDeviceLevel = 3,\r |
431 | EfiMemoryGranularityMemPartitionLevel = 4\r |
432 | } EFI_MEMORY_ERROR_GRANULARITY_TYPE;\r |
433 | \r |
434 | typedef enum { \r |
435 | EfiMemoryErrorOperationOther = 1,\r |
436 | EfiMemoryErrorOperationUnknown = 2,\r |
437 | EfiMemoryErrorOperationRead = 3,\r |
438 | EfiMemoryErrorOperationWrite = 4,\r |
439 | EfiMemoryErrorOperationPartialWrite = 5\r |
440 | } EFI_MEMORY_ERROR_OPERATION_TYPE;\r |
441 | \r |
442 | typedef struct {\r |
443 | EFI_MEMORY_ERROR_TYPE MemoryErrorType;\r |
444 | EFI_MEMORY_ERROR_GRANULARITY_TYPE MemoryErrorGranularity;\r |
445 | EFI_MEMORY_ERROR_OPERATION_TYPE MemoryErrorOperation;\r |
446 | UINT32 VendorSyndrome;\r |
447 | UINT32 MemoryArrayErrorAddress;\r |
448 | UINT32 DeviceErrorAddress;\r |
449 | UINT32 DeviceErrorResolution;\r |
450 | } EFI_MEMORY_32BIT_ERROR_INFORMATION;\r |
451 | \r |
452 | The definitions above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r |
453 | new 32-bit memory error information (type 18) defined in SmBios 2.6 specification. \r |
454 | Keeping this inconsistency to reflect the latest industry standard.\r |
455 | \r |
456 | 5. Guid/DataHubRecords.h\r |
457 | #define EFI_MEMORY_64BIT_ERROR_INFORMATION_RECORD_NUMBER 0x0000000A\r |
458 | \r |
459 | typedef struct {\r |
460 | EFI_MEMORY_ERROR_TYPE MemoryErrorType;\r |
461 | EFI_MEMORY_ERROR_GRANULARITY_TYPE MemoryErrorGranularity;\r |
462 | EFI_MEMORY_ERROR_OPERATION_TYPE MemoryErrorOperation;\r |
463 | UINT32 VendorSyndrome;\r |
464 | UINT64 MemoryArrayErrorAddress;\r |
465 | UINT64 DeviceErrorAddress;\r |
466 | UINT32 DeviceErrorResolution;\r |
467 | } EFI_MEMORY_64BIT_ERROR_INFORMATION;\r |
468 | \r |
469 | The definitions above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r |
470 | new 64-bit memory error information (type 33) defined in SmBios 2.6 specification. \r |
471 | Keeping this inconsistency to reflect the latest industry standard.\r |
472 | \r |
473 | 6. Guid/DataHubRecords.h\r |
474 | typedef union _EFI_MEMORY_SUBCLASS_RECORDS {\r |
475 | EFI_MEMORY_SIZE_DATA SizeData;\r |
476 | ...\r |
477 | EFI_MEMORY_64BIT_ERROR_INFORMATION Memory64bitErrorInfo;\r |
478 | } EFI_MEMORY_SUBCLASS_RECORDS;\r |
479 | \r |
480 | typedef struct {\r |
481 | EFI_SUBCLASS_TYPE1_HEADER Header;\r |
482 | EFI_MEMORY_SUBCLASS_RECORDS Record;\r |
483 | } EFI_MEMORY_SUBCLASS_DRIVER_DATA;\r |
484 | \r |
485 | The definitions above are *NOT* defined in MemSubclass specification 0.9. EdkII introduces them to simplify the\r |
486 | code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r |
487 | Keeping this inconsistency for backward compatibility.\r |
488 | \r |
489 | ##\r |
490 | # Mismatch with Intel Platform Innovation Framework for MiscSubclass Specification (Version 0.90)\r |
491 | ##\r |
492 | 1. Guid/DataHubRecords.h\r |
493 | #pragma pack(1)\r |
494 | typedef struct _USB_PORT_DEVICE_PATH {\r |
495 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
496 | PCI_DEVICE_PATH PciBusDevicePath;\r |
497 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
498 | } USB_PORT_DEVICE_PATH;\r |
499 | \r |
500 | typedef struct _IDE_DEVICE_PATH {\r |
501 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
502 | PCI_DEVICE_PATH PciBusDevicePath;\r |
503 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
504 | } IDE_DEVICE_PATH;\r |
505 | \r |
506 | typedef struct _RMC_CONN_DEVICE_PATH {\r |
507 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
508 | PCI_DEVICE_PATH PciBridgeDevicePath;\r |
509 | PCI_DEVICE_PATH PciBusDevicePath;\r |
510 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
511 | } RMC_CONN_DEVICE_PATH;\r |
512 | \r |
513 | typedef struct _RIDE_DEVICE_PATH {\r |
514 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
515 | PCI_DEVICE_PATH PciBridgeDevicePath;\r |
516 | PCI_DEVICE_PATH PciBusDevicePath;\r |
517 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
518 | } RIDE_DEVICE_PATH;\r |
519 | \r |
520 | typedef struct _GB_NIC_DEVICE_PATH {\r |
521 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
522 | PCI_DEVICE_PATH PciBridgeDevicePath;\r |
523 | PCI_DEVICE_PATH PciXBridgeDevicePath;\r |
524 | PCI_DEVICE_PATH PciXBusDevicePath;\r |
525 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
526 | } GB_NIC_DEVICE_PATH;\r |
527 | \r |
528 | typedef struct _PS2_CONN_DEVICE_PATH {\r |
529 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
530 | PCI_DEVICE_PATH LpcBridgeDevicePath;\r |
531 | ACPI_HID_DEVICE_PATH LpcBusDevicePath;\r |
532 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
533 | } PS2_CONN_DEVICE_PATH;\r |
534 | \r |
535 | typedef struct _SERIAL_CONN_DEVICE_PATH {\r |
536 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
537 | PCI_DEVICE_PATH LpcBridgeDevicePath;\r |
538 | ACPI_HID_DEVICE_PATH LpcBusDevicePath;\r |
539 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
540 | } SERIAL_CONN_DEVICE_PATH;\r |
541 | \r |
542 | typedef struct _PARALLEL_CONN_DEVICE_PATH {\r |
543 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
544 | PCI_DEVICE_PATH LpcBridgeDevicePath;\r |
545 | ACPI_HID_DEVICE_PATH LpcBusDevicePath;\r |
546 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
547 | } PARALLEL_CONN_DEVICE_PATH;\r |
548 | \r |
549 | typedef struct _FLOOPY_CONN_DEVICE_PATH {\r |
550 | ACPI_HID_DEVICE_PATH PciRootBridgeDevicePath;\r |
551 | PCI_DEVICE_PATH LpcBridgeDevicePath;\r |
552 | ACPI_HID_DEVICE_PATH LpcBusDevicePath;\r |
553 | EFI_DEVICE_PATH_PROTOCOL EndDevicePath;\r |
554 | } FLOOPY_CONN_DEVICE_PATH;\r |
555 | \r |
556 | typedef union _EFI_MISC_PORT_DEVICE_PATH {\r |
557 | USB_PORT_DEVICE_PATH UsbDevicePath;\r |
558 | IDE_DEVICE_PATH IdeDevicePath;\r |
559 | RMC_CONN_DEVICE_PATH RmcConnDevicePath;\r |
560 | RIDE_DEVICE_PATH RideDevicePath;\r |
561 | GB_NIC_DEVICE_PATH GbNicDevicePath;\r |
562 | PS2_CONN_DEVICE_PATH Ps2ConnDevicePath;\r |
563 | SERIAL_CONN_DEVICE_PATH SerialConnDevicePath;\r |
564 | PARALLEL_CONN_DEVICE_PATH ParallelConnDevicePath;\r |
565 | FLOOPY_CONN_DEVICE_PATH FloppyConnDevicePath;\r |
566 | } EFI_MISC_PORT_DEVICE_PATH;\r |
567 | #pragma pack()\r |
568 | \r |
569 | a. The definitions above are *NOT* defined in MiscSubclass specifications 0.9. EdkII introduces them to simplify the\r |
570 | code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length device\r |
571 | path for various device.\r |
572 | Keeping this inconsistency for backward compatibility.\r |
573 | \r |
574 | b. The definitions above are packed. This way violates the rule of alignment defined in DataHubSubclass specification.\r |
575 | Section "Alignment" in DataHubSubclass specification say "Fields in a data hub record should be aligned at their\r |
576 | natural boundaries". Keeping this inconsistency for backward compatibility.\r |
577 | \r |
578 | 2. Guid/DataHubRecords.h\r |
579 | typedef struct {\r |
580 | ...\r |
581 | EFI_MISC_PORT_DEVICE_PATH PortPath;\r |
582 | } EFI_MISC_PORT_INTERNAL_CONNECTOR_DESIGNATOR_DATA;\r |
583 | \r |
584 | The definition is *NOT* consistent with MiscSubclass specification, in which the type of last field is defined as\r |
585 | "EFI_DEVICE_PATH_PROTOCOL". The definition in Specification may bring a little complexity on implementation. User\r |
586 | have to allocate variable length memory to contain device path info and free them finially.\r |
587 | EdkII introduced an union type named EFI_MISC_PORT_DEVICE_PATH to avoid the logic above.\r |
588 | \r |
589 | 3. Guid/DataHubRecords.h\r |
590 | typedef struct {\r |
591 | ...\r |
592 | UINT8 BiosMajorRelease;\r |
593 | UINT8 BiosMinorRelease;\r |
594 | UINT8 BiosEmbeddedFirmwareMajorRelease;\r |
595 | UINT8 BiosEmbeddedFirmwareMinorRelease;\r |
596 | } EFI_MISC_BIOS_VENDOR_DATA;\r |
597 | \r |
598 | The fields listed above are *NOT* defined in MiscSubclass specification 0.9. They are introduced to support\r |
599 | new bios information (type 0) defined in SmBios 2.6 specification. \r |
600 | Keeping this inconsistency to reflect the latest industry standard.\r |
601 | \r |
602 | 4. Guid/DataHubRecords.h\r |
603 | typedef struct {\r |
604 | ...\r |
605 | STRING_REF SystemSKUNumber;\r |
606 | STRING_REF SystemFamily;\r |
607 | } EFI_MISC_SYSTEM_MANUFACTURER_DATA;\r |
608 | \r |
609 | The fields listed above are *NOT* defined in MiscSubclass specification 0.9. They are introduced to support\r |
610 | new system information (type 1) defined in SmBios 2.6 specification. \r |
611 | Keeping this inconsistency to reflect the latest industry standard.\r |
612 | \r |
613 | 5. Guid/DataHubRecords.h\r |
614 | typedef struct {\r |
615 | ...\r |
616 | EFI_INTER_LINK_DATA ManagementDeviceThresholdLink;\r |
617 | } EFI_MISC_MANAGEMENT_DEVICE_COMPONENT_DESCRIPTION_DATA;\r |
618 | \r |
619 | The field listed above is *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r |
620 | new management device component (type 35) defined in SmBios 2.6 specification. \r |
621 | Keeping this inconsistency to reflect the latest industry standard.\r |
622 | \r |
623 | 6. Guid/DataHubRecords.h\r |
624 | typedef struct {\r |
625 | UINT32 ChassisType :16;\r |
626 | UINT32 ChassisLockPresent:1;\r |
627 | UINT32 Reserved :15;\r |
628 | } EFI_MISC_CHASSIS_STATUS;\r |
629 | \r |
630 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the first field is assigned a wrong field\r |
631 | name "EFI_MISC_CHASSIS_TYPE". Due to EFI_MISC_CHASSIS_TYPE has been declared as a data type, it can not be used as a\r |
632 | field name again. EdkII changes its name to "ChassisType" to pass build.\r |
633 | \r |
634 | 7. Guid/DataHubRecords.h\r |
635 | typedef enum {\r |
636 | ...\r |
637 | EfiSlotTypeAgp2X = 0x10,\r |
638 | ...\r |
639 | EfiSlotTypePciExpress = 0xA5\r |
640 | } EFI_MISC_SLOT_TYPE;\r |
641 | \r |
642 | a. The field name "EfiSlotTypeAgp2X" is *NOT* consistent with MiscSubclass specification 0.9, in which it is named\r |
643 | "EfiSlotTypeApg2X".\r |
644 | From its literal sense, this field represents a AGP type display card, so it should be named as "EfiSlotTypeAgp2X".\r |
645 | b. The "EfiSlotTypePciExpress" field is *NOT* defined in MiscSubclass specification 0.9. It isintroduced to support\r |
646 | new system slots (type 9) defined in SmBios 2.6 specification.\r |
647 | Keeping this inconsistency to reflect the latest industry standard.\r |
648 | \r |
649 | 8. Guid/DataHubRecords.h\r |
650 | typedef struct {\r |
651 | ...\r |
652 | EFI_MISC_ONBOARD_DEVICE_STATUS OnBoardDeviceStatus;\r |
653 | ...\r |
654 | } EFI_MISC_ONBOARD_DEVICE_DATA;\r |
655 | \r |
656 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the field "OnBoardDeviceStatus" is \r |
657 | named as "OnBoardDeviceType". Keeping this inconsistency for backward compatibility.\r |
658 | \r |
659 | 9. Guid/DataHubRecords.h\r |
660 | #define EFI_MISC_PORTABLE_BATTERY_RECORD_NUMBER 0x00000010\r |
661 | \r |
662 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r |
663 | "EFI_MISC_BATTERY_LOCATION_RECORD_NUMBER". Keeping this inconsistency for backward compatibility.\r |
664 | \r |
665 | 10. Guid/DataHubRecords.h\r |
666 | typedef enum { \r |
667 | EfiPortableBatteryDeviceChemistryOther = 1,\r |
668 | EfiPortableBatteryDeviceChemistryUnknown = 2,\r |
669 | EfiPortableBatteryDeviceChemistryLeadAcid = 3,\r |
670 | EfiPortableBatteryDeviceChemistryNickelCadmium = 4,\r |
671 | EfiPortableBatteryDeviceChemistryNickelMetalHydride = 5,\r |
672 | EfiPortableBatteryDeviceChemistryLithiumIon = 6,\r |
673 | EfiPortableBatteryDeviceChemistryZincAir = 7,\r |
674 | EfiPortableBatteryDeviceChemistryLithiumPolymer = 8\r |
675 | } EFI_MISC_PORTABLE_BATTERY_DEVICE_CHEMISTRY;\r |
676 | \r |
677 | The name of the definition is *NOT* consistent with MiscSubclass specification, in which it is defined as\r |
678 | "EFI_MISC_BATTERY_DEVICE_CHEMISTRY". And all field names have a redundant "Portable" string compared with MisSubclass \r |
679 | specification 0.9.\r |
680 | Keeping this inconsistency for backward compatibility.\r |
681 | \r |
682 | 11. Guid/DataHubRecords.h\r |
683 | typedef struct {\r |
684 | STRING_REF Location;\r |
685 | STRING_REF Manufacturer;\r |
686 | STRING_REF ManufactureDate;\r |
687 | STRING_REF SerialNumber;\r |
688 | STRING_REF DeviceName;\r |
689 | EFI_MISC_PORTABLE_BATTERY_DEVICE_CHEMISTRY DeviceChemistry;\r |
690 | UINT16 DesignCapacity;\r |
691 | UINT16 DesignVoltage;\r |
692 | STRING_REF SBDSVersionNumber;\r |
693 | UINT8 MaximumError;\r |
694 | UINT16 SBDSSerialNumber;\r |
695 | UINT16 SBDSManufactureDate;\r |
696 | STRING_REF SBDSDeviceChemistry;\r |
697 | UINT8 DesignCapacityMultiplier;\r |
698 | UINT32 OEMSpecific;\r |
699 | UINT8 BatteryNumber;\r |
700 | BOOLEAN Valid;\r |
701 | } EFI_MISC_PORTABLE_BATTERY;\r |
702 | \r |
703 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the structure name is defined as\r |
704 | "EFI_MISC_BATTERY_LOCATION_DATA". Moreover, the name and the order of all fields are also different with MiscSubclass \r |
705 | specification 0.9. Keeping this inconsistency for backward compatibility.\r |
706 | \r |
707 | 12. Guid/DataHubRecords.h\r |
708 | typedef enum {\r |
709 | ...\r |
710 | } EFI_MISC_BOOT_INFORMATION_STATUS_DATA_TYPE;\r |
711 | \r |
712 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r |
713 | "EFI_MISC_BOOT_INFORMATION_STATUS_TYPE". Keeping this inconsistency for backward compatibility.\r |
714 | \r |
715 | 13. Guid/DataHubRecords.h\r |
716 | typedef struct {\r |
717 | EFI_MISC_BOOT_INFORMATION_STATUS_DATA_TYPE BootInformationStatus;\r |
718 | ...\r |
719 | } EFI_MISC_BOOT_INFORMATION_STATUS_DATA;\r |
720 | \r |
721 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the type of the first field is \r |
722 | "EFI_MISC_BOOT_INFORMATION_STATUS_TYPE". Keeping this inconsistency for backward compatibility.\r |
723 | \r |
724 | 14. Guid/DataHubRecords.h\r |
725 | typedef struct {\r |
726 | ...\r |
727 | } EFI_MISC_SYSTEM_POWER_SUPPLY_DATA;\r |
728 | \r |
729 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r |
730 | "EFI_MISC_POWER_SUPPLY_UNIT_GROUP_DATA". Keeping this inconsistency for backward compatibility.\r |
731 | \r |
732 | 15. Guid/DataHubRecords.h\r |
733 | typedef struct {\r |
734 | ...\r |
735 | } SMBIOS_STRUCTURE_HDR;\r |
736 | \r |
737 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which the structure name\r |
738 | is defined as "EFI_SMBIOS_STRUCTURE_HDR". Due to this structure is commonly used by vendor to construct SmBios\r |
739 | type 0x80~0xFF table, Keeping this inconsistency for backward compatibility.\r |
740 | \r |
741 | 16. Guid/DataHubRecords.h\r |
742 | typedef struct {\r |
743 | SMBIOS_STRUCTURE_HDR Header;\r |
744 | ...\r |
745 | } EFI_MISC_SMBIOS_STRUCT_ENCAPSULATION_DATA;\r |
746 | \r |
747 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the type of the first field is \r |
748 | "EFI_SMBIOS_STRUCTURE_HDR". Keeping this inconsistency for backward compatibility.\r |
749 | \r |
750 | 17. Guid/DataHubRecords.h\r |
751 | typedef struct {\r |
752 | UINT16 PowerSupplyHotReplaceable:1;\r |
753 | UINT16 PowerSupplyPresent :1;\r |
754 | UINT16 PowerSupplyUnplugged :1;\r |
755 | UINT16 InputVoltageRangeSwitch :4;\r |
756 | UINT16 PowerSupplyStatus :3;\r |
757 | UINT16 PowerSupplyType :4;\r |
758 | UINT16 Reserved :2;\r |
759 | } EFI_MISC_POWER_SUPPLY_CHARACTERISTICS;\r |
760 | \r |
761 | all field type in the definition are *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r |
762 | "UINT32" and the total width of bit-fields is 32bits width.\r |
763 | Keeping this inconsistency for backward compatibility.\r |
764 | \r |
765 | 18. Guid/DataHubRecords.h\r |
766 | #define EFI_MISC_SYSTEM_EVENT_LOG_RECORD_NUMBER 0x00000020\r |
767 | \r |
768 | typedef struct {\r |
769 | UINT16 LogAreaLength;\r |
770 | UINT16 LogHeaderStartOffset;\r |
771 | UINT16 LogDataStartOffset;\r |
772 | UINT8 AccessMethod;\r |
773 | UINT8 LogStatus;\r |
774 | UINT32 LogChangeToken;\r |
775 | UINT32 AccessMethodAddress;\r |
776 | UINT8 LogHeaderFormat;\r |
777 | UINT8 NumberOfSupportedLogType;\r |
778 | UINT8 LengthOfLogDescriptor;\r |
779 | } EFI_MISC_SYSTEM_EVENT_LOG_DATA;\r |
780 | \r |
781 | #define ACCESS_INDEXIO_1INDEX8BIT_DATA8BIT 0x00\r |
782 | #define ACCESS_INDEXIO_2INDEX8BIT_DATA8BIT 0X01\r |
783 | #define ACCESS_INDEXIO_1INDEX16BIT_DATA8BIT 0X02\r |
784 | #define ACCESS_MEMORY_MAPPED 0x03\r |
785 | #define ACCESS_GPNV 0x04\r |
786 | \r |
787 | The definitions listed above are *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r |
788 | new system event log (type 15) defined in SmBios 2.6 specification. \r |
789 | Keeping this inconsistency to reflect the latest industry standard.\r |
790 | \r |
791 | 19. Guid/DataHubRecords.h\r |
792 | #define EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD_RECORD_NUMBER 0x00000021\r |
793 | \r |
794 | typedef struct {\r |
795 | UINT16 LowerThresNonCritical;\r |
796 | UINT16 UpperThresNonCritical;\r |
797 | UINT16 LowerThresCritical;\r |
798 | UINT16 UpperThresCritical;\r |
799 | UINT16 LowerThresNonRecover;\r |
800 | UINT16 UpperThresNonRecover;\r |
801 | } EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD;\r |
802 | \r |
803 | The definitions listed above are *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r |
804 | new management device threshold data (type 36) defined in SmBios 2.6 specification. \r |
805 | Keeping this inconsistency to reflect the latest industry standard.\r |
806 | \r |
807 | 20. Guid/DataHubRecords.h\r |
808 | typedef union {\r |
809 | EFI_MISC_LAST_PCI_BUS_DATA LastPciBus;\r |
810 | ...\r |
811 | EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD MiscManagementDeviceThreshold;\r |
812 | } EFI_MISC_SUBCLASS_RECORDS;\r |
813 | \r |
814 | typedef struct {\r |
815 | EFI_SUBCLASS_TYPE1_HEADER Header;\r |
816 | EFI_MISC_SUBCLASS_RECORDS Record;\r |
817 | } EFI_MISC_SUBCLASS_DRIVER_DATA;\r |
818 | \r |
819 | The definitions above are *NOT* defined in MemSubclass specification 0.9. EdkII introduces them to simplify the\r |
820 | code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r |
821 | Keeping this inconsistency for backward compatibility.\r |
822 | \r |
823 | ##\r |
824 | # Mismatch with Intel Platform Innovation Framework for Status Codes Specification (Version 0.92)\r |
825 | ##\r |
826 | 1. Include/Framework/StatusCode.h\r |
827 | #define EFI_IOB_ATA_BUS_SMART_ENABLE (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r |
828 | #define EFI_IOB_ATA_BUS_SMART_DISABLE (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r |
829 | #define EFI_IOB_ATA_BUS_SMART_OVERTHRESHOLD (EFI_SUBCLASS_SPECIFIC | 0x00000002)\r |
830 | #define EFI_IOB_ATA_BUS_SMART_UNDERTHRESHOLD (EFI_SUBCLASS_SPECIFIC | 0x00000003)\r |
831 | \r |
832 | #define EFI_IOB_ATA_BUS_SMART_NOTSUPPORTED (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r |
833 | #define EFI_IOB_ATA_BUS_SMART_DISABLED (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r |
834 | \r |
835 | #define EFI_SW_DXE_BS_PC_BEGIN_CONNECTING_DRIVERS (EFI_SUBCLASS_SPECIFIC | 0x00000005)\r |
836 | #define EFI_SW_DXE_BS_PC_VERIFYING_PASSWORD (EFI_SUBCLASS_SPECIFIC | 0x00000006)\r |
837 | \r |
838 | #define EFI_SW_DXE_RT_PC_S0 (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r |
839 | #define EFI_SW_DXE_RT_PC_S1 (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r |
840 | #define EFI_SW_DXE_RT_PC_S2 (EFI_SUBCLASS_SPECIFIC | 0x00000002)\r |
841 | #define EFI_SW_DXE_RT_PC_S3 (EFI_SUBCLASS_SPECIFIC | 0x00000003)\r |
842 | #define EFI_SW_DXE_RT_PC_S4 (EFI_SUBCLASS_SPECIFIC | 0x00000004)\r |
843 | #define EFI_SW_DXE_RT_PC_S5 (EFI_SUBCLASS_SPECIFIC | 0x00000005)\r |
844 | \r |
845 | #define EFI_SW_CSM_LEGACY_ROM_INIT (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r |
846 | \r |
847 | The definitions above are *NOT* defined in Framework StatusCodes specification 0.92. But these subclass-specific error code\r |
848 | operations are needed for EdkII implementation.\r |
849 | Keeping this inconsistency for backward compatibility.\r |
850 | \r |
851 | 2. Include/Framework/StatusCode.h\r |
852 | typedef union {\r |
853 | CHAR8 *Ascii;\r |
854 | CHAR16 *Unicode;\r |
855 | ...\r |
856 | } EFI_STATUS_CODE_STRING;\r |
857 | \r |
858 | The definition is *NOT* consistent with Framework SatausCodes specification 0.92, in which the first field is defined as "CHAR8 Ascii[]"\r |
859 | and the second field is defined as "CHAR16 Unicode[]". Keeping this inconsistency for backward compatibility.\r |
860 | \r |
861 | 3. Include/Framework/StatusCode.h\r |
862 | #define EFI_SW_EC_X64_DIVIDE_ERROR EXCEPT_X64_DIVIDE_ERROR\r |
863 | #define EFI_SW_EC_X64_DEBUG EXCEPT_X64_DEBUG\r |
864 | #define EFI_SW_EC_X64_NMI EXCEPT_X64_NMI\r |
865 | #define EFI_SW_EC_X64_BREAKPOINT EXCEPT_X64_BREAKPOINT\r |
866 | #define EFI_SW_EC_X64_OVERFLOW EXCEPT_X64_OVERFLOW\r |
867 | #define EFI_SW_EC_X64_BOUND EXCEPT_X64_BOUND\r |
868 | #define EFI_SW_EC_X64_INVALID_OPCODE EXCEPT_X64_INVALID_OPCODE\r |
869 | #define EFI_SW_EC_X64_DOUBLE_FAULT EXCEPT_X64_DOUBLE_FAULT\r |
870 | #define EFI_SW_EC_X64_INVALID_TSS EXCEPT_X64_INVALID_TSS\r |
871 | #define EFI_SW_EC_X64_SEG_NOT_PRESENT EXCEPT_X64_SEG_NOT_PRESENT\r |
872 | #define EFI_SW_EC_X64_STACK_FAULT EXCEPT_X64_STACK_FAULT\r |
873 | #define EFI_SW_EC_X64_GP_FAULT EXCEPT_X64_GP_FAULT\r |
874 | #define EFI_SW_EC_X64_PAGE_FAULT EXCEPT_X64_PAGE_FAULT\r |
875 | #define EFI_SW_EC_X64_FP_ERROR EXCEPT_X64_FP_ERROR\r |
876 | #define EFI_SW_EC_X64_ALIGNMENT_CHECK EXCEPT_X64_ALIGNMENT_CHECK\r |
877 | #define EFI_SW_EC_X64_MACHINE_CHECK EXCEPT_X64_MACHINE_CHECK\r |
878 | #define EFI_SW_EC_X64_SIMD EXCEPT_X64_SIMD\r |
879 | \r |
880 | The definitions are *NOT* defined in Framework StatusCodes specification 0.92, in which IA32 and IPF exception subclass error code definitions\r |
881 | are defined but omit the corresponding definitions for X64. EdkII introduce these definitions for implementation. \r |
882 | \r |
883 | ##\r |
884 | # Mismatch with Intel Platform Innovation Framework for EFI Boot Script Specification (Version 0.91)\r |
885 | ##\r |
886 | 1. Include/Protocol/BootScriptSave.h\r |
887 | #define EFI_BOOT_SCRIPT_SAVE_PROTOCOL_GUID \\r |
888 | { \\r |
889 | 0x470e1529, 0xb79e, 0x4e32, {0xa0, 0xfe, 0x6a, 0x15, 0x6d, 0x29, 0xf9, 0xb2 } \\r |
890 | }\r |
891 | \r |
892 | The macro name "EFI_BOOT_SCRIPT_SAVE_PROTOCOL_GUID" is *NOT* consistent with Framework BootScript specification 0.91,\r |
893 | in which it's defined as "EFI_BOOT_SCRIPT_SAVE_GUID". Keeping this inconsistency for backward compatibility.\r |
894 | \r |
895 | 2. Include/Protocol/BootScriptSave.h\r |
896 | EFI_STATUS\r |
897 | EFI_BOOTSERVICE\r |
898 | (EFIAPI *EFI_BOOT_SCRIPT_WRITE) (\r |
899 | IN EFI_BOOT_SCRIPT_SAVE_PROTOCOL *This,\r |
900 | ...\r |
901 | );\r |
902 | \r |
903 | The first parameter's type is *NOT* consistent with Framework BootScript specification 0.91, in which it's defined as\r |
904 | "struct _EFI_BOOT_SCRIPT_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r |
905 | \r |
906 | 3. Include/Framework/BootScript.h\r |
907 | #define EFI_BOOT_SCRIPT_MEM_POLL_OPCODE 0x09\r |
908 | #define EFI_BOOT_SCRIPT_INFORMATION_OPCODE 0x0A\r |
909 | #define EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE 0x0B\r |
910 | #define EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE 0x0C\r |
911 | #define EFI_BOOT_SCRIPT_DISPATCH_2_OPCODE 0x0D\r |
912 | \r |
913 | The OPCODEs above are not defined in Framework BootScript Specification 0.91, but adopted by PI 1.0 Spec. And they\r |
914 | are needed for EdkII implementation.\r |
915 | \r |
916 | 4. Include/Framework/BootScript.h\r |
917 | #define EFI_BOOT_SCRIPT_TABLE_OPCODE 0xAA\r |
918 | #define EFI_BOOT_SCRIPT_TERMINATE_OPCODE 0xFF\r |
919 | \r |
920 | The two OPCODEs are *NOT* defined in Framework BootScript specification 0.91. EdkII introduces them to indicate the start\r |
921 | or end of the boot script table.\r |
922 | Keeping this inconsistency for backward compatibility.\r |
923 | \r |
924 | 5. Include/Protocol/BootScriptSave.h\r |
925 | typedef \r |
926 | EFI_STATUS \r |
927 | (EFIAPI *EFI_BOOT_SCRIPT_CLOSE_TABLE) (\r |
928 | IN EFI_BOOT_SCRIPT_SAVE_PROTOCOL *This,\r |
929 | ...\r |
930 | );\r |
931 | \r |
932 | The first parameter's type is *NOT* consistent with BootScript specification, in which it's defined as\r |
933 | "struct _EFI_BOOT_SCRIPT_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r |
934 | \r |
935 | 6. Include/Include/BootScriptExecuter.h\r |
936 | typedef\r |
937 | EFI_STATUS\r |
938 | (EFIAPI *EFI_PEI_BOOT_SCRIPT_EXECUTE)(\r |
939 | IN EFI_PEI_SERVICES **PeiServices,\r |
940 | IN EFI_PEI_BOOT_SCRIPT_EXECUTER_PPI *This,\r |
941 | ...\r |
942 | );\r |
943 | \r |
944 | The second parameter's type is *NOT* consistent with BootScript specification, in which it's defined as\r |
945 | "struct _EFI_PEI_BOOT_SCRIPT_EXECUTER_PPI". Keeping this inconsistency for backward compatibility.\r |
946 | \r |
947 | ##\r |
948 | # Mismatch with Intel Platform Innovation Framework for EFI DXE CIS (Version 0.91)\r |
949 | ##\r |
950 | 1. Include/Framework/DxeCis.h\r |
951 | EFI_STATUS_CODE_ARCH_PROTOCOL is removed.\r |
952 | \r |
953 | EdkII doesn't provide EFI_STATUS_CODE_ARCH_PROTOCOL definition due to ReportStatusCode() field has been\r |
954 | removed from EFI Runtime Service Table of PI specification. EFI_STATUS_CODE_ARCH_PROTOCOL is *NOT* required,\r |
955 | and is replaced with EFI_STATUS_CODE_RUNTIME_PROTOCOL.\r |
956 | \r |
957 | ##\r |
958 | # Mismatch with Intel Platform Innovation Framework for EFI Firmware Volume Specification (Version 0.9)\r |
959 | ##\r |
960 | 1. Include/Framework/FirmwareVolumeImageFormat.h\r |
961 | #define EFI_AGGREGATE_AUTH_STATUS_ALL 0x00000f\r |
962 | #define EFI_LOCAL_AUTH_STATUS_ALL 0x0f0000\r |
963 | \r |
964 | The two macros are *NOT* defined in Framework FV specification 0.9. EdkII introduces them as a mask to calculate the\r |
965 | value of authentication status.\r |
966 | \r |
967 | ##\r |
968 | # Mismatch with Intel Platform Innovation Framework for EFI Human Interface Infrastructure Specification (Version 0.92)\r |
969 | ##\r |
970 | 1. Include/Protocol/FrameworkHii.h\r |
971 | #define EFI_HII_PROTOCOL_GUID \\r |
972 | { \\r |
973 | 0xd7ad636e, 0xb997, 0x459b, {0xbf, 0x3f, 0x88, 0x46, 0x89, 0x79, 0x80, 0xe1} \\r |
974 | }\r |
975 | \r |
976 | The Framework HII specification 0.92 changed part of HII interfaces but did not update the protocol GUID.\r |
977 | This change should cause a change of GUID in both of code and HII spec. EdkII updates the GUID in code, \r |
978 | but the Framework HII specification 0.92 is not updated. This is a known issue.\r |
979 | \r |
980 | 2. Include/Protocol/FrameworkHii.h\r |
981 | typedef struct {\r |
982 | ...\r |
983 | EFI_HANDLE COBExportHandle;\r |
984 | } EFI_HII_HANDLE_PACK;\r |
985 | \r |
986 | The last field "COBExportHandle" of EFI_HII_HANDLE_PACK is *NOT* defined in the Framework HII specification\r |
987 | 0.92. Keeping this inconsistency for backward compatibility.\r |
988 | \r |
989 | 3. Include/Protocol/FrameworkHii.h\r |
990 | typedef struct {\r |
991 | UINTN NumberOfPackages;\r |
992 | EFI_GUID *GuidId;\r |
993 | } EFI_HII_PACKAGES;\r |
994 | \r |
995 | The definition is *NOT* consistent with Framework HII specification 0.92, in which a field "HandlePack" is defined.\r |
996 | EdkII changes the EFI_HII_PACKAGES to contain various number of packages of different types just after the structure\r |
997 | as inline data, which will bring the flexibility on development.\r |
998 | \r |
999 | 4. Include/Protocol/FrameworkHii.h\r |
1000 | struct _EFI_HII_PROTOCOL {\r |
1001 | ...\r |
1002 | EFI_HII_RESET_STRINGS ResetStrings;\r |
1003 | ...\r |
1004 | };\r |
1005 | \r |
1006 | The field listed above is *NOT* defined in Framework HII specification 0.92. EdkII adds this field to provide \r |
1007 | an ability of removing any new strings that were added after the initial string export for this handle. \r |
1008 | \r |
1009 | 5. Include/Protocol/FrameworkHii.h\r |
1010 | typedef\r |
1011 | EFI_STATUS\r |
1012 | (EFIAPI *EFI_HII_GLYPH_TO_BLT)(\r |
1013 | ...\r |
1014 | IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL Foreground,\r |
1015 | IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL Background,\r |
1016 | ...\r |
1017 | IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer\r |
1018 | );\r |
1019 | \r |
1020 | The type of the parameters listed above are *NOT* consistent with Framework HII specification 0.92, in which\r |
1021 | the type of these parameters is EFI_UGA_PIXEL. Here the definition uses the EFI_GRAPHICS_OUTPUT_BLT_PIXEL which\r |
1022 | defined in UEFI2.1 spec. Keeping this inconsistency for backward compatibility.\r |
1023 | \r |
1024 | 6. Include/Protocol/FrameworkHii.h\r |
1025 | typedef struct {\r |
1026 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1027 | UINT8 Flags;\r |
1028 | } EFI_IFR_SUPPRESS;\r |
1029 | \r |
1030 | typedef struct {\r |
1031 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1032 | UINT8 Flags;\r |
1033 | } EFI_IFR_GRAY_OUT;\r |
1034 | \r |
1035 | typedef struct {\r |
1036 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1037 | STRING_REF Popup;\r |
1038 | UINT8 Flags;\r |
1039 | } EFI_IFR_INCONSISTENT;\r |
1040 | \r |
1041 | typedef struct {\r |
1042 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1043 | UINT16 QuestionId;\r |
1044 | UINT8 Width;\r |
1045 | UINT16 Value;\r |
1046 | } FRAMEWORK_EFI_IFR_EQ_ID_VAL;\r |
1047 | \r |
1048 | typedef struct {\r |
1049 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1050 | UINT16 QuestionId;\r |
1051 | UINT8 Width;\r |
1052 | UINT16 ListLength;\r |
1053 | UINT16 ValueList[1];\r |
1054 | } FRAMEWORK_EFI_IFR_EQ_ID_LIST;\r |
1055 | \r |
1056 | typedef struct {\r |
1057 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1058 | UINT16 QuestionId1;\r |
1059 | UINT8 Width;\r |
1060 | UINT16 QuestionId2;\r |
1061 | } FRAMEWORK_EFI_IFR_EQ_ID_ID;\r |
1062 | \r |
1063 | typedef struct {\r |
1064 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r |
1065 | UINT16 VariableId;\r |
1066 | UINT16 Value;\r |
1067 | } EFI_IFR_EQ_VAR_VAL;\r |
1068 | \r |
1069 | The defintions are not complied with Framework HII spec 0.92. Keeping the inconsistent for implementation needed.\r |
1070 | \r |
1071 | 7. Include/Protocol/FrameworkFormCallback.h\r |
1072 | #define RESET_REQUIRED 1 \r |
1073 | #define EXIT_REQUIRED 2\r |
1074 | #define SAVE_REQUIRED 4\r |
1075 | #define NV_CHANGED 8\r |
1076 | #define NV_NOT_CHANGED 16\r |
1077 | \r |
1078 | These macros are *NOT* defined in the Framework HII specification 0.92. These Flags are introduced to describe\r |
1079 | the standard behavior of the browser after the callback.\r |
1080 | Keeping this inconsistency for backward compatibility.\r |
1081 | \r |
1082 | 8. Include/Protocol/FrameworkFormCallback.h\r |
1083 | typedef\r |
1084 | EFI_STATUS\r |
1085 | (EFIAPI *EFI_NV_WRITE)(\r |
1086 | ...\r |
1087 | IN UINT32 Attributes,\r |
1088 | ...\r |
1089 | );\r |
1090 | \r |
1091 | The definition is *NOT* consistent with Framework HII specification 0.92, in which the type of Attributes\r |
1092 | parameter is defined as "UINT32 *". EdkII changes the type of Attributes from UINT32 * to UINT32 because\r |
1093 | the input paramter is not necessary to use pointer date type.\r |
1094 | \r |
1095 | ##\r |
1096 | # Mismatch with Intel Platform Innovation Framework for PEI CIS Specification (Version 0.91)\r |
1097 | ##\r |
1098 | 1. Include/Ppi/ReadOnlyVariable.h\r |
1099 | #define EFI_VARIABLE_READ_ONLY 0x00000008\r |
1100 | \r |
1101 | In Framework PeiCis specification 0.91, neither the macro or its value is defined.\r |
1102 | Keeping this inconsistency for backward compatibility.\r |
1103 | \r |
1104 | 2. Include/Ppi/FindFv.h\r |
1105 | typedef\r |
1106 | EFI_STATUS\r |
1107 | (EFIAPI *EFI_PEI_FIND_FV_FINDFV)(\r |
1108 | IN EFI_PEI_FIND_FV_PPI *This,\r |
1109 | IN EFI_PEI_SERVICES **PeiServices,\r |
1110 | IN UINT8 *FvNumber,\r |
1111 | IN OUT EFI_FIRMWARE_VOLUME_HEADER **FVAddress\r |
1112 | );\r |
1113 | \r |
1114 | The definition is *NOT* consistent with Framework PeiCis specification 0.91. Compared with spec, the order\r |
1115 | of the first and second parameters is reversed. Keeping this inconsistency for backward compatibility.\r |
1116 | \r |
1117 | ##\r |
1118 | # Mismatch with Intel Platform Innovation Framework for EFI SMM CIS (Version 0.91)\r |
1119 | ##\r |
1120 | 1. Include/Guid/SmramMemoryReserve.h\r |
1121 | typedef struct {\r |
1122 | ...\r |
1123 | } EFI_SMRAM_HOB_DESCRIPTOR_BLOCK;\r |
1124 | \r |
1125 | The name of the definition is *NOT* consistent with Framework SmmCis specification 0.91, in which it's \r |
1126 | defined as "EFI_HOB_SMRAM_DESCRIPTOR_BLOCK" rather than "EFI_SMRAM_HOB_DESCRIPTOR_BLOCK". \r |
1127 | Keeping this inconsistency for backward compatibility.\r |
1128 | \r |
1129 | 2. Include/Guid/SmramMemoryReserve.h\r |
1130 | typedef enum {\r |
1131 | ...\r |
1132 | IchnIoTrap3,\r |
1133 | IchnIoTrap2,\r |
1134 | IchnIoTrap1,\r |
1135 | IchnIoTrap0,\r |
1136 | IchnPciExpress,\r |
1137 | IchnMonitor,\r |
1138 | IchnSpi,\r |
1139 | IchnQRT,\r |
1140 | IchnGpioUnlock,\r |
1141 | ...\r |
1142 | } EFI_SMM_ICHN_SMI_TYPE;\r |
1143 | \r |
1144 | The enumeration fields listed above are *NOT* defined in Framework SmmCis specification 0.91. EdkII introduces\r |
1145 | these fields to support new SMI types.\r |
1146 | \r |
1147 | ##\r |
1148 | # Mismatch with Intel Platform Innovation Framework for EFI S3 Resume Boot Path Specification (Version 0.9)\r |
1149 | ##\r |
1150 | 1. Include/Protocol/AcpiS3Save.h\r |
1151 | typedef\r |
1152 | EFI_STATUS\r |
1153 | EFI_BOOTSERVICE\r |
1154 | (EFIAPI *EFI_ACPI_GET_LEGACY_MEMORY_SIZE) (\r |
1155 | IN EFI_ACPI_S3_SAVE_PROTOCOL *This,\r |
1156 | OUT UINTN *Size\r |
1157 | );\r |
1158 | \r |
1159 | The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r |
1160 | "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r |
1161 | \r |
1162 | 2. Include/Protocol/AcpiS3Save.h\r |
1163 | typedef\r |
1164 | EFI_STATUS\r |
1165 | (EFIAPI *EFI_ACPI_S3_SAVE) (\r |
1166 | IN EFI_ACPI_S3_SAVE_PROTOCOL *This,\r |
1167 | IN VOID *LegacyMemoryAddress \r |
1168 | );\r |
1169 | \r |
1170 | The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r |
1171 | "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Also the EFI_BOOTSERVICE modifier is removed from the function declaration.\r |
1172 | \r |
1173 | 3. Include/Protocol/AcpiS3Save.h\r |
1174 | typedef\r |
1175 | EFI_STATUS\r |
1176 | (EFIAPI *EFI_ACPI_GET_LEGACY_MEMORY_SIZE)(\r |
1177 | IN EFI_ACPI_S3_SAVE_PROTOCOL *This,\r |
1178 | OUT UINTN *Size\r |
1179 | );\r |
1180 | \r |
1181 | The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r |
1182 | "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Also the EFI_BOOTSERVICE modifier is removed from the function declaration.\r |
1183 | \r |
1184 | ##\r |
1185 | # Mismatch with Intel Platform Innovation Framework for EFI ACPI Specification (Version 0.91)\r |
1186 | ##\r |
1187 | 1. Include/Protocol/AcpiSupport.h\r |
1188 | typedef\r |
1189 | EFI_STATUS\r |
1190 | (EFIAPI *EFI_ACPI_GET_ACPI_TABLE)(\r |
1191 | ...\r |
1192 | );\r |
1193 | \r |
1194 | The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r |
1195 | is removed from the function declaration.\r |
1196 | \r |
1197 | 2. Include/Protocol/AcpiSupport.h\r |
1198 | typedef\r |
1199 | EFI_STATUS\r |
1200 | (EFIAPI *EFI_ACPI_SET_ACPI_TABLE)(\r |
1201 | ...\r |
1202 | );\r |
1203 | \r |
1204 | The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r |
1205 | is removed from the function declaration.\r |
1206 | \r |
1207 | 3. Include/Protocol/AcpiSupport.h\r |
1208 | typedef\r |
1209 | EFI_STATUS\r |
1210 | (EFIAPI *EFI_ACPI_PUBLISH_TABLES)(\r |
1211 | ...\r |
1212 | );\r |
1213 | \r |
1214 | The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r |
1215 | is removed from the function declaration.\r |