coreboot

sudo ./superiotool 
superiotool r4.19-306-g12ec7901b7
Found Aspeed AST2400 (id=0x00) at 0x4e
sudo ./superiotool
superiotool r4.19-306-g12ec7901b7
No Super I/O found

A modification of little significance. To be honest, this Issue system is confusing. I can't edit the text, but my Github Issue allows me to edit the text, which is more efficient to be honest.

shen Liu wrote:

sudo ./superiotool 
Found Aspeed AST2400 (id=0x00) at 0x4e
sudo ./superiotool
superiotool r4.19-306-g12ec7901b7
No Super I/O found

Does superiotool provide debug symbols?
Without debug symbols I can't use gdb to provide more useful information.

Not by default, but it should be pretty easy to compile them in i.e. CFLAGS="-g" make or by editing the CFLAGS variable in the makefile. You may also want to remove the "-O2" flag to avoid GCC reordering code/optimizing out function calls which can make it harder to trace.

Nicholas Chin wrote in #note-2:

shen Liu wrote:

sudo ./superiotool 
Found Aspeed AST2400 (id=0x00) at 0x4e
sudo ./superiotool
superiotool r4.19-306-g12ec7901b7
No Super I/O found

Does superiotool provide debug symbols?
Without debug symbols I can't use gdb to provide more useful information.

Not by default, but it should be pretty easy to compile them in i.e. CFLAGS="-g" make or by editing the CFLAGS variable in the makefile. You may also want to remove the "-O2" flag to avoid GCC reordering code/optimizing out function calls which can make it harder to trace.

Starting program: /home/test/coreboot/util/superiotool/superiotool
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Inferior 1 (process 1254) exited normally]
Exception ignored in: <gdb._GdbOutputFile object at 0x7f8f82fcf340>
Traceback (most recent call last):
File "/usr/share/gdb/python/gdb/__init__.py", line 47, in flush
def flush(self):
KeyboardInterrupt:
Starting program: /home/test/coreboot/util/superiotool/superiotool
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Inferior 1 (process 1385) exited normally]

It doesn't seem to have any useful information.
The obtained chip model is wrong. In fact, the correct chip model is NCT6779D

shen Liu wrote in #note-3:

Starting program: /home/test/coreboot/util/superiotool/superiotool
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Inferior 1 (process 1254) exited normally]
Exception ignored in: <gdb._GdbOutputFile object at 0x7f8f82fcf340>
Traceback (most recent call last):
File "/usr/share/gdb/python/gdb/__init__.py", line 47, in flush
def flush(self):
KeyboardInterrupt:
Starting program: /home/test/coreboot/util/superiotool/superiotool
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Inferior 1 (process 1385) exited normally]

It doesn't seem to have any useful information.

I'm not sure what you were expecting. GDB and debug symbols don't magically cause debug messages to be printed out when you just run it. If you just use run in GDB, it will run the program until it hits a breakpoint or an exception (a runtime error). Debug symbols just tell GDB what line of code corresponds to each instruction in the compiled binary. It doesn't look like you had any breakpoints set and superiotool isn't running into any errors, so it just runs to completion (the [Inferior 1 (process 1385) exited normally] line)

The obtained chip model is wrong. In fact, the correct chip model is NCT6779D

Superiotool isn't guaranteed to correctly detect the correct chip model, and can be limited by how the hardware is set up. Most superios have an ID register, and superiotool tries to read this register over commonly used IO ports such as 0x2e or 0x4e. If the superio is on a non-typical port, it may not be detected. However, the NCT6779D on the H81M-P33 appears to use port 0x4e based on the coreboot source code, and as that board is similar to your board I would assume it would be on the same port.

The AST2400 doesn't have such an ID register so superiotool attempts to read a characteristic value from a specific register to attempt to identify it. From your logs superiotool is detecting something on port 0x4e, which is probably the NCT6779D, but this limitation in the AST2400 detection method is causing a false positive. It's also possible that this method causes the NCT6779D to stop responding, which might explain why nothing is detected on subsequent runs of superiotool. Normally superiotool will print every chip that it detects during a run, but since Nuvoton chips are probed for after Aspeed chips, the initial probe for the AST2400 might be preventing the NCT6779D from being detected afterwards as it stops responding.

The AST2400 has been known to cause false positives and an idea had been proposed before to allow a user to specify a vendor to probe for, so in this case "only probe for nuvoton and nothing else" as it's often easy to determine the vendor from a visual inspection of the board.

As a workaround for now, you could try ignoring aspeed chips by commenting out line 233 in superiotool.h

    227 /** Table of which config ports to probe for each Super I/O family. */
    228 static const struct {
    229         void (*probe_idregs) (uint16_t port);
    230         int ports[MAXNUMPORTS]; /* Signed, as we need EOT. */
    231 } superio_ports_table[] = {
    232         {probe_idregs_ali,      {0x3f0, 0x370, EOT}},
    233         /* ignore aspeed {probe_idregs_aspeed,   {0x2e, 0x4e, EOT}},*/
    234         {probe_idregs_exar,     {0x2e, 0x4e, EOT}},
    235         {probe_idregs_fintek,   {0x2e, 0x4e, EOT}},
    236         {probe_idregs_fintek_alternative,       {0x2e, 0x4e, EOT}},
    237         /* Only use 0x370 for ITE, but 0x3f0 or 0x3bd would also be valid. */
    238         {probe_idregs_ite,      {0x20e, 0x25e, 0x2e, 0x4e, 0x370, 0x6e, EOT}},
    239         {probe_idregs_nsc,      {0x2e, 0x4e, 0x15c, 0x164e, EOT}},
    240         /* I/O pairs on Nuvoton EC chips can be configured by firmware in
    241          * addition to the following hardware strapping options. */
    242         {probe_idregs_nuvoton, {0x164e, 0x2e, 0x4e, EOT}},
    243         {probe_idregs_smsc,     {0x2e, 0x4e, 0x162e, 0x164e, 0x3f0, 0x370, EOT}},
    244         {probe_idregs_winbond,  {0x2e, 0x4e, 0x3f0, 0x370, 0x250, EOT}},
    245 #ifdef PCI_SUPPORT
    246         {probe_idregs_via,      {0x2e, 0x4e, 0x3f0, EOT}},
    247         /* in fact read the BASE from HW */
    248         {probe_idregs_amd,      {0xaa, EOT}},
    249 #endif
    250         {probe_idregs_serverengines,    {0x2e, EOT}},
    251         {probe_idregs_infineon, {0x2e, 0x4e, EOT}},
    252 };

You might need to power cycle the system to get the NCT6779D to respond again if the aspeed detection is indeed causing it to stop responding

Have you tried running sudo superiotool -d? This should show the register dump for the Nuvoton Super I/O on your board. The AST2400 detection procedure is delusional (read random registers, if any returns non-zero then we have an AST2400), so it often results in false positives.

Nicholas Chin wrote in #note-4:

As a workaround for now, you could try ignoring aspeed chips by commenting out line 233 in superiotool.h

I did this, but the result was that superio was not detected.

Angel Pons wrote in #note-5:

Have you tried running sudo superiotool -d? This should show the register dump for the Nuvoton Super I/O on your board. The AST2400 detection procedure is delusional (read random registers, if any returns non-zero then we have an AST2400), so it often results in false positives.

superiotool r4.19-306-g12ec7901b7
Found Aspeed AST2400 (id=0x00) at 0x4e
Register dump:
idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
val ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
def 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
LDN 0x02 (SUART1)
idx 30 60 61 70 71 f0
val ff ff ff ff ff ff
def 00 03 f8 04 02 RR
LDN 0x03 (SUART2)
idx 30 60 61 70 71 f0
val ff ff ff ff ff ff
def 00 02 f8 03 02 00
LDN 0x04 (SWC)
idx 30 60 61 62 63 64 65 66 67 70 71
val ff ff ff ff ff ff ff ff ff ff ff
def 00 08 e6 08 e0 08 e4 08 e8 09 01
LDN 0x05 (Keyboard config (KBC))
idx 30 60 61 62 63 70 71 72 73 f0
val ff ff ff ff ff ff ff ff ff ff
def 00 00 60 00 64 01 02 0c 02 83
LDN 0x07 (GPIO)
idx 30 38 70 71
val ff ff ff ff
def 00 00 0b 01
LDN 0x0b (SUART3)
idx 30 60 61 70 71 f0
val ff ff ff ff ff ff
def 00 03 e8 06 02 00
LDN 0x0c (SUART4)
idx 30 60 61 70 71 f0
val ff ff ff ff ff ff
def 00 02 e8 05 02 00
LDN 0x0d (iLPC2AHB)
idx 30 70 71 f0 f1 f2 f3 f4 f5 f6 f7 f8 fe
val ff ff ff ff ff ff ff ff ff ff ff ff ff
def 00 09 01 NA NA NA NA NA NA NA NA 00 00
LDN 0x0e (Mailbox)
idx 30 60 61 70 71
val ff ff ff ff ff
def 00 08 c0 09 01