projects / mirror_edk2.git / blame
? search:
summary | shortlog | log | commit | commitdiff | tree
blob | blame (incremental) | history | HEAD
Document all of the mismatches between IntelFrameworkPkg and Framework specification.
[mirror_edk2.git] / IntelFrameworkPkg / FrameworkSpecConformance.txt
CommitLineData
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
EFI Development Kit II mirror for PVE