I have been contacted by email last week by a Linux user, probably noticing my recent patch for the gpio_it87 driver in the kernel. They have been hoping my driver could extend to IT7236 chips that are used in a number of gaming motherboards for controlling RGB LEDs.
Having left the case modding world after my first and only ThermalTake chassis – my mother gave me hell for the fans noise, mostly due to the plexiglass window on the side of the case – I still don’t have any context whatsoever on what the current state of these boards is, whether someone has written generic tools to set the LEDs, or even UIs for them. But it was an interesting back and forth of looking for leads into figuring out what is needed.
The first problem is, like most of you who already know a bit about electrical engineering and electronics, that clearly the IT7236 chip is clearly not the same series as the IT87xx chips that my driver supports. And since they are not the same series, they are unlikely to share the same functionality.
The IT87xx series chips are Super I/O controllers, which mean they implement functionality such as floppy-disk controllers, serial and parallel ports and similar interfaces, generally via the LPC bus. You usually know these chip names because these need to be supported by the kernel for them to show up in sensors output. In addition to these standard devices, many controllers include at least a set of general purpose I/O (GPIO) lines. On most consumer motherboards these are not exposed in any way, but boards designed for industrial applications, or customized boards tend to expose those lines easily.
Indeed, I wrote the gpio_it87 driver (well, actually adapted and extended it from a previous driver), because the board I was working on in Los Angeles had one of those chips, and we were interested in having access to the GPIO lines to drive some extra LEDs (and possibly in future versions more external interfaces, although I don’t know if anything was made of those). At the time, I did not manage to get the driver merged; a couple of years back, LaCie manufactured a NAS using a compatible chip, and two of their engineers got my original driver (further extended) merged into the Linux kernel. Since then I only submitted one other patch to add another ID for a compatible chip, because someone managed to send me a datasheet, and I could match it to the one I originally used to implement the driver as having the same behaviour.
Back to the original topic, the IT7236 chip is clearly not a Super I/O controller. It’s also not an Environmental Control (EC) chip, as I know that series is actually IT85xx, which is what my old laptop had. Somewhat luckily though, a “Preliminary Specifications” datasheet for that exact chip is available online from a company that appears to distribute electronics component in the general sense. I’m not sure if that was intentional or not, but having the datasheet is always handy of course.
According to these specifications, the IT7236xFN chips are “Touch ASIC Cap Button Controllers”. And indeed, ITE lists them as such. Comparing this with a different model in the same series shows that probably LED driving was not their original target, but they came to be useful for that. These chips also include an MCU based on a 8051 core, similarly to their EC solution — this makes them, and in particular the datasheet I found earlier, a bit more interesting to me. Unfortunately the datasheet is clearly amended to be the shorter version, and does not include a programming interface description.
Up to this point this tells us exactly one thing only: my driver is completely useless for this chip, as it implements specifically the Super I/O bus access, and it’s unlikely to be extensible to this series of chips. So a new driver is needed and some reverse engineering is likely to be required. The user who wrote me also gave me two other ITE chip names found on the board they have: IT87920 and IT8686 (which appears to be a PWN fan controller — I couldn’t find it on the ITE website at all). Since the it87 (hwmon) driver is still developed out-of-kernel on GitHub, I checked and found an issue that appears to describe a common situation for gaming motherboards: the fans are not controlled with the usual Super I/O chip, but with a separate (more accurate?) one, and that suggests that the LEDs are indeed controlled by another separate chip, which makes sense. The user ran strings on the UEFI/BIOS image and did indeed find modules named after IT8790 and IT7236 (and IT8728 for whatever reason), to confirm this.
None of this brings us any closer to supporting it though, so let’s take a loop at the datasheet, and we can see that the device has an I²C bus, instead of the LPC (or ISA) bus used by Super I/O and the fan controller. Which meant looking at i2cdev and lsi2c. Unfortunately the output can only see that there are things connected to the bus, but not what they are.
This leaves us pretty much dry. Particularly me since I don’t have hardware access. So my suggestion has been to consider looking into the Windows driver and software (that I’m sure the motherboard manufacturer provides), and possibly figure out if they can run in a virtualized environment (qemu?) where I²C traffic can be inspected. But there may be simpler, more useful or more advanced tools to do most of this already, since I have not spent any time on this particular topic before. So if you know of any of them, feel free to leave a comment on the blog, and I’ll make sure to forward them to the concerned user (since I have not asked them if I can publish their name I’m not going to out them — they can, if they want, leave a comment with their name to be reached directly!).
The other option is to identify the chip in question with its power rail, SDA and SCL pins and tack a logic analyser onto there. If the chip is a SOIC, this shouldn’t be too hard, if it’s something smaller, good luck!Sometimes you can read the registers of an I²C chip, but you’re at the mercy of ITE knowing if they’ve included a model number register somewhere. Some manufacturers do this, e.g. CET with their Modbus energy meters, include a string of holding registers that give the model number in UTF16.I think my desktop at work has RGB LED control. The motherboard is an MSI B350 PC Mate… but honestly, it’s literally the last thing I cared about as it was going into an old windowless case (that still proudly announces “Pentium 4 inside”). The board was bought because it had a RS-232 port, parallel port and a couple of PCI slots, along with newer peripherals (USB3) and recent CPU support. I’ve never booted Windows on it, so no idea whether the tools support RGB lighting control.I have plans to break out the RS-232 header and parallel port to give me easy access, and to convert the RS-232 to RS-485/422 (and take out the now dead LS-120 floppy drive that I managed to bugger up with a cleaning disk), but I doubt I’ll get time to muck around with RGB lighting.
Yeah if I had access to it myself I would probably stick the Logic Pro on it and figure it out that way, but having no hardware access, virtualisation sounded like a good second option.As for ITE, they are usually not horrible. Their Super I/O controllers advertise themselves with the right command over LPC and that’s what I’ve used for the gpio driver.
Yeah… actually reading the datasheet … there are two DACs and a number of GPIOs. So they could be using a GPIO as a “chip select” for the particular LED channel then using the DAC to control the voltage out. They also mention PWM control on some pins.I used a similar approach here: https://hackaday.io/project… There, I use a 74HC574 latch to “select” one of the LED channels then drive the ‘574s “output enable” pin with PWM. That lets me drive 8 LEDs from one PWM channel at ⅛ brightness.The fact though that they advertise a 8051 core with flash, that to me sounds like the I²C interface could be decided by whomever is designing the motherboard using it. So these GPIOs, PWMs and DACs are just exposed on the internal bus within the IT7236 and the firmware exposes that over I²C using whatever protocol the firmware developer decides on.The packages are all QFNs, the website mentions a TSSOP option (not much better for this purpose) but that isn’t mentioned in the datasheet… and I know first hand how much of a right pain those are to hold a CRO probe on a QFN32, after a skirmish with a TI TLV320AIC3204 audio CODEC chip years ago. So my earlier suggestion of tacking wires on, yeah… wishful thinking on my part. 🙂
Different chip, but maybe useful anyway: https://kazlauskas.me/entri… https://github.com/nagisa/m…
chip of asus and msi gaming motherboard are quite good so, that your product will having long lasting.MSI gaming motherboards price in India