英雄帖: Support for SMBIOS Type 44 LoongArch supplement tables

[xen0n]

Right now there are SMBIOS Type 44 tables on LoongArch systems, that cannot be decoded with current versions of dmidecode and other known tools:

$ sudo dmidecode -t 44
# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.

Handle 0x0015, DMI type 44, 48 bytes
Unknown Type
	Header and Data:
		2C 30 15 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 41 36 30
		30 30 2D 48 56 00 00 00 00 00 00 00 C7 CC 7C 7E
	Strings:
		ptal....X

(repeated 7 more times with increasing handle indexes)

This is actually well-defined in the LoongArch SMBIOS supplement spec (rendered), and worth supporting.

Places to look at:

• dmidecode
• smbios-lib

It could be helpful if anyone communicate here first before stepping up and writing code.

[jiegec]

✋ 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:

• Type: 0x2C=44, correct
• Length: 0x30=48, correct
• Handle: 0x0012, correct
• Reference Handle: 0x0001, correct
• Block Length: 0x28=40, correct
• Processor Type: 0x0A, LoongArch64, correct
• Revision: 0x0100, v1.00, correct
• Block Length: 0x28=40, correct
• Machine Vendor ID: 4C 6F 6F 6E 67 73 6F 6E 00 00 00 00 00 00 00 00=Loongson, correct
• CPU ID: 33 43 35 30 30 30 00 00 00 00 00 00 00 00 00 00=3C5000, correct
• ISA extensions support: 0x007CCFC7, bits[3:0] equals 0x7, means FP+LSX+LASX without LBT, wrong. Besides, what are those extra bits?

Update: 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?

[kilaterlee]

The latest version of dmidecode seems to support SMBIOS V3.6 and V3.7: https://savannah.nongnu.org/news/?id=10634

[xen0n]

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.

[xen0n]

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.

[jiegec]

The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see loongson/Firmware#82

[kilaterlee]

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?

[jiegec]

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?

Either way is okay, as long as they match.

[xen0n]

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?

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.)

[kilaterlee]

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?

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?

1. The 32-bit bit fields are tightly packed and each bit has its own meaning. If so, I need to define the meaning of each bit.
2. Same as CPUCFG 0x2, some bits do not need to be decoded.