Update and add some definitions to reflect the latest industry standard or for backwa...
[mirror_edk2.git] / IntelFrameworkPkg / FrameworkSpecConformance.txt
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       ProcessorCoreCountRecordType         = 25,\r
231       ProcessorEnabledCoreCountRecordType  = 26,\r
232       ProcessorThreadCountRecordType       = 27,\r
233       ProcessorCharacteristicsRecordType   = 28,\r
234       ProcessorFamily2RecordType           = 29,\r
235       ProcessorPartNumberRecordType        = 30,\r
236     } EFI_CPU_VARIABLE_RECORD_TYPE;\r
237 \r
238     The enumeration fields from ProcessorCoreFrequencyRecordType to ProcessorHealthStatusRecordType are *NOT* defined \r
239     in ProcSubclass specification 0.9, which only defines the following macros to specify the record number of the data record:\r
240       #define EFI_PROCESSOR_FREQUENCY_RECORD_NUMBER           0x00000001\r
241       #define EFI_PROCESSOR_BUS_FREQUENCY_RECORD_NUMBER       0x00000002\r
242       #define EFI_PROCESSOR_VERSION_RECORD_NUMBER             0x00000003\r
243       #define EFI_PROCESSOR_MANUFACTURER_RECORD_NUMBER        0x00000004\r
244       #define EFI_PROCESSOR_SERIAL_NUMBER_RECORD_NUMBER       0x00000005\r
245       #define EFI_PROCESSOR_ID_RECORD_NUMBER                  0x00000006\r
246       #define EFI_PROCESSOR_TYPE_RECORD_NUMBER                0x00000007\r
247       #define EFI_PROCESSOR_FAMILY_RECORD_NUMBER              0x00000008\r
248       #define EFI_PROCESSOR_VOLTAGE_RECORD_NUMBER             0x00000009\r
249       #define EFI_PROCESSOR_APIC_BASE_ADDRESS_RECORD_NUMBER   0x0000000A\r
250       #define EFI_PROCESSOR_APIC_ID_RECORD_NUMBER             0x0000000B\r
251       #define EFI_PROCESSOR_APIC_VER_NUMBER_RECORD_NUMBER     0x0000000C\r
252       #define EFI_PROCESSOR_MICROCODE_REVISION_RECORD_NUMBER  0x0000000D\r
253       #define EFI_PROCESSOR_STATUS_RECORD_NUMBER              0x0000000E\r
254       #define EFI_PROCESSOR_SOCKET_TYPE_RECORD_NUMBER         0x0000000F\r
255       #define EFI_PROCESSOR_SOCKET_NAME_RECORD_NUMBER         0x00000010\r
256       #define EFI_PROCESSOR_CACHE_ASSOCIATION_RECORD_NUMBER   0x00000011\r
257       #define EFI_PROCESSOR_MAX_FREQUENCY_RECORD_NUMBER       0x00000012\r
258       #define EFI_PROCESSOR_ASSET_TAG_RECORD_NUMBER           0x00000013\r
259       #define EFI_PROCESSOR_MAX_FSB_FREQUENCY_RECORD_NUMBER   0x00000014\r
260       #define EFI_PROCESSOR_PACKAGE_NUMBER_RECORD_NUMBER      0x00000015\r
261       #define EFI_PROCESSOR_FREQUENCY_LIST_RECORD_NUMBER      0x00000016\r
262       #define EFI_PROCESSOR_FSB_FREQUENCY_LIST_RECORD_NUMBER  0x00000017\r
263       #define EFI_PROCESSOR_HEALTH_STATUS_RECORD_NUMBER       0x00000018\r
264     Keeping this inconsistency for backward compatibility.\r
265 \r
266     The enumeration fields from ProcessorCoreCountRecordType to ProcessorPartNumberRecordType are *NOT* defined \r
267     in ProcSubclass specification 0.9. \r
268     They are introduced to support new fields for type 4 defined in SmBios 2.6 specification.\r
269     Keeping this inconsistency to reflect the latest industry standard.\r
270 \r
271   8. Guid/DataHubRecords.h\r
272     typedef union {\r
273       EFI_PROCESSOR_CORE_FREQUENCY_LIST_DATA  ProcessorCoreFrequencyList;\r
274       ...\r
275       EFI_PROCESSOR_FAMILY2_DATA              ProcessorFamily2;\r
276     } EFI_CPU_VARIABLE_RECORD;\r
277     \r
278     typedef struct {\r
279       EFI_SUBCLASS_TYPE1_HEADER         DataRecordHeader;\r
280       EFI_CPU_VARIABLE_RECORD           VariableRecord;\r
281     } EFI_CPU_DATA_RECORD;\r
282 \r
283     The definitions above are *NOT* defined in ProcSubclass specification 0.9. EdkII introduces them to simplify the\r
284     code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r
285     Keeping this inconsistency for backward compatibility.\r
286 \r
287   9. Guid/DataHubRecords.h\r
288     typedef STRING_REF                  EFI_PROCESSOR_PART_NUMBER_DATA;\r
289 \r
290     typedef enum {\r
291       EfiProcessorFamilySh3           = 0x104,\r
292       EfiProcessorFamilySh4           = 0x105,\r
293       EfiProcessorFamilyArm           = 0x118,\r
294       EfiProcessorFamilyStrongArm     = 0x119,\r
295       EfiProcessorFamily6x86          = 0x12C,\r
296       EfiProcessorFamilyMediaGx       = 0x12D,\r
297       EfiProcessorFamilyMii           = 0x12E,\r
298       EfiProcessorFamilyWinChip       = 0x140,\r
299       EfiProcessorFamilyDsp           = 0x15E,\r
300       EfiProcessorFamilyVideo         = 0x1F4\r
301     } EFI_PROCESSOR_FAMILY2_DATA;\r
302 \r
303     typedef UINT8                       EFI_PROCESSOR_CORE_COUNT_DATA;\r
304 \r
305     typedef UINT8                       EFI_PROCESSOR_ENABLED_CORE_COUNT_DATA;\r
306 \r
307     typedef UINT8                       EFI_PROCESSOR_THREAD_COUNT_DATA;\r
308 \r
309     typedef struct {\r
310       UINT16  Reserved              :1;\r
311       UINT16  Unknown               :1;\r
312       UINT16  Capable64Bit          :1;\r
313       UINT16  Reserved2             :13;\r
314     } EFI_PROCESSOR_CHARACTERISTICS_DATA;\r
315 \r
316     The fields listed here are *NOT* defined in ProcSubclass specification 0.9. They are introduced to support\r
317     new fields for type 4 defined in SmBios 2.6 specification. \r
318     Keeping this inconsistency to reflect the latest industry standard.\r
319 \r
320 ##\r
321 # Mismatch with Intel Platform Innovation Framework for MemSubclass Specification (Version 0.90)\r
322 ##\r
323   1. Guid/DataHubRecords.h\r
324     typedef enum _EFI_MEMORY_FORM_FACTOR {\r
325       ...\r
326       EfiMemoryFormFactorFbDimm                   = 0x0F\r
327     } EFI_MEMORY_FORM_FACTOR;\r
328     \r
329     typedef enum _EFI_MEMORY_ARRAY_TYPE {\r
330       ...\r
331       EfiMemoryTypeDdr2                           = 0x13,\r
332       EfiMemoryTypeDdr2FbDimm                     = 0x14\r
333     } EFI_MEMORY_ARRAY_TYPE;\r
334     \r
335     typedef enum {\r
336       ...\r
337       EfiMemoryStatePartial      = 6\r
338     } EFI_MEMORY_STATE;\r
339 \r
340     The fields listed above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r
341     new memory device (type 17) defined in SmBios 2.6 specification. \r
342     Keeping this inconsistency to reflect the latest industry standard.\r
343 \r
344   2. Guid/DataHubRecords.h\r
345     typedef struct { \r
346       ...\r
347       EFI_EXP_BASE10_DATA      MemorySpeed; \r
348       ...\r
349     } EFI_MEMORY_ARRAY_LINK_DATA;\r
350 \r
351     The field name "MemorySpeed" in the definition above is *NOT* consistent with MemSubclass specification 0.9,\r
352     in which it is defined as MemoryTypeSpeed. Keeping this inconsistency for backward compatibility.\r
353 \r
354   3. Guid/DataHubRecords.h\r
355     #define EFI_MEMORY_CONTROLLER_INFORMATION_RECORD_NUMBER    0x00000008\r
356 \r
357     typedef enum {  \r
358       EfiErrorDetectingMethodOther   = 1,\r
359       EfiErrorDetectingMethodUnknown = 2,\r
360       EfiErrorDetectingMethodNone    = 3,\r
361       EfiErrorDetectingMethodParity  = 4,\r
362       EfiErrorDetectingMethod32Ecc   = 5,\r
363       EfiErrorDetectingMethod64Ecc   = 6,\r
364       EfiErrorDetectingMethod128Ecc  = 7,\r
365       EfiErrorDetectingMethodCrc     = 8\r
366     } EFI_MEMORY_ERROR_DETECT_METHOD_TYPE;\r
367 \r
368     typedef struct {\r
369       UINT8                             Other                 :1;\r
370       UINT8                             Unknown               :1;\r
371       UINT8                             None                  :1;\r
372       UINT8                             SingleBitErrorCorrect :1;\r
373       UINT8                             DoubleBitErrorCorrect :1;\r
374       UINT8                             ErrorScrubbing        :1;\r
375       UINT8                             Reserved              :2;\r
376     } EFI_MEMORY_ERROR_CORRECT_CAPABILITY;\r
377 \r
378     typedef enum {  \r
379       EfiMemoryInterleaveOther      = 1,\r
380       EfiMemoryInterleaveUnknown    = 2,\r
381       EfiMemoryInterleaveOneWay     = 3,\r
382       EfiMemoryInterleaveTwoWay     = 4,\r
383       EfiMemoryInterleaveFourWay    = 5,\r
384       EfiMemoryInterleaveEightWay   = 6,\r
385       EfiMemoryInterleaveSixteenWay = 7\r
386     } EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE;\r
387 \r
388     typedef struct {\r
389       UINT16                            Other    :1;\r
390       UINT16                            Unknown  :1;\r
391       UINT16                            SeventyNs:1;\r
392       UINT16                            SixtyNs  :1;\r
393       UINT16                            FiftyNs  :1;\r
394       UINT16                            Reserved :11;\r
395     } EFI_MEMORY_SPEED_TYPE;\r
396 \r
397     typedef struct {\r
398       UINT16                            Other       :1;\r
399       UINT16                            Unknown     :1;\r
400       UINT16                            Standard    :1;\r
401       UINT16                            FastPageMode:1;\r
402       UINT16                            EDO         :1;\r
403       UINT16                            Parity      :1;\r
404       UINT16                            ECC         :1;\r
405       UINT16                            SIMM        :1;\r
406       UINT16                            DIMM        :1;\r
407       UINT16                            BurstEdo    :1;\r
408       UINT16                            SDRAM       :1;\r
409       UINT16                            Reserved    :5;\r
410     } EFI_MEMORY_SUPPORTED_TYPE;\r
411 \r
412     typedef struct {\r
413       UINT8                             Five    :1;\r
414       UINT8                             Three   :1;\r
415       UINT8                             Two     :1;\r
416       UINT8                             Reserved:5;\r
417     } EFI_MEMORY_MODULE_VOLTAGE_TYPE;\r
418 \r
419     typedef struct {\r
420       EFI_MEMORY_ERROR_DETECT_METHOD_TYPE ErrorDetectingMethod;\r
421       EFI_MEMORY_ERROR_CORRECT_CAPABILITY ErrorCorrectingCapability;\r
422       EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE  MemorySupportedInterleave;\r
423       EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE  MemoryCurrentInterleave;\r
424       UINT8                               MaxMemoryModuleSize;\r
425       EFI_MEMORY_SPEED_TYPE               MemorySpeedType;\r
426       EFI_MEMORY_SUPPORTED_TYPE           MemorySupportedType;\r
427       EFI_MEMORY_MODULE_VOLTAGE_TYPE      MemoryModuleVoltage;\r
428       UINT8                               NumberofMemorySlot;\r
429       EFI_MEMORY_ERROR_CORRECT_CAPABILITY EnabledCorrectingCapability;\r
430       UINT16                              *MemoryModuleConfigHandles;\r
431     } EFI_MEMORY_CONTROLLER_INFORMATION;\r
432 \r
433     typedef struct {\r
434       EFI_MEMORY_ERROR_DETECT_METHOD_TYPE   ErrorDetectingMethod;\r
435       EFI_MEMORY_ERROR_CORRECT_CAPABILITY   ErrorCorrectingCapability;\r
436       EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE    MemorySupportedInterleave;\r
437       EFI_MEMORY_SUPPORT_INTERLEAVE_TYPE    MemoryCurrentInterleave;\r
438       UINT8                                 MaxMemoryModuleSize;\r
439       EFI_MEMORY_SPEED_TYPE                 MemorySpeedType;\r
440       EFI_MEMORY_SUPPORTED_TYPE             MemorySupportedType;\r
441       EFI_MEMORY_MODULE_VOLTAGE_TYPE        MemoryModuleVoltage;\r
442       UINT8                                 NumberofMemorySlot;\r
443       EFI_MEMORY_ERROR_CORRECT_CAPABILITY   EnabledCorrectingCapability;\r
444       EFI_INTER_LINK_DATA                   MemoryModuleConfig[1];\r
445     } EFI_MEMORY_CONTROLLER_INFORMATION_DATA;\r
446 \r
447     The definitions above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r
448     new memory controller information (type 5) defined in SmBios 2.6 specification. \r
449     Keeping this inconsistency to reflect the latest industry standard.\r
450 \r
451   4. Guid/DataHubRecords.h\r
452     #define EFI_MEMORY_32BIT_ERROR_INFORMATION_RECORD_NUMBER    0x00000009\r
453 \r
454     typedef enum {  \r
455       EfiMemoryErrorOther             = 1,\r
456       EfiMemoryErrorUnknown           = 2,\r
457       EfiMemoryErrorOk                = 3,\r
458       EfiMemoryErrorBadRead           = 4,\r
459       EfiMemoryErrorParity            = 5,\r
460       EfiMemoryErrorSigleBit          = 6,\r
461       EfiMemoryErrorDoubleBit         = 7,\r
462       EfiMemoryErrorMultiBit          = 8,\r
463       EfiMemoryErrorNibble            = 9,\r
464       EfiMemoryErrorChecksum          = 10,\r
465       EfiMemoryErrorCrc               = 11,\r
466       EfiMemoryErrorCorrectSingleBit  = 12,\r
467       EfiMemoryErrorCorrected         = 13,\r
468       EfiMemoryErrorUnCorrectable     = 14\r
469     } EFI_MEMORY_ERROR_TYPE;\r
470 \r
471     typedef enum {  \r
472       EfiMemoryGranularityOther               = 1,\r
473       EfiMemoryGranularityOtherUnknown        = 2,\r
474       EfiMemoryGranularityDeviceLevel         = 3,\r
475       EfiMemoryGranularityMemPartitionLevel   = 4\r
476     } EFI_MEMORY_ERROR_GRANULARITY_TYPE;\r
477 \r
478     typedef enum {  \r
479       EfiMemoryErrorOperationOther            = 1,\r
480       EfiMemoryErrorOperationUnknown          = 2,\r
481       EfiMemoryErrorOperationRead             = 3,\r
482       EfiMemoryErrorOperationWrite            = 4,\r
483       EfiMemoryErrorOperationPartialWrite     = 5\r
484     } EFI_MEMORY_ERROR_OPERATION_TYPE;\r
485 \r
486     typedef struct {\r
487       EFI_MEMORY_ERROR_TYPE               MemoryErrorType;\r
488       EFI_MEMORY_ERROR_GRANULARITY_TYPE   MemoryErrorGranularity;\r
489       EFI_MEMORY_ERROR_OPERATION_TYPE     MemoryErrorOperation;\r
490       UINT32                              VendorSyndrome;\r
491       UINT32                              MemoryArrayErrorAddress;\r
492       UINT32                              DeviceErrorAddress;\r
493       UINT32                              DeviceErrorResolution;\r
494     } EFI_MEMORY_32BIT_ERROR_INFORMATION;\r
495 \r
496     The definitions above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r
497     new 32-bit memory error information (type 18) defined in SmBios 2.6 specification. \r
498     Keeping this inconsistency to reflect the latest industry standard.\r
499 \r
500   5. Guid/DataHubRecords.h\r
501     #define EFI_MEMORY_64BIT_ERROR_INFORMATION_RECORD_NUMBER    0x0000000A\r
502     \r
503     typedef struct {\r
504       EFI_MEMORY_ERROR_TYPE             MemoryErrorType;\r
505       EFI_MEMORY_ERROR_GRANULARITY_TYPE MemoryErrorGranularity;\r
506       EFI_MEMORY_ERROR_OPERATION_TYPE   MemoryErrorOperation;\r
507       UINT32                            VendorSyndrome;\r
508       UINT64                            MemoryArrayErrorAddress;\r
509       UINT64                            DeviceErrorAddress;\r
510       UINT32                            DeviceErrorResolution;\r
511     } EFI_MEMORY_64BIT_ERROR_INFORMATION;\r
512 \r
513     The definitions above are *NOT* defined in MemSubclass specification 0.9. They are introduced to support\r
514     new 64-bit memory error information (type 33) defined in SmBios 2.6 specification. \r
515     Keeping this inconsistency to reflect the latest industry standard.\r
516 \r
517   6. Guid/DataHubRecords.h\r
518     typedef union _EFI_MEMORY_SUBCLASS_RECORDS {\r
519       EFI_MEMORY_SIZE_DATA                 SizeData;\r
520       ...\r
521       EFI_MEMORY_64BIT_ERROR_INFORMATION   Memory64bitErrorInfo;\r
522     } EFI_MEMORY_SUBCLASS_RECORDS;\r
523 \r
524     typedef struct {\r
525       EFI_SUBCLASS_TYPE1_HEADER         Header;\r
526       EFI_MEMORY_SUBCLASS_RECORDS       Record;\r
527     } EFI_MEMORY_SUBCLASS_DRIVER_DATA;\r
528 \r
529     The definitions above are *NOT* defined in MemSubclass specification 0.9. EdkII introduces them to simplify the\r
530     code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r
531     Keeping this inconsistency for backward compatibility.\r
532 \r
533 ##\r
534 # Mismatch with Intel Platform Innovation Framework for MiscSubclass Specification (Version 0.90)\r
535 ##\r
536   1. Guid/DataHubRecords.h\r
537     #pragma pack(1)\r
538     typedef struct _USB_PORT_DEVICE_PATH {\r
539       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
540       PCI_DEVICE_PATH                   PciBusDevicePath;\r
541       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
542     } USB_PORT_DEVICE_PATH;\r
543     \r
544     typedef struct _IDE_DEVICE_PATH {\r
545       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
546       PCI_DEVICE_PATH                   PciBusDevicePath;\r
547       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
548     } IDE_DEVICE_PATH;\r
549     \r
550     typedef struct _RMC_CONN_DEVICE_PATH {\r
551       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
552       PCI_DEVICE_PATH                   PciBridgeDevicePath;\r
553       PCI_DEVICE_PATH                   PciBusDevicePath;\r
554       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
555     } RMC_CONN_DEVICE_PATH;\r
556     \r
557     typedef struct _RIDE_DEVICE_PATH {\r
558       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
559       PCI_DEVICE_PATH                   PciBridgeDevicePath;\r
560       PCI_DEVICE_PATH                   PciBusDevicePath;\r
561       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
562     } RIDE_DEVICE_PATH;\r
563     \r
564     typedef struct _GB_NIC_DEVICE_PATH {\r
565       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
566       PCI_DEVICE_PATH                   PciBridgeDevicePath;\r
567       PCI_DEVICE_PATH                   PciXBridgeDevicePath;\r
568       PCI_DEVICE_PATH                   PciXBusDevicePath;\r
569       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
570     } GB_NIC_DEVICE_PATH;\r
571     \r
572     typedef struct _PS2_CONN_DEVICE_PATH {\r
573       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
574       PCI_DEVICE_PATH                   LpcBridgeDevicePath;\r
575       ACPI_HID_DEVICE_PATH              LpcBusDevicePath;\r
576       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
577     } PS2_CONN_DEVICE_PATH;\r
578     \r
579     typedef struct _SERIAL_CONN_DEVICE_PATH {\r
580       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
581       PCI_DEVICE_PATH                   LpcBridgeDevicePath;\r
582       ACPI_HID_DEVICE_PATH              LpcBusDevicePath;\r
583       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
584     } SERIAL_CONN_DEVICE_PATH;\r
585     \r
586     typedef struct _PARALLEL_CONN_DEVICE_PATH {\r
587       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
588       PCI_DEVICE_PATH                   LpcBridgeDevicePath;\r
589       ACPI_HID_DEVICE_PATH              LpcBusDevicePath;\r
590       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
591     } PARALLEL_CONN_DEVICE_PATH;\r
592     \r
593     typedef struct _FLOOPY_CONN_DEVICE_PATH {\r
594       ACPI_HID_DEVICE_PATH              PciRootBridgeDevicePath;\r
595       PCI_DEVICE_PATH                   LpcBridgeDevicePath;\r
596       ACPI_HID_DEVICE_PATH              LpcBusDevicePath;\r
597       EFI_DEVICE_PATH_PROTOCOL          EndDevicePath;\r
598     } FLOOPY_CONN_DEVICE_PATH;\r
599     \r
600     typedef union _EFI_MISC_PORT_DEVICE_PATH {\r
601       USB_PORT_DEVICE_PATH              UsbDevicePath;\r
602       IDE_DEVICE_PATH                   IdeDevicePath;\r
603       RMC_CONN_DEVICE_PATH              RmcConnDevicePath;\r
604       RIDE_DEVICE_PATH                  RideDevicePath;\r
605       GB_NIC_DEVICE_PATH                GbNicDevicePath;\r
606       PS2_CONN_DEVICE_PATH              Ps2ConnDevicePath;\r
607       SERIAL_CONN_DEVICE_PATH           SerialConnDevicePath;\r
608       PARALLEL_CONN_DEVICE_PATH         ParallelConnDevicePath;\r
609       FLOOPY_CONN_DEVICE_PATH           FloppyConnDevicePath;\r
610     } EFI_MISC_PORT_DEVICE_PATH;\r
611     #pragma pack()\r
612 \r
613     a. The definitions above are *NOT* defined in MiscSubclass specifications 0.9. EdkII introduces them to simplify the\r
614        code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length device\r
615        path for various device.\r
616        Keeping this inconsistency for backward compatibility.\r
617 \r
618     b. The definitions above are packed. This way violates the rule of alignment defined in DataHubSubclass specification.\r
619        Section "Alignment" in DataHubSubclass specification say "Fields in a data hub record should be aligned at their\r
620        natural boundaries". Keeping this inconsistency for backward compatibility.\r
621 \r
622   2. Guid/DataHubRecords.h\r
623     typedef struct {\r
624       ...\r
625       EFI_MISC_PORT_DEVICE_PATH         PortPath;\r
626     } EFI_MISC_PORT_INTERNAL_CONNECTOR_DESIGNATOR_DATA;\r
627 \r
628     The definition is *NOT* consistent with MiscSubclass specification, in which the type of last field is defined as\r
629     "EFI_DEVICE_PATH_PROTOCOL". The definition in Specification may bring a little complexity on implementation. User\r
630     have to allocate variable length memory to contain device path info and free them finially.\r
631     EdkII introduced an union type named EFI_MISC_PORT_DEVICE_PATH to avoid the logic above.\r
632 \r
633   3. Guid/DataHubRecords.h\r
634     typedef struct {\r
635       ...\r
636       UINT8                                       BiosMajorRelease;\r
637       UINT8                                       BiosMinorRelease;\r
638       UINT8                                       BiosEmbeddedFirmwareMajorRelease;\r
639       UINT8                                       BiosEmbeddedFirmwareMinorRelease;\r
640     } EFI_MISC_BIOS_VENDOR_DATA;\r
641 \r
642     The fields listed above are *NOT* defined in MiscSubclass specification 0.9. They are introduced to support\r
643     new bios information (type 0) defined in SmBios 2.6 specification. \r
644     Keeping this inconsistency to reflect the latest industry standard.\r
645 \r
646   4. Guid/DataHubRecords.h\r
647     typedef struct {\r
648       ...\r
649       STRING_REF                        SystemSKUNumber;\r
650       STRING_REF                        SystemFamily;\r
651     } EFI_MISC_SYSTEM_MANUFACTURER_DATA;\r
652 \r
653     The fields listed above are *NOT* defined in MiscSubclass specification 0.9. They are introduced to support\r
654     new system information (type 1) defined in SmBios 2.6 specification. \r
655     Keeping this inconsistency to reflect the latest industry standard.\r
656 \r
657   5. Guid/DataHubRecords.h\r
658     typedef struct {\r
659       ...\r
660       EFI_INTER_LINK_DATA               ManagementDeviceThresholdLink;\r
661       UINT8                             ComponentType;\r
662     } EFI_MISC_MANAGEMENT_DEVICE_COMPONENT_DESCRIPTION_DATA;\r
663 \r
664     a. The field "ManagementDeviceThresholdLink" above is *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r
665        new management device component (type 35) defined in SmBios 2.6 specification. \r
666        Keeping this inconsistency to reflect the latest industry standard.\r
667     b. The field "ComponentType" above is *NOT* defined in MiscSubclass specifications 0.9. It's implementation-specific to simplify the code logic.\r
668        Keeping this inconsistency for backward compatibility.\r
669 \r
670   6. Guid/DataHubRecords.h\r
671     typedef struct {\r
672       UINT32                            ChassisType       :16;\r
673       UINT32                            ChassisLockPresent:1;\r
674       UINT32                            Reserved          :15;\r
675     } EFI_MISC_CHASSIS_STATUS;\r
676 \r
677     The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the first field is assigned a wrong field\r
678     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
679     field name again. EdkII changes its name to "ChassisType" to pass build.\r
680 \r
681   7. Guid/DataHubRecords.h\r
682     typedef enum {\r
683       ...\r
684       EfiSlotTypeAgp2X                  = 0x10,\r
685       ...\r
686       EfiSlotTypePciExpress             = 0xA5,\r
687       EfiSlotTypePciExpressX1           = 0xA6,\r
688       EfiSlotTypePciExpressX2           = 0xA7,\r
689       EfiSlotTypePciExpressX4           = 0xA8,\r
690       EfiSlotTypePciExpressX8           = 0xA9,\r
691       EfiSlotTypePciExpressX16          = 0xAA\r
692     } EFI_MISC_SLOT_TYPE;\r
693 \r
694     a. The field name "EfiSlotTypeAgp2X" is *NOT* consistent with MiscSubclass specification 0.9, in which it is named\r
695        "EfiSlotTypeApg2X".\r
696        From its literal sense, this field represents a AGP type display card, so it should be named as "EfiSlotTypeAgp2X".\r
697     b. The enumeration fields from "EfiSlotTypePciExpress" to "EfiSlotTypePciExpressX16" are *NOT* defined in MiscSubclass specification 0.9.\r
698        They are introduced to support new system slots (type 9) defined in SmBios 2.6 specification.\r
699        Keeping this inconsistency to reflect the latest industry standard.\r
700 \r
701   8. Guid/DataHubRecords.h\r
702     typedef struct {\r
703       ...\r
704       EFI_MISC_ONBOARD_DEVICE_STATUS    OnBoardDeviceStatus;\r
705       ...\r
706     } EFI_MISC_ONBOARD_DEVICE_DATA;\r
707 \r
708     The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the field "OnBoardDeviceStatus" is \r
709     named as "OnBoardDeviceType". Keeping this inconsistency for backward compatibility.\r
710 \r
711   9. Guid/DataHubRecords.h\r
712     #define EFI_MISC_PORTABLE_BATTERY_RECORD_NUMBER   0x00000010\r
713 \r
714     The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r
715     "EFI_MISC_BATTERY_LOCATION_RECORD_NUMBER". Keeping this inconsistency for backward compatibility.\r
716 \r
717   10. Guid/DataHubRecords.h\r
718     typedef enum {  \r
719       EfiPortableBatteryDeviceChemistryOther = 1,\r
720       EfiPortableBatteryDeviceChemistryUnknown = 2,\r
721       EfiPortableBatteryDeviceChemistryLeadAcid = 3,\r
722       EfiPortableBatteryDeviceChemistryNickelCadmium = 4,\r
723       EfiPortableBatteryDeviceChemistryNickelMetalHydride = 5,\r
724       EfiPortableBatteryDeviceChemistryLithiumIon = 6,\r
725       EfiPortableBatteryDeviceChemistryZincAir = 7,\r
726       EfiPortableBatteryDeviceChemistryLithiumPolymer = 8\r
727     } EFI_MISC_PORTABLE_BATTERY_DEVICE_CHEMISTRY;\r
728 \r
729     The name of the definition is *NOT* consistent with MiscSubclass specification, in which it is defined as\r
730     "EFI_MISC_BATTERY_DEVICE_CHEMISTRY". And all field names have a redundant "Portable" string compared with MisSubclass \r
731     specification 0.9.\r
732     Keeping this inconsistency for backward compatibility.\r
733 \r
734   11. Guid/DataHubRecords.h\r
735     typedef struct {\r
736       STRING_REF                                 Location;\r
737       STRING_REF                                 Manufacturer;\r
738       STRING_REF                                 ManufactureDate;\r
739       STRING_REF                                 SerialNumber;\r
740       STRING_REF                                 DeviceName;\r
741       EFI_MISC_PORTABLE_BATTERY_DEVICE_CHEMISTRY DeviceChemistry;\r
742       UINT16                                     DesignCapacity;\r
743       UINT16                                     DesignVoltage;\r
744       STRING_REF                                 SBDSVersionNumber;\r
745       UINT8                                      MaximumError;\r
746       UINT16                                     SBDSSerialNumber;\r
747       UINT16                                     SBDSManufactureDate;\r
748       STRING_REF                                 SBDSDeviceChemistry;\r
749       UINT8                                      DesignCapacityMultiplier;\r
750       UINT32                                     OEMSpecific;\r
751       UINT8                                      BatteryNumber;\r
752       BOOLEAN                                    Valid;\r
753     } EFI_MISC_PORTABLE_BATTERY;\r
754 \r
755     The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the structure name is defined as\r
756     "EFI_MISC_BATTERY_LOCATION_DATA". Moreover, the name and the order of all fields are also different with MiscSubclass \r
757     specification 0.9. Keeping this inconsistency for backward compatibility.\r
758 \r
759   12. Guid/DataHubRecords.h\r
760     typedef enum {\r
761       ...\r
762     } EFI_MISC_BOOT_INFORMATION_STATUS_DATA_TYPE;\r
763 \r
764     The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r
765     "EFI_MISC_BOOT_INFORMATION_STATUS_TYPE". Keeping this inconsistency for backward compatibility.\r
766 \r
767   13. Guid/DataHubRecords.h\r
768     typedef struct {\r
769       EFI_MISC_BOOT_INFORMATION_STATUS_DATA_TYPE BootInformationStatus;\r
770       ...\r
771     } EFI_MISC_BOOT_INFORMATION_STATUS_DATA;\r
772 \r
773     The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the type of the first field is \r
774     "EFI_MISC_BOOT_INFORMATION_STATUS_TYPE". Keeping this inconsistency for backward compatibility.\r
775 \r
776   14. Guid/DataHubRecords.h\r
777     typedef struct {\r
778       ...\r
779     } EFI_MISC_SYSTEM_POWER_SUPPLY_DATA;\r
780 \r
781     The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r
782     "EFI_MISC_POWER_SUPPLY_UNIT_GROUP_DATA". Keeping this inconsistency for backward compatibility.\r
783 \r
784   15. Guid/DataHubRecords.h\r
785     typedef struct {\r
786       ...\r
787     } SMBIOS_STRUCTURE_HDR;\r
788 \r
789     The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which the structure name\r
790     is defined as "EFI_SMBIOS_STRUCTURE_HDR". Due to this structure is commonly used by vendor to construct SmBios\r
791     type 0x80~0xFF table, Keeping this inconsistency for backward compatibility.\r
792 \r
793   16. Guid/DataHubRecords.h\r
794     typedef struct {\r
795       SMBIOS_STRUCTURE_HDR              Header;\r
796       ...\r
797     } EFI_MISC_SMBIOS_STRUCT_ENCAPSULATION_DATA;\r
798 \r
799     The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the type of the first field is \r
800     "EFI_SMBIOS_STRUCTURE_HDR". Keeping this inconsistency for backward compatibility.\r
801 \r
802   17. Guid/DataHubRecords.h\r
803     typedef struct {\r
804       UINT16                            PowerSupplyHotReplaceable:1;\r
805       UINT16                            PowerSupplyPresent       :1;\r
806       UINT16                            PowerSupplyUnplugged     :1;\r
807       UINT16                            InputVoltageRangeSwitch  :4;\r
808       UINT16                            PowerSupplyStatus        :3;\r
809       UINT16                            PowerSupplyType          :4;\r
810       UINT16                            Reserved                 :2;\r
811     } EFI_MISC_POWER_SUPPLY_CHARACTERISTICS;\r
812 \r
813     all field type in the definition are *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r
814     "UINT32" and the total width of bit-fields is 32bits width.\r
815     Keeping this inconsistency for backward compatibility.\r
816 \r
817   18. Guid/DataHubRecords.h\r
818     #define EFI_MISC_SYSTEM_EVENT_LOG_RECORD_NUMBER    0x00000020\r
819 \r
820     typedef struct {\r
821       UINT16                            LogAreaLength;\r
822       UINT16                            LogHeaderStartOffset;\r
823       UINT16                            LogDataStartOffset;\r
824       UINT8                             AccessMethod;\r
825       UINT8                             LogStatus;\r
826       UINT32                            LogChangeToken;\r
827       UINT32                            AccessMethodAddress;\r
828       UINT8                             LogHeaderFormat;\r
829       UINT8                             NumberOfSupportedLogType;\r
830       UINT8                             LengthOfLogDescriptor;\r
831     } EFI_MISC_SYSTEM_EVENT_LOG_DATA;\r
832 \r
833     #define ACCESS_INDEXIO_1INDEX8BIT_DATA8BIT    0x00\r
834     #define ACCESS_INDEXIO_2INDEX8BIT_DATA8BIT    0X01\r
835     #define ACCESS_INDEXIO_1INDEX16BIT_DATA8BIT   0X02\r
836     #define ACCESS_MEMORY_MAPPED                  0x03\r
837     #define ACCESS_GPNV                           0x04\r
838 \r
839     The definitions listed above are *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r
840     new system event log (type 15) defined in SmBios 2.6 specification. \r
841     Keeping this inconsistency to reflect the latest industry standard.\r
842 \r
843   19. Guid/DataHubRecords.h\r
844     #define EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD_RECORD_NUMBER    0x00000021\r
845 \r
846     typedef struct {\r
847       UINT16                            LowerThresNonCritical;\r
848       UINT16                            UpperThresNonCritical;\r
849       UINT16                            LowerThresCritical;\r
850       UINT16                            UpperThresCritical;\r
851       UINT16                            LowerThresNonRecover;\r
852       UINT16                            UpperThresNonRecover;\r
853     } EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD;\r
854 \r
855     The definitions listed above are *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r
856     new management device threshold data (type 36) defined in SmBios 2.6 specification. \r
857     Keeping this inconsistency to reflect the latest industry standard.\r
858 \r
859   20. Guid/DataHubRecords.h\r
860     typedef union {\r
861       EFI_MISC_LAST_PCI_BUS_DATA                         LastPciBus;\r
862       ...\r
863       EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD               MiscManagementDeviceThreshold;\r
864     } EFI_MISC_SUBCLASS_RECORDS;\r
865 \r
866     typedef struct {\r
867       EFI_SUBCLASS_TYPE1_HEADER         Header;\r
868       EFI_MISC_SUBCLASS_RECORDS         Record;\r
869     } EFI_MISC_SUBCLASS_DRIVER_DATA;\r
870 \r
871     The definitions above are *NOT* defined in MemSubclass specification 0.9. EdkII introduces them to simplify the\r
872     code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r
873     Keeping this inconsistency for backward compatibility.\r
874 \r
875   21. Guid/DataHubRecords.h\r
876     typedef struct {\r
877       EFI_MISC_COOLING_DEVICE_TYPE      CoolingDeviceType;\r
878       EFI_INTER_LINK_DATA               CoolingDeviceTemperatureLink;\r
879       UINT8                             CoolingDeviceUnitGroup;\r
880       UINT16                            CoolingDeviceNominalSpeed;\r
881       UINT32                            CoolingDeviceOemDefined;\r
882     } EFI_MISC_COOLING_DEVICE_TEMP_LINK_DATA;\r
883 \r
884     The "CoolingDeviceUnitGroup" field and "CoolingDeviceNominalSpeed" field are *NOT* consistent with \r
885     MiscSubclass specification 0.9. These fields are aligned with SMBIOS 2.6 specification. And user can easily\r
886     assign any value to CoolingDeviceNominalSpeed.\r
887 \r
888   22. Guid/DataHubRecords.h\r
889     typedef enum {\r
890       ...\r
891       EfiSlotDataBusWidth1xOrx1         = 0x8,\r
892       EfiSlotDataBusWidth2xOrx2         = 0x9,\r
893       EfiSlotDataBusWidth4xOrx4         = 0xA,\r
894       EfiSlotDataBusWidth8xOrx8         = 0xB,\r
895       EfiSlotDataBusWidth12xOrx12       = 0xC,\r
896       EfiSlotDataBusWidth16xOrx16       = 0xD,\r
897       EfiSlotDataBusWidth32xOrx32       = 0xE\r
898     } EFI_MISC_SLOT_DATA_BUS_WIDTH;\r
899 \r
900     The enumeration fields from "EfiSlotDataBusWidth1xOrx1" to "EfiSlotDataBusWidth32xOrx32" are *NOT* defined in MiscSubclass specification 0.9.\r
901     They are introduced to support new system slots (type 9) defined in SmBios 2.6 specification.\r
902     Keeping this inconsistency to reflect the latest industry standard.\r
903 \r
904   23. Guid/DataHubRecords.h\r
905     typedef struct {\r
906       ...\r
907       UINT16                            TemperatureProbeMaximumValue;\r
908       UINT16                            TemperatureProbeMinimumValue;\r
909       UINT16                            TemperatureProbeResolution;\r
910       UINT16                            TemperatureProbeTolerance;\r
911       UINT16                            TemperatureProbeAccuracy;\r
912       UINT16                            TemperatureProbeNominalValue;\r
913       UINT16                            MDLowerNoncriticalThreshold;\r
914       UINT16                            MDUpperNoncriticalThreshold;\r
915       UINT16                            MDLowerCriticalThreshold;\r
916       UINT16                            MDUpperCriticalThreshold;\r
917       UINT16                            MDLowerNonrecoverableThreshold;\r
918       UINT16                            MDUpperNonrecoverableThreshold;\r
919       ...\r
920     } EFI_MISC_TEMPERATURE_PROBE_DESCRIPTION_DATA;\r
921 \r
922     The structure fields from "TemperatureProbeMaximumValue" to "MDUpperNonrecoverableThreshold" are *NOT* consistent with MiscSubclass specification 0.9.\r
923     The specification defines the fields type as EFI_EXP_BASE10_DATA. In fact, they should be UINT16 type because they refer to 16bit width data.\r
924     Keeping this inconsistency for backward compatibility.\r
925 \r
926   24. Guid/DataHubRecords.h\r
927     #define EFI_MISC_IPMI_INTERFACE_TYPE_DATA_RECORD_NUMBER EFI_MISC_IPMI_INTERFACE_TYPE_RECORD_NUMBER\r
928 \r
929     The definition above is *NOT* defined in MiscSubclass specifications 0.9. It's defined for backward compatibility.\r
930 \r
931 ##\r
932 # Mismatch with Intel Platform Innovation Framework for Status Codes Specification (Version 0.92)\r
933 ##\r
934   1. Include/Framework/StatusCode.h\r
935     #define EFI_IOB_ATA_BUS_SMART_ENABLE               (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r
936     #define EFI_IOB_ATA_BUS_SMART_DISABLE              (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r
937     #define EFI_IOB_ATA_BUS_SMART_OVERTHRESHOLD        (EFI_SUBCLASS_SPECIFIC | 0x00000002)\r
938     #define EFI_IOB_ATA_BUS_SMART_UNDERTHRESHOLD       (EFI_SUBCLASS_SPECIFIC | 0x00000003)\r
939 \r
940     #define EFI_IOB_ATA_BUS_SMART_NOTSUPPORTED         (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r
941     #define EFI_IOB_ATA_BUS_SMART_DISABLED             (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r
942 \r
943     #define EFI_SW_DXE_BS_PC_BEGIN_CONNECTING_DRIVERS  (EFI_SUBCLASS_SPECIFIC | 0x00000005)\r
944     #define EFI_SW_DXE_BS_PC_VERIFYING_PASSWORD        (EFI_SUBCLASS_SPECIFIC | 0x00000006)\r
945 \r
946     #define EFI_SW_DXE_RT_PC_S0                        (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r
947     #define EFI_SW_DXE_RT_PC_S1                        (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r
948     #define EFI_SW_DXE_RT_PC_S2                        (EFI_SUBCLASS_SPECIFIC | 0x00000002)\r
949     #define EFI_SW_DXE_RT_PC_S3                        (EFI_SUBCLASS_SPECIFIC | 0x00000003)\r
950     #define EFI_SW_DXE_RT_PC_S4                        (EFI_SUBCLASS_SPECIFIC | 0x00000004)\r
951     #define EFI_SW_DXE_RT_PC_S5                        (EFI_SUBCLASS_SPECIFIC | 0x00000005)\r
952 \r
953     #define EFI_SW_CSM_LEGACY_ROM_INIT                 (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r
954 \r
955     The definitions above are *NOT* defined in Framework StatusCodes specification 0.92. But these subclass-specific error code\r
956     operations are needed for EdkII implementation.\r
957     Keeping this inconsistency for backward compatibility.\r
958 \r
959   2. Include/Framework/StatusCode.h\r
960     typedef union {\r
961       CHAR8   *Ascii;\r
962       CHAR16  *Unicode;\r
963       ...\r
964     } EFI_STATUS_CODE_STRING;\r
965 \r
966     The definition is *NOT* consistent with Framework SatausCodes specification 0.92, in which the first field is defined as "CHAR8 Ascii[]"\r
967     and the second field is defined as "CHAR16 Unicode[]". Keeping this inconsistency for backward compatibility.\r
968 \r
969   3. Include/Framework/StatusCode.h\r
970     #define EFI_SW_EC_X64_DIVIDE_ERROR      EXCEPT_X64_DIVIDE_ERROR\r
971     #define EFI_SW_EC_X64_DEBUG             EXCEPT_X64_DEBUG\r
972     #define EFI_SW_EC_X64_NMI               EXCEPT_X64_NMI\r
973     #define EFI_SW_EC_X64_BREAKPOINT        EXCEPT_X64_BREAKPOINT\r
974     #define EFI_SW_EC_X64_OVERFLOW          EXCEPT_X64_OVERFLOW\r
975     #define EFI_SW_EC_X64_BOUND             EXCEPT_X64_BOUND\r
976     #define EFI_SW_EC_X64_INVALID_OPCODE    EXCEPT_X64_INVALID_OPCODE\r
977     #define EFI_SW_EC_X64_DOUBLE_FAULT      EXCEPT_X64_DOUBLE_FAULT\r
978     #define EFI_SW_EC_X64_INVALID_TSS       EXCEPT_X64_INVALID_TSS\r
979     #define EFI_SW_EC_X64_SEG_NOT_PRESENT   EXCEPT_X64_SEG_NOT_PRESENT\r
980     #define EFI_SW_EC_X64_STACK_FAULT       EXCEPT_X64_STACK_FAULT\r
981     #define EFI_SW_EC_X64_GP_FAULT          EXCEPT_X64_GP_FAULT\r
982     #define EFI_SW_EC_X64_PAGE_FAULT        EXCEPT_X64_PAGE_FAULT\r
983     #define EFI_SW_EC_X64_FP_ERROR          EXCEPT_X64_FP_ERROR\r
984     #define EFI_SW_EC_X64_ALIGNMENT_CHECK   EXCEPT_X64_ALIGNMENT_CHECK\r
985     #define EFI_SW_EC_X64_MACHINE_CHECK     EXCEPT_X64_MACHINE_CHECK\r
986     #define EFI_SW_EC_X64_SIMD              EXCEPT_X64_SIMD\r
987 \r
988     The definitions are *NOT* defined in Framework StatusCodes specification 0.92, in which IA32 and IPF exception subclass error code definitions\r
989     are defined but omit the corresponding definitions for X64. EdkII introduce these definitions for implementation. \r
990 \r
991 ##\r
992 # Mismatch with Intel Platform Innovation Framework for EFI Boot Script Specification (Version 0.91)\r
993 ##\r
994   1. Include/Protocol/BootScriptSave.h\r
995     #define EFI_BOOT_SCRIPT_SAVE_PROTOCOL_GUID \\r
996     { \\r
997       0x470e1529, 0xb79e, 0x4e32, {0xa0, 0xfe, 0x6a, 0x15, 0x6d, 0x29, 0xf9, 0xb2 } \\r
998     }\r
999 \r
1000     The macro name "EFI_BOOT_SCRIPT_SAVE_PROTOCOL_GUID" is *NOT* consistent with Framework BootScript specification 0.91,\r
1001     in which it's defined as "EFI_BOOT_SCRIPT_SAVE_GUID". Keeping this inconsistency for backward compatibility.\r
1002 \r
1003   2. Include/Protocol/BootScriptSave.h\r
1004     EFI_STATUS\r
1005     EFI_BOOTSERVICE\r
1006     (EFIAPI *EFI_BOOT_SCRIPT_WRITE) (\r
1007       IN EFI_BOOT_SCRIPT_SAVE_PROTOCOL            *This,\r
1008       ...\r
1009     );\r
1010 \r
1011     The first parameter's type is *NOT* consistent with Framework BootScript specification 0.91, in which it's defined as\r
1012     "struct _EFI_BOOT_SCRIPT_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r
1013 \r
1014   3. Include/Framework/BootScript.h\r
1015     #define EFI_BOOT_SCRIPT_MEM_POLL_OPCODE               0x09\r
1016     #define EFI_BOOT_SCRIPT_INFORMATION_OPCODE            0x0A\r
1017     #define EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE      0x0B\r
1018     #define EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE 0x0C\r
1019     #define EFI_BOOT_SCRIPT_DISPATCH_2_OPCODE             0x0D\r
1020 \r
1021     The OPCODEs above are not defined in Framework BootScript Specification 0.91, but adopted by PI 1.0 Spec. And they\r
1022     are needed for EdkII implementation.\r
1023 \r
1024   4. Include/Framework/BootScript.h\r
1025     #define EFI_BOOT_SCRIPT_TABLE_OPCODE                  0xAA\r
1026     #define EFI_BOOT_SCRIPT_TERMINATE_OPCODE              0xFF\r
1027 \r
1028     The two OPCODEs are *NOT* defined in Framework BootScript specification 0.91. EdkII introduces them to indicate the start\r
1029     or end of the boot script table.\r
1030     Keeping this inconsistency for backward compatibility.\r
1031 \r
1032   5. Include/Protocol/BootScriptSave.h\r
1033     typedef  \r
1034     EFI_STATUS  \r
1035     (EFIAPI *EFI_BOOT_SCRIPT_CLOSE_TABLE) (\r
1036       IN  EFI_BOOT_SCRIPT_SAVE_PROTOCOL            *This,\r
1037       ...\r
1038       );\r
1039 \r
1040     The first parameter's type is *NOT* consistent with BootScript specification, in which it's defined as\r
1041     "struct _EFI_BOOT_SCRIPT_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r
1042 \r
1043   6. Include/Include/BootScriptExecuter.h\r
1044     typedef\r
1045     EFI_STATUS\r
1046     (EFIAPI *EFI_PEI_BOOT_SCRIPT_EXECUTE)(\r
1047       IN     EFI_PEI_SERVICES                        **PeiServices,\r
1048       IN     EFI_PEI_BOOT_SCRIPT_EXECUTER_PPI        *This,\r
1049       ...\r
1050       );\r
1051 \r
1052     The second parameter's type is *NOT* consistent with BootScript specification, in which it's defined as\r
1053     "struct _EFI_PEI_BOOT_SCRIPT_EXECUTER_PPI". Keeping this inconsistency for backward compatibility.\r
1054 \r
1055 ##\r
1056 # Mismatch with Intel Platform Innovation Framework for EFI DXE CIS (Version 0.91)\r
1057 ##\r
1058   1. Include/Framework/DxeCis.h\r
1059     EFI_STATUS_CODE_ARCH_PROTOCOL is removed.\r
1060     \r
1061     EdkII doesn't provide EFI_STATUS_CODE_ARCH_PROTOCOL definition due to ReportStatusCode() field has been\r
1062     removed from EFI Runtime Service Table of PI specification. EFI_STATUS_CODE_ARCH_PROTOCOL is *NOT* required,\r
1063     and is replaced with EFI_STATUS_CODE_RUNTIME_PROTOCOL.\r
1064 \r
1065 ##\r
1066 # Mismatch with Intel Platform Innovation Framework for EFI Firmware Volume Specification (Version 0.9)\r
1067 ##\r
1068   1. Include/Framework/FirmwareVolumeImageFormat.h\r
1069     #define EFI_AGGREGATE_AUTH_STATUS_ALL               0x00000f\r
1070     #define EFI_LOCAL_AUTH_STATUS_ALL                   0x0f0000\r
1071 \r
1072     The two macros are *NOT* defined in Framework FV specification 0.9. EdkII introduces them as a mask to calculate the\r
1073     value of authentication status.\r
1074 \r
1075 ##\r
1076 # Mismatch with Intel Platform Innovation Framework for EFI Human Interface Infrastructure Specification (Version 0.92)\r
1077 ##\r
1078   1. Include/Protocol/FrameworkHii.h\r
1079     #define EFI_HII_PROTOCOL_GUID \\r
1080       { \\r
1081         0xd7ad636e, 0xb997, 0x459b, {0xbf, 0x3f, 0x88, 0x46, 0x89, 0x79, 0x80, 0xe1} \\r
1082       }\r
1083 \r
1084     The Framework HII specification 0.92 changed part of HII interfaces but did not update the protocol GUID.\r
1085     This change should cause a change of GUID in both of code and HII spec. EdkII updates the GUID in code, \r
1086     but the Framework HII specification 0.92 is not updated. This is a known issue.\r
1087 \r
1088   2. Include/Protocol/FrameworkHii.h\r
1089     typedef struct {\r
1090       ...\r
1091       EFI_HANDLE          COBExportHandle;\r
1092     } EFI_HII_HANDLE_PACK;\r
1093 \r
1094     The last field "COBExportHandle" of EFI_HII_HANDLE_PACK is *NOT* defined in the Framework HII specification\r
1095     0.92. Keeping this inconsistency for backward compatibility.\r
1096 \r
1097   3. Include/Protocol/FrameworkHii.h\r
1098     typedef struct {\r
1099       UINTN     NumberOfPackages;\r
1100       EFI_GUID  *GuidId;\r
1101     } EFI_HII_PACKAGES;\r
1102 \r
1103     The definition is *NOT* consistent with Framework HII specification 0.92, in which a field "HandlePack" is defined.\r
1104     EdkII changes the EFI_HII_PACKAGES to contain various number of packages of different types just after the structure\r
1105     as inline data, which will bring the flexibility on development.\r
1106 \r
1107   4. Include/Protocol/FrameworkHii.h\r
1108     struct _EFI_HII_PROTOCOL {\r
1109       ...\r
1110       EFI_HII_RESET_STRINGS                 ResetStrings;\r
1111       ...\r
1112     };\r
1113 \r
1114     The field listed above is *NOT* defined in Framework HII specification 0.92. EdkII adds this field to provide \r
1115     an ability of removing any new strings that were added after the initial string export for this handle.  \r
1116 \r
1117   5. Include/Protocol/FrameworkHii.h\r
1118     typedef\r
1119     EFI_STATUS\r
1120     (EFIAPI *EFI_HII_GLYPH_TO_BLT)(\r
1121       ...\r
1122       IN     EFI_GRAPHICS_OUTPUT_BLT_PIXEL Foreground,\r
1123       IN     EFI_GRAPHICS_OUTPUT_BLT_PIXEL Background,\r
1124       ...\r
1125       IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer\r
1126       );\r
1127 \r
1128     The type of the parameters listed above are *NOT* consistent with Framework HII specification 0.92, in which\r
1129     the type of these parameters is EFI_UGA_PIXEL. Here the definition uses the EFI_GRAPHICS_OUTPUT_BLT_PIXEL which\r
1130     defined in UEFI2.1 spec. Keeping this inconsistency for backward compatibility.\r
1131 \r
1132   6. Include/Protocol/FrameworkHii.h\r
1133     typedef struct {\r
1134       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1135       UINT8                             Flags;\r
1136     } EFI_IFR_SUPPRESS;\r
1137     \r
1138     typedef struct {\r
1139       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1140       UINT8                             Flags;\r
1141     } EFI_IFR_GRAY_OUT;\r
1142     \r
1143     typedef struct {\r
1144       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1145       STRING_REF                        Popup;\r
1146       UINT8                             Flags;\r
1147     } EFI_IFR_INCONSISTENT;\r
1148     \r
1149     typedef struct {\r
1150       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1151       UINT16                            QuestionId;\r
1152       UINT8                             Width;\r
1153       UINT16                            Value;\r
1154     } FRAMEWORK_EFI_IFR_EQ_ID_VAL;\r
1155     \r
1156     typedef struct {\r
1157       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1158       UINT16                            QuestionId;\r
1159       UINT8                             Width;\r
1160       UINT16                            ListLength;\r
1161       UINT16                            ValueList[1];\r
1162     } FRAMEWORK_EFI_IFR_EQ_ID_LIST;\r
1163     \r
1164     typedef struct {\r
1165       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1166       UINT16                            QuestionId1;\r
1167       UINT8                             Width;\r
1168       UINT16                            QuestionId2;\r
1169     } FRAMEWORK_EFI_IFR_EQ_ID_ID;\r
1170     \r
1171     typedef struct {\r
1172       FRAMEWORK_EFI_IFR_OP_HEADER       Header;\r
1173       UINT16                            VariableId;\r
1174       UINT16                            Value;\r
1175     } EFI_IFR_EQ_VAR_VAL;\r
1176 \r
1177     The defintions are not complied with Framework HII spec 0.92. Keeping the inconsistent for implementation needed.\r
1178 \r
1179   7. Include/Protocol/FrameworkFormCallback.h\r
1180     #define RESET_REQUIRED  1 \r
1181     #define EXIT_REQUIRED   2\r
1182     #define SAVE_REQUIRED   4\r
1183     #define NV_CHANGED      8\r
1184     #define NV_NOT_CHANGED  16\r
1185 \r
1186     These macros are *NOT* defined in the Framework HII specification 0.92. These Flags are introduced to describe\r
1187     the standard behavior of the browser after the callback.\r
1188     Keeping this inconsistency for backward compatibility.\r
1189 \r
1190   8. Include/Protocol/FrameworkFormCallback.h\r
1191     typedef\r
1192     EFI_STATUS\r
1193     (EFIAPI *EFI_NV_WRITE)(\r
1194       ...\r
1195       IN     UINT32                        Attributes,\r
1196       ...\r
1197       );\r
1198 \r
1199     The definition is *NOT* consistent with Framework HII specification 0.92, in which the type of Attributes\r
1200     parameter is defined as "UINT32 *". EdkII changes the type of Attributes from UINT32 * to UINT32 because\r
1201     the input paramter is not necessary to use pointer date type.\r
1202 \r
1203 ##\r
1204 # Mismatch with Intel Platform Innovation Framework for PEI CIS Specification (Version 0.91)\r
1205 ##\r
1206   1. Include/Ppi/ReadOnlyVariable.h\r
1207     #define EFI_VARIABLE_READ_ONLY          0x00000008\r
1208 \r
1209     In Framework PeiCis specification 0.91, neither the macro or its value is defined.\r
1210     Keeping this inconsistency for backward compatibility.\r
1211 \r
1212   2. Include/Ppi/FindFv.h\r
1213     typedef\r
1214     EFI_STATUS\r
1215     (EFIAPI *EFI_PEI_FIND_FV_FINDFV)(\r
1216       IN EFI_PEI_FIND_FV_PPI             *This,\r
1217       IN EFI_PEI_SERVICES                **PeiServices,\r
1218       IN UINT8                           *FvNumber,\r
1219       IN OUT EFI_FIRMWARE_VOLUME_HEADER  **FVAddress\r
1220       );\r
1221 \r
1222     The definition is *NOT* consistent with Framework PeiCis specification 0.91. Compared with spec, the order\r
1223     of the first and second parameters is reversed. Keeping this inconsistency for backward compatibility.\r
1224 \r
1225 ##\r
1226 # Mismatch with Intel Platform Innovation Framework for EFI SMM CIS (Version 0.91)\r
1227 ##\r
1228   1. Include/Guid/SmramMemoryReserve.h\r
1229     typedef struct {\r
1230       UINT32                NumberOfSmmReservedRegions;\r
1231       ...\r
1232     } EFI_SMRAM_HOB_DESCRIPTOR_BLOCK;\r
1233 \r
1234     1) The name of the definition is *NOT* consistent with Framework SmmCis specification 0.91, in which it's \r
1235     defined as "EFI_HOB_SMRAM_DESCRIPTOR_BLOCK" rather than "EFI_SMRAM_HOB_DESCRIPTOR_BLOCK". \r
1236     Keeping this inconsistency for backward compatibility.\r
1237 \r
1238     2) The definition of NumberOfSmmReservedRegions is *NOT* consistent with Framework SmmCis specification 0.91,\r
1239     in which the type of this field is defined as UINTN. However, HOBs are supposed to be CPU neutral, so UINTN\r
1240     is incorrect and UINT32 should be used.\r
1241 \r
1242   2. Include/Guid/SmramMemoryReserve.h\r
1243     typedef enum {\r
1244       ...\r
1245       IchnIoTrap3,\r
1246       IchnIoTrap2,\r
1247       IchnIoTrap1,\r
1248       IchnIoTrap0,\r
1249       IchnPciExpress,\r
1250       IchnMonitor,\r
1251       IchnSpi,\r
1252       IchnQRT,\r
1253       IchnGpioUnlock,\r
1254       ...\r
1255     } EFI_SMM_ICHN_SMI_TYPE;\r
1256 \r
1257     The enumeration fields listed above are *NOT* defined in Framework SmmCis specification 0.91. EdkII introduces\r
1258     these fields to support new SMI types.\r
1259 \r
1260   3. Include/Framework/SmmCis.h\r
1261     typedef union {\r
1262       ///\r
1263       /// The processor save-state information for IA-32 processors. \r
1264       ///\r
1265       EFI_SMI_CPU_SAVE_STATE     Ia32SaveState;\r
1266       ///\r
1267       /// Note: Inconsistency with the Framework SMM CIS spec - Itanium save state not included.\r
1268       ///\r
1269       /// The processor save-state information for Itanium processors.\r
1270       ///\r
1271       /// EFI_PMI_SYSTEM_CONTEXT ItaniumSaveState;\r
1272     } EFI_SMM_CPU_SAVE_STATE;\r
1273 \r
1274 ##\r
1275 # Mismatch with Intel Platform Innovation Framework for EFI S3 Resume Boot Path Specification (Version 0.9)\r
1276 ##\r
1277   1. Include/Protocol/AcpiS3Save.h\r
1278     typedef\r
1279     EFI_STATUS\r
1280     EFI_BOOTSERVICE\r
1281     (EFIAPI *EFI_ACPI_GET_LEGACY_MEMORY_SIZE) (\r
1282       IN  EFI_ACPI_S3_SAVE_PROTOCOL *This,\r
1283       OUT UINTN *Size\r
1284       );\r
1285 \r
1286     The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r
1287     "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r
1288 \r
1289   2. Include/Protocol/AcpiS3Save.h\r
1290     typedef\r
1291     EFI_STATUS\r
1292     (EFIAPI *EFI_ACPI_S3_SAVE) (\r
1293       IN EFI_ACPI_S3_SAVE_PROTOCOL      *This,\r
1294       IN VOID                           *LegacyMemoryAddress \r
1295       );\r
1296 \r
1297     The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r
1298     "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Also the EFI_BOOTSERVICE modifier is removed from the function declaration.\r
1299 \r
1300   3. Include/Protocol/AcpiS3Save.h\r
1301     typedef\r
1302     EFI_STATUS\r
1303     (EFIAPI *EFI_ACPI_GET_LEGACY_MEMORY_SIZE)(\r
1304       IN  EFI_ACPI_S3_SAVE_PROTOCOL     *This,\r
1305       OUT UINTN                         *Size\r
1306     );\r
1307 \r
1308     The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r
1309     "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Also the EFI_BOOTSERVICE modifier is removed from the function declaration.\r
1310 \r
1311 ##\r
1312 # Mismatch with Intel Platform Innovation Framework for EFI ACPI Specification (Version 0.91)\r
1313 ##\r
1314   1. Include/Protocol/AcpiSupport.h\r
1315     typedef\r
1316     EFI_STATUS\r
1317     (EFIAPI *EFI_ACPI_GET_ACPI_TABLE)(\r
1318       ...\r
1319       );\r
1320 \r
1321     The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r
1322     is removed from the function declaration.\r
1323 \r
1324   2. Include/Protocol/AcpiSupport.h\r
1325     typedef\r
1326     EFI_STATUS\r
1327     (EFIAPI *EFI_ACPI_SET_ACPI_TABLE)(\r
1328       ...\r
1329       );\r
1330 \r
1331     The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r
1332     is removed from the function declaration.\r
1333 \r
1334   3. Include/Protocol/AcpiSupport.h\r
1335     typedef\r
1336     EFI_STATUS\r
1337     (EFIAPI *EFI_ACPI_PUBLISH_TABLES)(\r
1338       ...\r
1339       );\r
1340 \r
1341     The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r
1342     is removed from the function declaration.\r