]>
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 | |
33d9d834 | 661 | UINT8 ComponentType;\r |
b1fe77c9 | 662 | } EFI_MISC_MANAGEMENT_DEVICE_COMPONENT_DESCRIPTION_DATA;\r |
663 | \r | |
33d9d834 SZ |
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 | |
b1fe77c9 | 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 | |
33d9d834 SZ |
686 | EfiSlotTypePciExpress = 0xA5,\r |
687 | EfiSlotTypePciExpressX1 = 0xA6,\r | |
688 | EfiSlotTypePciExpressX2 = 0xA7,\r | |
689 | EfiSlotTypePciExpressX4 = 0xA8,\r | |
690 | EfiSlotTypePciExpressX8 = 0xA9,\r | |
691 | EfiSlotTypePciExpressX16 = 0xAA\r | |
b1fe77c9 | 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 | |
33d9d834 SZ |
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 | |
b1fe77c9 | 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 | |
4eb56285 | 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 | |
33d9d834 SZ |
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 | |
b1fe77c9 | 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 | |
7ae58ec2 | 1230 | UINT32 NumberOfSmmReservedRegions;\r |
b1fe77c9 | 1231 | ...\r |
1232 | } EFI_SMRAM_HOB_DESCRIPTOR_BLOCK;\r | |
1233 | \r | |
7ae58ec2 | 1234 | 1) The name of the definition is *NOT* consistent with Framework SmmCis specification 0.91, in which it's \r |
b1fe77c9 | 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 | |
7ae58ec2 | 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 | |
b1fe77c9 | 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 | |
23228db3 | 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 | |
b1fe77c9 | 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 |