Open xen0n opened 10 months ago
✋ I will work on dmidecode. WIP version: https://github.com/jiegec/dmidecode.
I found a issue decoding ISA extensions support
field: the actual SMBIOS info seems wrong.
Raw info from 3C5000:
Handle 0x0012, DMI type 44, 48 bytes
Unknown Type
Header and Data:
2C 30 12 00 01 00 28 0A 00 01 28 00 4C 6F 6F 6E
67 73 6F 6E 00 00 00 00 00 00 00 00 33 43 35 30
30 30 00 00 00 00 00 00 00 00 00 00 C7 CF 7C 00
Strings:
ptal....X
Fields:
4C 6F 6F 6E 67 73 6F 6E 00 00 00 00 00 00 00 00
=Loongson, correct33 43 35 30 30 30 00 00 00 00 00 00 00 00 00 00
=3C5000, correctUpdate: 0x007CCFC7 equals to CPUCFG[1], but does not equal to EUEN according to the spec.
Currently decoded info:
Handle 0x0012, DMI type 44, 48 bytes
Processor Additional Information
Referenced Handle: 0x0001
Processor Type: 64-bit LoongArch (LoongArch64)
Machine Vendor ID: Loongson
CPU ID: 3C5000
ISA Extensions Support:
Floating Point Instructions
128-bit Vector Instructions
256-bit Vector Instructions
RFC: how to name these ISA extensions?
The latest version of dmidecode seems to support SMBIOS V3.6 and V3.7: https://savannah.nongnu.org/news/?id=10634
The latest version of dmidecode seems to support SMBIOS V3.6 and V3.7: https://savannah.nongnu.org/news/?id=10634
Thanks for the triage. It contained CPUID handling but apparently not Type 44 table support yet, so this issue is still TODO.
For the record, the decoding of Type 4 (Processor Information) table by dmidecode
3.6 is like this, on my XC-LS3A6M:
Handle 0x0007, DMI type 4, 50 bytes
Processor Information
Socket Designation: CPU0
Type: Central Processor
Family: Loongson 3A
Manufacturer: Loongson
ID: 33 41 36 30 30 30 2D 48
Signature: Processor Identity 0x30364133
Version: Loongson-3A6000-HV
Voltage: 1.2 V
External Clock: 25 MHz
Max Speed: 2500 MHz
Current Speed: 2500 MHz
Status: Populated, Enabled
Upgrade: Socket BGA2422
L1 Cache Handle: 0x0004
L2 Cache Handle: 0x0005
L3 Cache Handle: 0x0006
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Core Count: 8
Core Enabled: 8
Thread Count: 8
Characteristics:
64-bit capable
Multi-Core
Hardware Thread
The "Processor Identity" part is truncated to 4 bytes, which may or may not be a bug (I have already forgotten the details). The rest looks okay to me.
The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see https://github.com/loongson/Firmware/issues/82
The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see loongson/Firmware#82
Ha, I understand now.
When I designed the spec, CSR 0x2
should be used to fill this field, but in the BIOS implementation it used CPUCFG 0x2
...
Anyway, SPEC and implementation doesn't match now, and I thintk using the CPUCFG 0x2
also not bad, what do you think?
The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see loongson/Firmware#82
Ha, I understand now. When I designed the spec,
CSR 0x2
should be used to fill this field, but in the BIOS implementation it usedCPUCFG 0x2
... Anyway, SPEC and implementation doesn't match now, and I thintk using theCPUCFG 0x2
also not bad, what do you think?
Either way is okay, as long as they match.
The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see loongson/Firmware#82
Ha, I understand now. When I designed the spec,
CSR 0x2
should be used to fill this field, but in the BIOS implementation it usedCPUCFG 0x2
... Anyway, SPEC and implementation doesn't match now, and I thintk using theCPUCFG 0x2
also not bad, what do you think?
From a cost's perspective, the approach to take likely depends on "which is cheaper / takes less time, amending the spec or fixing the firmware implementation for future models". (Current versions of firmware may or may not get fixed, depending on users and/or difficulty arranging with vendors / codebases.)
The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see loongson/Firmware#82
Ha, I understand now. When I designed the spec,
CSR 0x2
should be used to fill this field, but in the BIOS implementation it usedCPUCFG 0x2
... Anyway, SPEC and implementation doesn't match now, and I thintk using theCPUCFG 0x2
also not bad, what do you think?From a cost's perspective, the approach to take likely depends on "which is cheaper / takes less time, amending the spec or fixing the firmware implementation for future models". (Current versions of firmware may or may not get fixed, depending on users and/or difficulty arranging with vendors / codebases.)
If I adjust the SPEC, what kind bit-field do you like?
CPUCFG 0x2
, some bits do not need to be decoded.
Right now there are SMBIOS Type 44 tables on LoongArch systems, that cannot be decoded with current versions of
dmidecode
and other known tools:This is actually well-defined in the LoongArch SMBIOS supplement spec (rendered), and worth supporting.
Places to look at:
It could be helpful if anyone communicate here first before stepping up and writing code.