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

xen0n commented 11 months ago

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:

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

jiegec commented 11 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:

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 commented 3 months ago

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

xen0n commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

The problem is, the firmware does not generate Type 44 entry according to SMBIOS standard, see https://github.com/loongson/Firmware/issues/82

kilaterlee commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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?

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.
Same as CPUCFG 0x2, some bits do not need to be decoded.

loongson-community / discussions

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