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_supported_by_coreboot/
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.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
https://ticket.coreboot.org/my/account
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
