Issue #455 has been updated by Nicholas Chin.
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 }; ```
---------------------------------------- Bug #455: superiotool recognizes the wrong chip and doesn't work. https://ticket.coreboot.org/issues/455#change-1398
* Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: master * Start date: 2023-02-07 * Affected versions: master * Needs backport to: none * Related links: More discussion： https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_support...
https://wiki.archlinux.org/title/Debuginfod * Affected hardware: MSI B85M-E45 * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1) ---------------------------------------- ``` shell 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.