ProcessorPackageNumberRecordType = 21,\r
ProcessorCoreFrequencyListRecordType = 22,\r
ProcessorFsbFrequencyListRecordType = 23,\r
- ProcessorHealthStatusRecordType = 24\r
+ ProcessorHealthStatusRecordType = 24,\r
+ ProcessorCoreCountRecordType = 25,\r
+ ProcessorEnabledCoreCountRecordType = 26,\r
+ ProcessorThreadCountRecordType = 27,\r
+ ProcessorCharacteristicsRecordType = 28,\r
+ ProcessorFamily2RecordType = 29,\r
+ ProcessorPartNumberRecordType = 30,\r
} EFI_CPU_VARIABLE_RECORD_TYPE;\r
\r
- The data structure and all enumeration fields are *NOT* defined in ProcSubclass specification 0.9, which only\r
- defines the following macros to specify the record number of the data record:\r
+ The enumeration fields from ProcessorCoreFrequencyRecordType to ProcessorHealthStatusRecordType are *NOT* defined \r
+ in ProcSubclass specification 0.9, which only defines the following macros to specify the record number of the data record:\r
#define EFI_PROCESSOR_FREQUENCY_RECORD_NUMBER 0x00000001\r
#define EFI_PROCESSOR_BUS_FREQUENCY_RECORD_NUMBER 0x00000002\r
#define EFI_PROCESSOR_VERSION_RECORD_NUMBER 0x00000003\r
#define EFI_PROCESSOR_HEALTH_STATUS_RECORD_NUMBER 0x00000018\r
Keeping this inconsistency for backward compatibility.\r
\r
+ The enumeration fields from ProcessorCoreCountRecordType to ProcessorPartNumberRecordType are *NOT* defined \r
+ in ProcSubclass specification 0.9. \r
+ They are introduced to support new fields for type 4 defined in SmBios 2.6 specification.\r
+ Keeping this inconsistency to reflect the latest industry standard.\r
+\r
8. Guid/DataHubRecords.h\r
typedef union {\r
EFI_PROCESSOR_CORE_FREQUENCY_LIST_DATA ProcessorCoreFrequencyList;\r
...\r
- EFI_PROCESSOR_PACKAGE_NUMBER_DATA ProcessorPackageNumber;\r
+ EFI_PROCESSOR_FAMILY2_DATA ProcessorFamily2;\r
} EFI_CPU_VARIABLE_RECORD;\r
\r
typedef struct {\r
code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r
Keeping this inconsistency for backward compatibility.\r
\r
+ 9. Guid/DataHubRecords.h\r
+ typedef STRING_REF EFI_PROCESSOR_PART_NUMBER_DATA;\r
+\r
+ typedef enum {\r
+ EfiProcessorFamilySh3 = 0x104,\r
+ EfiProcessorFamilySh4 = 0x105,\r
+ EfiProcessorFamilyArm = 0x118,\r
+ EfiProcessorFamilyStrongArm = 0x119,\r
+ EfiProcessorFamily6x86 = 0x12C,\r
+ EfiProcessorFamilyMediaGx = 0x12D,\r
+ EfiProcessorFamilyMii = 0x12E,\r
+ EfiProcessorFamilyWinChip = 0x140,\r
+ EfiProcessorFamilyDsp = 0x15E,\r
+ EfiProcessorFamilyVideo = 0x1F4\r
+ } EFI_PROCESSOR_FAMILY2_DATA;\r
+\r
+ typedef UINT8 EFI_PROCESSOR_CORE_COUNT_DATA;\r
+\r
+ typedef UINT8 EFI_PROCESSOR_ENABLED_CORE_COUNT_DATA;\r
+\r
+ typedef UINT8 EFI_PROCESSOR_THREAD_COUNT_DATA;\r
+\r
+ typedef struct {\r
+ UINT16 Reserved :1;\r
+ UINT16 Unknown :1;\r
+ UINT16 Capable64Bit :1;\r
+ UINT16 Reserved2 :13;\r
+ } EFI_PROCESSOR_CHARACTERISTICS_DATA;\r
+\r
+ The fields listed here are *NOT* defined in ProcSubclass specification 0.9. They are introduced to support\r
+ new fields for type 4 defined in SmBios 2.6 specification. \r
+ Keeping this inconsistency to reflect the latest industry standard.\r
+\r
##\r
# Mismatch with Intel Platform Innovation Framework for MemSubclass Specification (Version 0.90)\r
##\r
code logic. Therefore developer doesn't need to allocate memory dynamically to construct variable length data record.\r
Keeping this inconsistency for backward compatibility.\r
\r
+ 21. Guid/DataHubRecords.h\r
+ typedef struct {\r
+ EFI_MISC_COOLING_DEVICE_TYPE CoolingDeviceType;\r
+ EFI_INTER_LINK_DATA CoolingDeviceTemperatureLink;\r
+ UINT8 CoolingDeviceUnitGroup;\r
+ UINT16 CoolingDeviceNominalSpeed;\r
+ UINT32 CoolingDeviceOemDefined;\r
+ } EFI_MISC_COOLING_DEVICE_TEMP_LINK_DATA;\r
+\r
+ The "CoolingDeviceUnitGroup" field and "CoolingDeviceNominalSpeed" field are *NOT* consistent with \r
+ MiscSubclass specification 0.9. These fields are aligned with SMBIOS 2.6 specification. And user can easily\r
+ assign any value to CoolingDeviceNominalSpeed.\r
+\r
##\r
# Mismatch with Intel Platform Innovation Framework for Status Codes Specification (Version 0.92)\r
##\r
##\r
1. Include/Guid/SmramMemoryReserve.h\r
typedef struct {\r
+ UINT32 NumberOfSmmReservedRegions;\r
...\r
} EFI_SMRAM_HOB_DESCRIPTOR_BLOCK;\r
\r
- The name of the definition is *NOT* consistent with Framework SmmCis specification 0.91, in which it's \r
+ 1) The name of the definition is *NOT* consistent with Framework SmmCis specification 0.91, in which it's \r
defined as "EFI_HOB_SMRAM_DESCRIPTOR_BLOCK" rather than "EFI_SMRAM_HOB_DESCRIPTOR_BLOCK". \r
Keeping this inconsistency for backward compatibility.\r
\r
+ 2) The definition of NumberOfSmmReservedRegions is *NOT* consistent with Framework SmmCis specification 0.91,\r
+ in which the type of this field is defined as UINTN. However, HOBs are supposed to be CPU neutral, so UINTN\r
+ is incorrect and UINT32 should be used.\r
+\r
2. Include/Guid/SmramMemoryReserve.h\r
typedef enum {\r
...\r
The enumeration fields listed above are *NOT* defined in Framework SmmCis specification 0.91. EdkII introduces\r
these fields to support new SMI types.\r
\r
+ 3. Include/Framework/SmmCis.h\r
+ typedef union {\r
+ ///\r
+ /// The processor save-state information for IA-32 processors. \r
+ ///\r
+ EFI_SMI_CPU_SAVE_STATE Ia32SaveState;\r
+ ///\r
+ /// Note: Inconsistency with the Framework SMM CIS spec - Itanium save state not included.\r
+ ///\r
+ /// The processor save-state information for Itanium processors.\r
+ ///\r
+ /// EFI_PMI_SYSTEM_CONTEXT ItaniumSaveState;\r
+ } EFI_SMM_CPU_SAVE_STATE;\r
+\r
##\r
# Mismatch with Intel Platform Innovation Framework for EFI S3 Resume Boot Path Specification (Version 0.9)\r
##\r
projects / mirror_edk2.git / blobdiff