]>
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 | |
f92d1031 | 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 | |
b1fe77c9 | 236 | } EFI_CPU_VARIABLE_RECORD_TYPE;\r |
237 | \r | |
f92d1031 | 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 | |
b1fe77c9 | 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 | |
f92d1031 | 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 | |
b1fe77c9 | 271 | 8. Guid/DataHubRecords.h\r |
272 | typedef union {\r | |
273 | EFI_PROCESSOR_CORE_FREQUENCY_LIST_DATA ProcessorCoreFrequencyList;\r | |
274 | ...\r | |
f92d1031 | 275 | EFI_PROCESSOR_FAMILY2_DATA ProcessorFamily2;\r |
b1fe77c9 | 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 | |
f92d1031 | 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 | |
b1fe77c9 | 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 | } EFI_MISC_MANAGEMENT_DEVICE_COMPONENT_DESCRIPTION_DATA;\r | |
662 | \r | |
663 | The field listed above is *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r | |
664 | new management device component (type 35) defined in SmBios 2.6 specification. \r | |
665 | Keeping this inconsistency to reflect the latest industry standard.\r | |
666 | \r | |
667 | 6. Guid/DataHubRecords.h\r | |
668 | typedef struct {\r | |
669 | UINT32 ChassisType :16;\r | |
670 | UINT32 ChassisLockPresent:1;\r | |
671 | UINT32 Reserved :15;\r | |
672 | } EFI_MISC_CHASSIS_STATUS;\r | |
673 | \r | |
674 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the first field is assigned a wrong field\r | |
675 | 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 | |
676 | field name again. EdkII changes its name to "ChassisType" to pass build.\r | |
677 | \r | |
678 | 7. Guid/DataHubRecords.h\r | |
679 | typedef enum {\r | |
680 | ...\r | |
681 | EfiSlotTypeAgp2X = 0x10,\r | |
682 | ...\r | |
683 | EfiSlotTypePciExpress = 0xA5\r | |
684 | } EFI_MISC_SLOT_TYPE;\r | |
685 | \r | |
686 | a. The field name "EfiSlotTypeAgp2X" is *NOT* consistent with MiscSubclass specification 0.9, in which it is named\r | |
687 | "EfiSlotTypeApg2X".\r | |
688 | From its literal sense, this field represents a AGP type display card, so it should be named as "EfiSlotTypeAgp2X".\r | |
689 | b. The "EfiSlotTypePciExpress" field is *NOT* defined in MiscSubclass specification 0.9. It isintroduced to support\r | |
690 | new system slots (type 9) defined in SmBios 2.6 specification.\r | |
691 | Keeping this inconsistency to reflect the latest industry standard.\r | |
692 | \r | |
693 | 8. Guid/DataHubRecords.h\r | |
694 | typedef struct {\r | |
695 | ...\r | |
696 | EFI_MISC_ONBOARD_DEVICE_STATUS OnBoardDeviceStatus;\r | |
697 | ...\r | |
698 | } EFI_MISC_ONBOARD_DEVICE_DATA;\r | |
699 | \r | |
700 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the field "OnBoardDeviceStatus" is \r | |
701 | named as "OnBoardDeviceType". Keeping this inconsistency for backward compatibility.\r | |
702 | \r | |
703 | 9. Guid/DataHubRecords.h\r | |
704 | #define EFI_MISC_PORTABLE_BATTERY_RECORD_NUMBER 0x00000010\r | |
705 | \r | |
706 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r | |
707 | "EFI_MISC_BATTERY_LOCATION_RECORD_NUMBER". Keeping this inconsistency for backward compatibility.\r | |
708 | \r | |
709 | 10. Guid/DataHubRecords.h\r | |
710 | typedef enum { \r | |
711 | EfiPortableBatteryDeviceChemistryOther = 1,\r | |
712 | EfiPortableBatteryDeviceChemistryUnknown = 2,\r | |
713 | EfiPortableBatteryDeviceChemistryLeadAcid = 3,\r | |
714 | EfiPortableBatteryDeviceChemistryNickelCadmium = 4,\r | |
715 | EfiPortableBatteryDeviceChemistryNickelMetalHydride = 5,\r | |
716 | EfiPortableBatteryDeviceChemistryLithiumIon = 6,\r | |
717 | EfiPortableBatteryDeviceChemistryZincAir = 7,\r | |
718 | EfiPortableBatteryDeviceChemistryLithiumPolymer = 8\r | |
719 | } EFI_MISC_PORTABLE_BATTERY_DEVICE_CHEMISTRY;\r | |
720 | \r | |
721 | The name of the definition is *NOT* consistent with MiscSubclass specification, in which it is defined as\r | |
722 | "EFI_MISC_BATTERY_DEVICE_CHEMISTRY". And all field names have a redundant "Portable" string compared with MisSubclass \r | |
723 | specification 0.9.\r | |
724 | Keeping this inconsistency for backward compatibility.\r | |
725 | \r | |
726 | 11. Guid/DataHubRecords.h\r | |
727 | typedef struct {\r | |
728 | STRING_REF Location;\r | |
729 | STRING_REF Manufacturer;\r | |
730 | STRING_REF ManufactureDate;\r | |
731 | STRING_REF SerialNumber;\r | |
732 | STRING_REF DeviceName;\r | |
733 | EFI_MISC_PORTABLE_BATTERY_DEVICE_CHEMISTRY DeviceChemistry;\r | |
734 | UINT16 DesignCapacity;\r | |
735 | UINT16 DesignVoltage;\r | |
736 | STRING_REF SBDSVersionNumber;\r | |
737 | UINT8 MaximumError;\r | |
738 | UINT16 SBDSSerialNumber;\r | |
739 | UINT16 SBDSManufactureDate;\r | |
740 | STRING_REF SBDSDeviceChemistry;\r | |
741 | UINT8 DesignCapacityMultiplier;\r | |
742 | UINT32 OEMSpecific;\r | |
743 | UINT8 BatteryNumber;\r | |
744 | BOOLEAN Valid;\r | |
745 | } EFI_MISC_PORTABLE_BATTERY;\r | |
746 | \r | |
747 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the structure name is defined as\r | |
748 | "EFI_MISC_BATTERY_LOCATION_DATA". Moreover, the name and the order of all fields are also different with MiscSubclass \r | |
749 | specification 0.9. Keeping this inconsistency for backward compatibility.\r | |
750 | \r | |
751 | 12. Guid/DataHubRecords.h\r | |
752 | typedef enum {\r | |
753 | ...\r | |
754 | } EFI_MISC_BOOT_INFORMATION_STATUS_DATA_TYPE;\r | |
755 | \r | |
756 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r | |
757 | "EFI_MISC_BOOT_INFORMATION_STATUS_TYPE". Keeping this inconsistency for backward compatibility.\r | |
758 | \r | |
759 | 13. Guid/DataHubRecords.h\r | |
760 | typedef struct {\r | |
761 | EFI_MISC_BOOT_INFORMATION_STATUS_DATA_TYPE BootInformationStatus;\r | |
762 | ...\r | |
763 | } EFI_MISC_BOOT_INFORMATION_STATUS_DATA;\r | |
764 | \r | |
765 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the type of the first field is \r | |
766 | "EFI_MISC_BOOT_INFORMATION_STATUS_TYPE". Keeping this inconsistency for backward compatibility.\r | |
767 | \r | |
768 | 14. Guid/DataHubRecords.h\r | |
769 | typedef struct {\r | |
770 | ...\r | |
771 | } EFI_MISC_SYSTEM_POWER_SUPPLY_DATA;\r | |
772 | \r | |
773 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r | |
774 | "EFI_MISC_POWER_SUPPLY_UNIT_GROUP_DATA". Keeping this inconsistency for backward compatibility.\r | |
775 | \r | |
776 | 15. Guid/DataHubRecords.h\r | |
777 | typedef struct {\r | |
778 | ...\r | |
779 | } SMBIOS_STRUCTURE_HDR;\r | |
780 | \r | |
781 | The name of the definition is *NOT* consistent with MiscSubclass specification 0.9, in which the structure name\r | |
782 | is defined as "EFI_SMBIOS_STRUCTURE_HDR". Due to this structure is commonly used by vendor to construct SmBios\r | |
783 | type 0x80~0xFF table, Keeping this inconsistency for backward compatibility.\r | |
784 | \r | |
785 | 16. Guid/DataHubRecords.h\r | |
786 | typedef struct {\r | |
787 | SMBIOS_STRUCTURE_HDR Header;\r | |
788 | ...\r | |
789 | } EFI_MISC_SMBIOS_STRUCT_ENCAPSULATION_DATA;\r | |
790 | \r | |
791 | The definition is *NOT* consistent with MiscSubclass specification 0.9, in which the type of the first field is \r | |
792 | "EFI_SMBIOS_STRUCTURE_HDR". Keeping this inconsistency for backward compatibility.\r | |
793 | \r | |
794 | 17. Guid/DataHubRecords.h\r | |
795 | typedef struct {\r | |
796 | UINT16 PowerSupplyHotReplaceable:1;\r | |
797 | UINT16 PowerSupplyPresent :1;\r | |
798 | UINT16 PowerSupplyUnplugged :1;\r | |
799 | UINT16 InputVoltageRangeSwitch :4;\r | |
800 | UINT16 PowerSupplyStatus :3;\r | |
801 | UINT16 PowerSupplyType :4;\r | |
802 | UINT16 Reserved :2;\r | |
803 | } EFI_MISC_POWER_SUPPLY_CHARACTERISTICS;\r | |
804 | \r | |
805 | all field type in the definition are *NOT* consistent with MiscSubclass specification 0.9, in which it is defined as\r | |
806 | "UINT32" and the total width of bit-fields is 32bits width.\r | |
807 | Keeping this inconsistency for backward compatibility.\r | |
808 | \r | |
809 | 18. Guid/DataHubRecords.h\r | |
810 | #define EFI_MISC_SYSTEM_EVENT_LOG_RECORD_NUMBER 0x00000020\r | |
811 | \r | |
812 | typedef struct {\r | |
813 | UINT16 LogAreaLength;\r | |
814 | UINT16 LogHeaderStartOffset;\r | |
815 | UINT16 LogDataStartOffset;\r | |
816 | UINT8 AccessMethod;\r | |
817 | UINT8 LogStatus;\r | |
818 | UINT32 LogChangeToken;\r | |
819 | UINT32 AccessMethodAddress;\r | |
820 | UINT8 LogHeaderFormat;\r | |
821 | UINT8 NumberOfSupportedLogType;\r | |
822 | UINT8 LengthOfLogDescriptor;\r | |
823 | } EFI_MISC_SYSTEM_EVENT_LOG_DATA;\r | |
824 | \r | |
825 | #define ACCESS_INDEXIO_1INDEX8BIT_DATA8BIT 0x00\r | |
826 | #define ACCESS_INDEXIO_2INDEX8BIT_DATA8BIT 0X01\r | |
827 | #define ACCESS_INDEXIO_1INDEX16BIT_DATA8BIT 0X02\r | |
828 | #define ACCESS_MEMORY_MAPPED 0x03\r | |
829 | #define ACCESS_GPNV 0x04\r | |
830 | \r | |
831 | The definitions listed above are *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r | |
832 | new system event log (type 15) defined in SmBios 2.6 specification. \r | |
833 | Keeping this inconsistency to reflect the latest industry standard.\r | |
834 | \r | |
835 | 19. Guid/DataHubRecords.h\r | |
836 | #define EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD_RECORD_NUMBER 0x00000021\r | |
837 | \r | |
838 | typedef struct {\r | |
839 | UINT16 LowerThresNonCritical;\r | |
840 | UINT16 UpperThresNonCritical;\r | |
841 | UINT16 LowerThresCritical;\r | |
842 | UINT16 UpperThresCritical;\r | |
843 | UINT16 LowerThresNonRecover;\r | |
844 | UINT16 UpperThresNonRecover;\r | |
845 | } EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD;\r | |
846 | \r | |
847 | The definitions listed above are *NOT* defined in MiscSubclass specification 0.9. It is introduced to support\r | |
848 | new management device threshold data (type 36) defined in SmBios 2.6 specification. \r | |
849 | Keeping this inconsistency to reflect the latest industry standard.\r | |
850 | \r | |
851 | 20. Guid/DataHubRecords.h\r | |
852 | typedef union {\r | |
853 | EFI_MISC_LAST_PCI_BUS_DATA LastPciBus;\r | |
854 | ...\r | |
855 | EFI_MISC_MANAGEMENT_DEVICE_THRESHOLD MiscManagementDeviceThreshold;\r | |
856 | } EFI_MISC_SUBCLASS_RECORDS;\r | |
857 | \r | |
858 | typedef struct {\r | |
859 | EFI_SUBCLASS_TYPE1_HEADER Header;\r | |
860 | EFI_MISC_SUBCLASS_RECORDS Record;\r | |
861 | } EFI_MISC_SUBCLASS_DRIVER_DATA;\r | |
862 | \r | |
863 | The definitions above are *NOT* defined in MemSubclass specification 0.9. EdkII introduces them to simplify the\r | |
864 | code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r | |
865 | Keeping this inconsistency for backward compatibility.\r | |
866 | \r | |
4eb56285 | 867 | 21. Guid/DataHubRecords.h\r |
868 | typedef struct {\r | |
869 | EFI_MISC_COOLING_DEVICE_TYPE CoolingDeviceType;\r | |
870 | EFI_INTER_LINK_DATA CoolingDeviceTemperatureLink;\r | |
871 | UINT8 CoolingDeviceUnitGroup;\r | |
872 | UINT16 CoolingDeviceNominalSpeed;\r | |
873 | UINT32 CoolingDeviceOemDefined;\r | |
874 | } EFI_MISC_COOLING_DEVICE_TEMP_LINK_DATA;\r | |
875 | \r | |
876 | The "CoolingDeviceUnitGroup" field and "CoolingDeviceNominalSpeed" field are *NOT* consistent with \r | |
877 | MiscSubclass specification 0.9. These fields are aligned with SMBIOS 2.6 specification. And user can easily\r | |
878 | assign any value to CoolingDeviceNominalSpeed.\r | |
879 | \r | |
b1fe77c9 | 880 | ##\r |
881 | # Mismatch with Intel Platform Innovation Framework for Status Codes Specification (Version 0.92)\r | |
882 | ##\r | |
883 | 1. Include/Framework/StatusCode.h\r | |
884 | #define EFI_IOB_ATA_BUS_SMART_ENABLE (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r | |
885 | #define EFI_IOB_ATA_BUS_SMART_DISABLE (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r | |
886 | #define EFI_IOB_ATA_BUS_SMART_OVERTHRESHOLD (EFI_SUBCLASS_SPECIFIC | 0x00000002)\r | |
887 | #define EFI_IOB_ATA_BUS_SMART_UNDERTHRESHOLD (EFI_SUBCLASS_SPECIFIC | 0x00000003)\r | |
888 | \r | |
889 | #define EFI_IOB_ATA_BUS_SMART_NOTSUPPORTED (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r | |
890 | #define EFI_IOB_ATA_BUS_SMART_DISABLED (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r | |
891 | \r | |
892 | #define EFI_SW_DXE_BS_PC_BEGIN_CONNECTING_DRIVERS (EFI_SUBCLASS_SPECIFIC | 0x00000005)\r | |
893 | #define EFI_SW_DXE_BS_PC_VERIFYING_PASSWORD (EFI_SUBCLASS_SPECIFIC | 0x00000006)\r | |
894 | \r | |
895 | #define EFI_SW_DXE_RT_PC_S0 (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r | |
896 | #define EFI_SW_DXE_RT_PC_S1 (EFI_SUBCLASS_SPECIFIC | 0x00000001)\r | |
897 | #define EFI_SW_DXE_RT_PC_S2 (EFI_SUBCLASS_SPECIFIC | 0x00000002)\r | |
898 | #define EFI_SW_DXE_RT_PC_S3 (EFI_SUBCLASS_SPECIFIC | 0x00000003)\r | |
899 | #define EFI_SW_DXE_RT_PC_S4 (EFI_SUBCLASS_SPECIFIC | 0x00000004)\r | |
900 | #define EFI_SW_DXE_RT_PC_S5 (EFI_SUBCLASS_SPECIFIC | 0x00000005)\r | |
901 | \r | |
902 | #define EFI_SW_CSM_LEGACY_ROM_INIT (EFI_SUBCLASS_SPECIFIC | 0x00000000)\r | |
903 | \r | |
904 | The definitions above are *NOT* defined in Framework StatusCodes specification 0.92. But these subclass-specific error code\r | |
905 | operations are needed for EdkII implementation.\r | |
906 | Keeping this inconsistency for backward compatibility.\r | |
907 | \r | |
908 | 2. Include/Framework/StatusCode.h\r | |
909 | typedef union {\r | |
910 | CHAR8 *Ascii;\r | |
911 | CHAR16 *Unicode;\r | |
912 | ...\r | |
913 | } EFI_STATUS_CODE_STRING;\r | |
914 | \r | |
915 | The definition is *NOT* consistent with Framework SatausCodes specification 0.92, in which the first field is defined as "CHAR8 Ascii[]"\r | |
916 | and the second field is defined as "CHAR16 Unicode[]". Keeping this inconsistency for backward compatibility.\r | |
917 | \r | |
918 | 3. Include/Framework/StatusCode.h\r | |
919 | #define EFI_SW_EC_X64_DIVIDE_ERROR EXCEPT_X64_DIVIDE_ERROR\r | |
920 | #define EFI_SW_EC_X64_DEBUG EXCEPT_X64_DEBUG\r | |
921 | #define EFI_SW_EC_X64_NMI EXCEPT_X64_NMI\r | |
922 | #define EFI_SW_EC_X64_BREAKPOINT EXCEPT_X64_BREAKPOINT\r | |
923 | #define EFI_SW_EC_X64_OVERFLOW EXCEPT_X64_OVERFLOW\r | |
924 | #define EFI_SW_EC_X64_BOUND EXCEPT_X64_BOUND\r | |
925 | #define EFI_SW_EC_X64_INVALID_OPCODE EXCEPT_X64_INVALID_OPCODE\r | |
926 | #define EFI_SW_EC_X64_DOUBLE_FAULT EXCEPT_X64_DOUBLE_FAULT\r | |
927 | #define EFI_SW_EC_X64_INVALID_TSS EXCEPT_X64_INVALID_TSS\r | |
928 | #define EFI_SW_EC_X64_SEG_NOT_PRESENT EXCEPT_X64_SEG_NOT_PRESENT\r | |
929 | #define EFI_SW_EC_X64_STACK_FAULT EXCEPT_X64_STACK_FAULT\r | |
930 | #define EFI_SW_EC_X64_GP_FAULT EXCEPT_X64_GP_FAULT\r | |
931 | #define EFI_SW_EC_X64_PAGE_FAULT EXCEPT_X64_PAGE_FAULT\r | |
932 | #define EFI_SW_EC_X64_FP_ERROR EXCEPT_X64_FP_ERROR\r | |
933 | #define EFI_SW_EC_X64_ALIGNMENT_CHECK EXCEPT_X64_ALIGNMENT_CHECK\r | |
934 | #define EFI_SW_EC_X64_MACHINE_CHECK EXCEPT_X64_MACHINE_CHECK\r | |
935 | #define EFI_SW_EC_X64_SIMD EXCEPT_X64_SIMD\r | |
936 | \r | |
937 | The definitions are *NOT* defined in Framework StatusCodes specification 0.92, in which IA32 and IPF exception subclass error code definitions\r | |
938 | are defined but omit the corresponding definitions for X64. EdkII introduce these definitions for implementation. \r | |
939 | \r | |
940 | ##\r | |
941 | # Mismatch with Intel Platform Innovation Framework for EFI Boot Script Specification (Version 0.91)\r | |
942 | ##\r | |
943 | 1. Include/Protocol/BootScriptSave.h\r | |
944 | #define EFI_BOOT_SCRIPT_SAVE_PROTOCOL_GUID \\r | |
945 | { \\r | |
946 | 0x470e1529, 0xb79e, 0x4e32, {0xa0, 0xfe, 0x6a, 0x15, 0x6d, 0x29, 0xf9, 0xb2 } \\r | |
947 | }\r | |
948 | \r | |
949 | The macro name "EFI_BOOT_SCRIPT_SAVE_PROTOCOL_GUID" is *NOT* consistent with Framework BootScript specification 0.91,\r | |
950 | in which it's defined as "EFI_BOOT_SCRIPT_SAVE_GUID". Keeping this inconsistency for backward compatibility.\r | |
951 | \r | |
952 | 2. Include/Protocol/BootScriptSave.h\r | |
953 | EFI_STATUS\r | |
954 | EFI_BOOTSERVICE\r | |
955 | (EFIAPI *EFI_BOOT_SCRIPT_WRITE) (\r | |
956 | IN EFI_BOOT_SCRIPT_SAVE_PROTOCOL *This,\r | |
957 | ...\r | |
958 | );\r | |
959 | \r | |
960 | The first parameter's type is *NOT* consistent with Framework BootScript specification 0.91, in which it's defined as\r | |
961 | "struct _EFI_BOOT_SCRIPT_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r | |
962 | \r | |
963 | 3. Include/Framework/BootScript.h\r | |
964 | #define EFI_BOOT_SCRIPT_MEM_POLL_OPCODE 0x09\r | |
965 | #define EFI_BOOT_SCRIPT_INFORMATION_OPCODE 0x0A\r | |
966 | #define EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE 0x0B\r | |
967 | #define EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE 0x0C\r | |
968 | #define EFI_BOOT_SCRIPT_DISPATCH_2_OPCODE 0x0D\r | |
969 | \r | |
970 | The OPCODEs above are not defined in Framework BootScript Specification 0.91, but adopted by PI 1.0 Spec. And they\r | |
971 | are needed for EdkII implementation.\r | |
972 | \r | |
973 | 4. Include/Framework/BootScript.h\r | |
974 | #define EFI_BOOT_SCRIPT_TABLE_OPCODE 0xAA\r | |
975 | #define EFI_BOOT_SCRIPT_TERMINATE_OPCODE 0xFF\r | |
976 | \r | |
977 | The two OPCODEs are *NOT* defined in Framework BootScript specification 0.91. EdkII introduces them to indicate the start\r | |
978 | or end of the boot script table.\r | |
979 | Keeping this inconsistency for backward compatibility.\r | |
980 | \r | |
981 | 5. Include/Protocol/BootScriptSave.h\r | |
982 | typedef \r | |
983 | EFI_STATUS \r | |
984 | (EFIAPI *EFI_BOOT_SCRIPT_CLOSE_TABLE) (\r | |
985 | IN EFI_BOOT_SCRIPT_SAVE_PROTOCOL *This,\r | |
986 | ...\r | |
987 | );\r | |
988 | \r | |
989 | The first parameter's type is *NOT* consistent with BootScript specification, in which it's defined as\r | |
990 | "struct _EFI_BOOT_SCRIPT_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r | |
991 | \r | |
992 | 6. Include/Include/BootScriptExecuter.h\r | |
993 | typedef\r | |
994 | EFI_STATUS\r | |
995 | (EFIAPI *EFI_PEI_BOOT_SCRIPT_EXECUTE)(\r | |
996 | IN EFI_PEI_SERVICES **PeiServices,\r | |
997 | IN EFI_PEI_BOOT_SCRIPT_EXECUTER_PPI *This,\r | |
998 | ...\r | |
999 | );\r | |
1000 | \r | |
1001 | The second parameter's type is *NOT* consistent with BootScript specification, in which it's defined as\r | |
1002 | "struct _EFI_PEI_BOOT_SCRIPT_EXECUTER_PPI". Keeping this inconsistency for backward compatibility.\r | |
1003 | \r | |
1004 | ##\r | |
1005 | # Mismatch with Intel Platform Innovation Framework for EFI DXE CIS (Version 0.91)\r | |
1006 | ##\r | |
1007 | 1. Include/Framework/DxeCis.h\r | |
1008 | EFI_STATUS_CODE_ARCH_PROTOCOL is removed.\r | |
1009 | \r | |
1010 | EdkII doesn't provide EFI_STATUS_CODE_ARCH_PROTOCOL definition due to ReportStatusCode() field has been\r | |
1011 | removed from EFI Runtime Service Table of PI specification. EFI_STATUS_CODE_ARCH_PROTOCOL is *NOT* required,\r | |
1012 | and is replaced with EFI_STATUS_CODE_RUNTIME_PROTOCOL.\r | |
1013 | \r | |
1014 | ##\r | |
1015 | # Mismatch with Intel Platform Innovation Framework for EFI Firmware Volume Specification (Version 0.9)\r | |
1016 | ##\r | |
1017 | 1. Include/Framework/FirmwareVolumeImageFormat.h\r | |
1018 | #define EFI_AGGREGATE_AUTH_STATUS_ALL 0x00000f\r | |
1019 | #define EFI_LOCAL_AUTH_STATUS_ALL 0x0f0000\r | |
1020 | \r | |
1021 | The two macros are *NOT* defined in Framework FV specification 0.9. EdkII introduces them as a mask to calculate the\r | |
1022 | value of authentication status.\r | |
1023 | \r | |
1024 | ##\r | |
1025 | # Mismatch with Intel Platform Innovation Framework for EFI Human Interface Infrastructure Specification (Version 0.92)\r | |
1026 | ##\r | |
1027 | 1. Include/Protocol/FrameworkHii.h\r | |
1028 | #define EFI_HII_PROTOCOL_GUID \\r | |
1029 | { \\r | |
1030 | 0xd7ad636e, 0xb997, 0x459b, {0xbf, 0x3f, 0x88, 0x46, 0x89, 0x79, 0x80, 0xe1} \\r | |
1031 | }\r | |
1032 | \r | |
1033 | The Framework HII specification 0.92 changed part of HII interfaces but did not update the protocol GUID.\r | |
1034 | This change should cause a change of GUID in both of code and HII spec. EdkII updates the GUID in code, \r | |
1035 | but the Framework HII specification 0.92 is not updated. This is a known issue.\r | |
1036 | \r | |
1037 | 2. Include/Protocol/FrameworkHii.h\r | |
1038 | typedef struct {\r | |
1039 | ...\r | |
1040 | EFI_HANDLE COBExportHandle;\r | |
1041 | } EFI_HII_HANDLE_PACK;\r | |
1042 | \r | |
1043 | The last field "COBExportHandle" of EFI_HII_HANDLE_PACK is *NOT* defined in the Framework HII specification\r | |
1044 | 0.92. Keeping this inconsistency for backward compatibility.\r | |
1045 | \r | |
1046 | 3. Include/Protocol/FrameworkHii.h\r | |
1047 | typedef struct {\r | |
1048 | UINTN NumberOfPackages;\r | |
1049 | EFI_GUID *GuidId;\r | |
1050 | } EFI_HII_PACKAGES;\r | |
1051 | \r | |
1052 | The definition is *NOT* consistent with Framework HII specification 0.92, in which a field "HandlePack" is defined.\r | |
1053 | EdkII changes the EFI_HII_PACKAGES to contain various number of packages of different types just after the structure\r | |
1054 | as inline data, which will bring the flexibility on development.\r | |
1055 | \r | |
1056 | 4. Include/Protocol/FrameworkHii.h\r | |
1057 | struct _EFI_HII_PROTOCOL {\r | |
1058 | ...\r | |
1059 | EFI_HII_RESET_STRINGS ResetStrings;\r | |
1060 | ...\r | |
1061 | };\r | |
1062 | \r | |
1063 | The field listed above is *NOT* defined in Framework HII specification 0.92. EdkII adds this field to provide \r | |
1064 | an ability of removing any new strings that were added after the initial string export for this handle. \r | |
1065 | \r | |
1066 | 5. Include/Protocol/FrameworkHii.h\r | |
1067 | typedef\r | |
1068 | EFI_STATUS\r | |
1069 | (EFIAPI *EFI_HII_GLYPH_TO_BLT)(\r | |
1070 | ...\r | |
1071 | IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL Foreground,\r | |
1072 | IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL Background,\r | |
1073 | ...\r | |
1074 | IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer\r | |
1075 | );\r | |
1076 | \r | |
1077 | The type of the parameters listed above are *NOT* consistent with Framework HII specification 0.92, in which\r | |
1078 | the type of these parameters is EFI_UGA_PIXEL. Here the definition uses the EFI_GRAPHICS_OUTPUT_BLT_PIXEL which\r | |
1079 | defined in UEFI2.1 spec. Keeping this inconsistency for backward compatibility.\r | |
1080 | \r | |
1081 | 6. Include/Protocol/FrameworkHii.h\r | |
1082 | typedef struct {\r | |
1083 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1084 | UINT8 Flags;\r | |
1085 | } EFI_IFR_SUPPRESS;\r | |
1086 | \r | |
1087 | typedef struct {\r | |
1088 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1089 | UINT8 Flags;\r | |
1090 | } EFI_IFR_GRAY_OUT;\r | |
1091 | \r | |
1092 | typedef struct {\r | |
1093 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1094 | STRING_REF Popup;\r | |
1095 | UINT8 Flags;\r | |
1096 | } EFI_IFR_INCONSISTENT;\r | |
1097 | \r | |
1098 | typedef struct {\r | |
1099 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1100 | UINT16 QuestionId;\r | |
1101 | UINT8 Width;\r | |
1102 | UINT16 Value;\r | |
1103 | } FRAMEWORK_EFI_IFR_EQ_ID_VAL;\r | |
1104 | \r | |
1105 | typedef struct {\r | |
1106 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1107 | UINT16 QuestionId;\r | |
1108 | UINT8 Width;\r | |
1109 | UINT16 ListLength;\r | |
1110 | UINT16 ValueList[1];\r | |
1111 | } FRAMEWORK_EFI_IFR_EQ_ID_LIST;\r | |
1112 | \r | |
1113 | typedef struct {\r | |
1114 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1115 | UINT16 QuestionId1;\r | |
1116 | UINT8 Width;\r | |
1117 | UINT16 QuestionId2;\r | |
1118 | } FRAMEWORK_EFI_IFR_EQ_ID_ID;\r | |
1119 | \r | |
1120 | typedef struct {\r | |
1121 | FRAMEWORK_EFI_IFR_OP_HEADER Header;\r | |
1122 | UINT16 VariableId;\r | |
1123 | UINT16 Value;\r | |
1124 | } EFI_IFR_EQ_VAR_VAL;\r | |
1125 | \r | |
1126 | The defintions are not complied with Framework HII spec 0.92. Keeping the inconsistent for implementation needed.\r | |
1127 | \r | |
1128 | 7. Include/Protocol/FrameworkFormCallback.h\r | |
1129 | #define RESET_REQUIRED 1 \r | |
1130 | #define EXIT_REQUIRED 2\r | |
1131 | #define SAVE_REQUIRED 4\r | |
1132 | #define NV_CHANGED 8\r | |
1133 | #define NV_NOT_CHANGED 16\r | |
1134 | \r | |
1135 | These macros are *NOT* defined in the Framework HII specification 0.92. These Flags are introduced to describe\r | |
1136 | the standard behavior of the browser after the callback.\r | |
1137 | Keeping this inconsistency for backward compatibility.\r | |
1138 | \r | |
1139 | 8. Include/Protocol/FrameworkFormCallback.h\r | |
1140 | typedef\r | |
1141 | EFI_STATUS\r | |
1142 | (EFIAPI *EFI_NV_WRITE)(\r | |
1143 | ...\r | |
1144 | IN UINT32 Attributes,\r | |
1145 | ...\r | |
1146 | );\r | |
1147 | \r | |
1148 | The definition is *NOT* consistent with Framework HII specification 0.92, in which the type of Attributes\r | |
1149 | parameter is defined as "UINT32 *". EdkII changes the type of Attributes from UINT32 * to UINT32 because\r | |
1150 | the input paramter is not necessary to use pointer date type.\r | |
1151 | \r | |
1152 | ##\r | |
1153 | # Mismatch with Intel Platform Innovation Framework for PEI CIS Specification (Version 0.91)\r | |
1154 | ##\r | |
1155 | 1. Include/Ppi/ReadOnlyVariable.h\r | |
1156 | #define EFI_VARIABLE_READ_ONLY 0x00000008\r | |
1157 | \r | |
1158 | In Framework PeiCis specification 0.91, neither the macro or its value is defined.\r | |
1159 | Keeping this inconsistency for backward compatibility.\r | |
1160 | \r | |
1161 | 2. Include/Ppi/FindFv.h\r | |
1162 | typedef\r | |
1163 | EFI_STATUS\r | |
1164 | (EFIAPI *EFI_PEI_FIND_FV_FINDFV)(\r | |
1165 | IN EFI_PEI_FIND_FV_PPI *This,\r | |
1166 | IN EFI_PEI_SERVICES **PeiServices,\r | |
1167 | IN UINT8 *FvNumber,\r | |
1168 | IN OUT EFI_FIRMWARE_VOLUME_HEADER **FVAddress\r | |
1169 | );\r | |
1170 | \r | |
1171 | The definition is *NOT* consistent with Framework PeiCis specification 0.91. Compared with spec, the order\r | |
1172 | of the first and second parameters is reversed. Keeping this inconsistency for backward compatibility.\r | |
1173 | \r | |
1174 | ##\r | |
1175 | # Mismatch with Intel Platform Innovation Framework for EFI SMM CIS (Version 0.91)\r | |
1176 | ##\r | |
1177 | 1. Include/Guid/SmramMemoryReserve.h\r | |
1178 | typedef struct {\r | |
7ae58ec2 | 1179 | UINT32 NumberOfSmmReservedRegions;\r |
b1fe77c9 | 1180 | ...\r |
1181 | } EFI_SMRAM_HOB_DESCRIPTOR_BLOCK;\r | |
1182 | \r | |
7ae58ec2 | 1183 | 1) The name of the definition is *NOT* consistent with Framework SmmCis specification 0.91, in which it's \r |
b1fe77c9 | 1184 | defined as "EFI_HOB_SMRAM_DESCRIPTOR_BLOCK" rather than "EFI_SMRAM_HOB_DESCRIPTOR_BLOCK". \r |
1185 | Keeping this inconsistency for backward compatibility.\r | |
1186 | \r | |
7ae58ec2 | 1187 | 2) The definition of NumberOfSmmReservedRegions is *NOT* consistent with Framework SmmCis specification 0.91,\r |
1188 | in which the type of this field is defined as UINTN. However, HOBs are supposed to be CPU neutral, so UINTN\r | |
1189 | is incorrect and UINT32 should be used.\r | |
1190 | \r | |
b1fe77c9 | 1191 | 2. Include/Guid/SmramMemoryReserve.h\r |
1192 | typedef enum {\r | |
1193 | ...\r | |
1194 | IchnIoTrap3,\r | |
1195 | IchnIoTrap2,\r | |
1196 | IchnIoTrap1,\r | |
1197 | IchnIoTrap0,\r | |
1198 | IchnPciExpress,\r | |
1199 | IchnMonitor,\r | |
1200 | IchnSpi,\r | |
1201 | IchnQRT,\r | |
1202 | IchnGpioUnlock,\r | |
1203 | ...\r | |
1204 | } EFI_SMM_ICHN_SMI_TYPE;\r | |
1205 | \r | |
1206 | The enumeration fields listed above are *NOT* defined in Framework SmmCis specification 0.91. EdkII introduces\r | |
1207 | these fields to support new SMI types.\r | |
1208 | \r | |
23228db3 | 1209 | 3. Include/Framework/SmmCis.h\r |
1210 | typedef union {\r | |
1211 | ///\r | |
1212 | /// The processor save-state information for IA-32 processors. \r | |
1213 | ///\r | |
1214 | EFI_SMI_CPU_SAVE_STATE Ia32SaveState;\r | |
1215 | ///\r | |
1216 | /// Note: Inconsistency with the Framework SMM CIS spec - Itanium save state not included.\r | |
1217 | ///\r | |
1218 | /// The processor save-state information for Itanium processors.\r | |
1219 | ///\r | |
1220 | /// EFI_PMI_SYSTEM_CONTEXT ItaniumSaveState;\r | |
1221 | } EFI_SMM_CPU_SAVE_STATE;\r | |
1222 | \r | |
b1fe77c9 | 1223 | ##\r |
1224 | # Mismatch with Intel Platform Innovation Framework for EFI S3 Resume Boot Path Specification (Version 0.9)\r | |
1225 | ##\r | |
1226 | 1. Include/Protocol/AcpiS3Save.h\r | |
1227 | typedef\r | |
1228 | EFI_STATUS\r | |
1229 | EFI_BOOTSERVICE\r | |
1230 | (EFIAPI *EFI_ACPI_GET_LEGACY_MEMORY_SIZE) (\r | |
1231 | IN EFI_ACPI_S3_SAVE_PROTOCOL *This,\r | |
1232 | OUT UINTN *Size\r | |
1233 | );\r | |
1234 | \r | |
1235 | The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r | |
1236 | "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Keeping this inconsistency for backward compatibility.\r | |
1237 | \r | |
1238 | 2. Include/Protocol/AcpiS3Save.h\r | |
1239 | typedef\r | |
1240 | EFI_STATUS\r | |
1241 | (EFIAPI *EFI_ACPI_S3_SAVE) (\r | |
1242 | IN EFI_ACPI_S3_SAVE_PROTOCOL *This,\r | |
1243 | IN VOID *LegacyMemoryAddress \r | |
1244 | );\r | |
1245 | \r | |
1246 | The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r | |
1247 | "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Also the EFI_BOOTSERVICE modifier is removed from the function declaration.\r | |
1248 | \r | |
1249 | 3. Include/Protocol/AcpiS3Save.h\r | |
1250 | typedef\r | |
1251 | EFI_STATUS\r | |
1252 | (EFIAPI *EFI_ACPI_GET_LEGACY_MEMORY_SIZE)(\r | |
1253 | IN EFI_ACPI_S3_SAVE_PROTOCOL *This,\r | |
1254 | OUT UINTN *Size\r | |
1255 | );\r | |
1256 | \r | |
1257 | The first parameter's type is *NOT* consistent with Framework S3Resume specification, in which it's defined as\r | |
1258 | "struct _EFI_ACPI_S3_SAVE_PROTOCOL". Also the EFI_BOOTSERVICE modifier is removed from the function declaration.\r | |
1259 | \r | |
1260 | ##\r | |
1261 | # Mismatch with Intel Platform Innovation Framework for EFI ACPI Specification (Version 0.91)\r | |
1262 | ##\r | |
1263 | 1. Include/Protocol/AcpiSupport.h\r | |
1264 | typedef\r | |
1265 | EFI_STATUS\r | |
1266 | (EFIAPI *EFI_ACPI_GET_ACPI_TABLE)(\r | |
1267 | ...\r | |
1268 | );\r | |
1269 | \r | |
1270 | The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r | |
1271 | is removed from the function declaration.\r | |
1272 | \r | |
1273 | 2. Include/Protocol/AcpiSupport.h\r | |
1274 | typedef\r | |
1275 | EFI_STATUS\r | |
1276 | (EFIAPI *EFI_ACPI_SET_ACPI_TABLE)(\r | |
1277 | ...\r | |
1278 | );\r | |
1279 | \r | |
1280 | The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r | |
1281 | is removed from the function declaration.\r | |
1282 | \r | |
1283 | 3. Include/Protocol/AcpiSupport.h\r | |
1284 | typedef\r | |
1285 | EFI_STATUS\r | |
1286 | (EFIAPI *EFI_ACPI_PUBLISH_TABLES)(\r | |
1287 | ...\r | |
1288 | );\r | |
1289 | \r | |
1290 | The function modifier is *NOT* consistent with Framework Acpi specification. The EFI_BOOTSERVICE modifier\r | |
1291 | is removed from the function declaration.\r |