Bug 245654
| Summary: | ig4(4): Intel Bay Trail I2C not recognized | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | xspbe3ho3p5uac | ||||||||||||||||||
| Component: | kern | Assignee: | Vladimir Kondratyev <wulf> | ||||||||||||||||||
| Status: | Closed FIXED | ||||||||||||||||||||
| Severity: | Affects Some People | CC: | sam3423.yntmr, wulf | ||||||||||||||||||
| Priority: | --- | Keywords: | needs-qa, patch | ||||||||||||||||||
| Version: | 12.1-RELEASE | Flags: | koobs:
maintainer-feedback?
(wulf) koobs: mfc-stable12? |
||||||||||||||||||
| Hardware: | amd64 | ||||||||||||||||||||
| OS: | Any | ||||||||||||||||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240485 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275115 |
||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
Thank you for the report. Could you provide full versions of /var/run/dmesg.boot and pciconf -lv as attachments please Created attachment 213440 [details]
pciconf -lv; dmesg.boot
Created attachment 213457 [details]
BayTrail_PCI_IDs.patch
Please:
1. Upgrade sources to latest STABLE
2. Apply attached patch
3. Rebuild and reinstall kernel
than post here output of:
1. dmesg after verbose boot (with -v option)
2. pciconf -lv
3. devinfo -rv
Created attachment 213474 [details]
BayTrail_PCI_IDs.patch
Missing 4-th port added.
Created attachment 213514 [details]
dmesg; pciconf -lv; devinfo -rv
(In reply to xspbe3ho3p5uac from comment #5) It is appeared that 2 I2C devices are connected to device that was missed in first version of BayTrail_PCI_IDs.patch. :-( Please, apply 2-nd version and rebuild your kernel. After that, you can try to scan both your I2C buses that have I2C children in ACPI DST table with following commands: i2c -s -f /dev/iic3 i2c -s -f /dev/iic5 I do not know what to do except to scan as we do not have drivers for ATML2000 and CLK devices in our OS I actually had applied the latest patch, though I do see that for some reason ID 0f438086 is not recognized by the driver. The ID that was mistakenly left out in the first patch, 0f448086, seems to be working, as you can see in my latest `pciconf -lv`. I also have a feeling I may have been chasing my own tail on this one. Funnily enough, this machine doesn't actually seem to have any devices attached on the I2C bus. I thought the indicator LEDs were accessed through I2C, but now I'm almost certain they work through GPIO (however, I cannot get any of the pins to change state, even with bytgpio(4), but that is another issue). (In reply to xspbe3ho3p5uac from comment #7) > this machine doesn't actually seem to have any devices attached on the I2C bus. This machine have at least 3 I2C devices defined in DSDT table. You can find them with searching of "devinfo -rv" output for 'handle=\_SB_.I2C' string. I doubt that they can be used for something good, but it would be nice to read at least 1 byte from any of them. BayTrail is known for sharing I2C lines with power management unit so I would like to know if I2C works at all without dedicated support for this unit. Could you post output of "sudo acpidump -dt" command here too. It looks like one of I2C devices were not recognized properly by ACPI subsystem. Created attachment 213553 [details]
ls /dev/iic*; i2c -s; acpidump -dt
(In reply to xspbe3ho3p5uac from comment #9) There are only 6 /dev/iic* rather than 7. One device is still not configured. It looks like your ACPI BIOS has so called I2C OpRegion handler. I ported support for it from DragonFlyBSD recently but it is disabled by default as non tested. It is used by ACPI BIOS to communicate with peripheral devices e.g. battery charge controllers over I2C bus. It can be enabled with placing following line to /boot/loader.conf: hw.iicbus.enable_acpi_space_handler=1 You should reboot after that. I do not know how to test it though. Maybe verbose boot will reveal some debugging messages. Created attachment 213622 [details]
dmesg
Here is the dmesg after I enabled `hw.iicbus.enable_acpi_space_handler`. Let me know if you have any ideas on how to get that last device to show up.
Also, I noticed a couple lines in the latest dmesg. Am I doing something wrong here? I've removed all the *_load lines from /boot/loader.conf.
```
interface ig4iic.1 already present in the KLD 'kernel'!
linker_load_file: /boot/kernel/ig4.ko - unsupported file type
```
Sorry if this is a stupid question, I'm not very familiar with FreeBSD yet.
(In reply to xspbe3ho3p5uac from comment #11) > Here is the dmesg after I enabled `hw.iicbus.enable_acpi_space_handler`. > Let me know if you have any ideas on how to get that last device to show up. Unfortunately, nothing interesting. Except the 3-rd controller is dysfunctional. Full power off/on cycle may be required to restore it. I hope, all 7 /dev/iic* will appear after that. > interface ig4iic.1 already present in the KLD 'kernel'! > linker_load_file: /boot/kernel/ig4.ko - unsupported file type Looks like you have ig4 compiled in to kernel and something ?devmatch? tries to load it one more time as a module. Most probably, it is harmless in the case if you have `device ig4` line in your kernel config. (In reply to Vladimir Kondratyev from comment #12) Sadly, a full shutdown, unplug, and boot does not cause the missing /dev/iic to appear. A commit references this bug: Author: wulf Date: Sun Apr 26 20:16:19 UTC 2020 New revision: 360355 URL: https://svnweb.freebsd.org/changeset/base/360355 Log: ig4(4): Add PCI IDs for Intel Bay Trail I2C controllers. PR: 245654 Reported by: <xspbe3ho3p5uac@protonmail.com> MFC after: 1 week Changes: head/sys/dev/ichiic/ig4_pci.c A commit references this bug: Author: wulf Date: Sun May 3 23:40:16 UTC 2020 New revision: 360618 URL: https://svnweb.freebsd.org/changeset/base/360618 Log: MFC r360355: ig4(4): Add PCI IDs for Intel Bay Trail I2C controllers. PR: 245654 Reported by: <xspbe3ho3p5uac@protonmail.com> Changes: _U stable/12/ stable/12/sys/dev/ichiic/ig4_pci.c Created attachment 246487 [details]
dmesg output
(In reply to Sam from comment #16) Sorry I posted comment#16 in the wrong thread. |
Created attachment 213438 [details] pciconf -l; dmesg Hi, I believe the I2C bus in my ASUSTOR AS5002T (Bay Trail CPU) is not being recognized properly: ~ $ ls /dev|grep iic ~ $ According to the ig4(4) HARDWARE section, Bay Trail devices should be supported. I tried adding all of the PCI IDs (80860f41-0f47) to sys/dev/ichiic/ig4_pci.c and recompiling, which caused `iic` devices to show up in /dev, but they did not seem to be functioning properly via i2c(8) and I'm worried I could mess up my hardware if I try any more (I am NOT a developer). I can provide any data you need, please let me know how I can help. Thank you!