]>
Commit | Line | Data |
---|---|---|
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 |