PINE64
Touchpad, Keyboard, I2C oh my. - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: Pinebook Pro Hardware and Accessories (https://forum.pine64.org/forumdisplay.php?fid=116)
+--- Thread: Touchpad, Keyboard, I2C oh my. (/showthread.php?tid=8794)

Pages: 1 2

RE: Touchpad, Keyboard, I2C oh my. - C_Elegans - 01-16-2020

I did press the kill switches, but I didn't disable the wifi, only the microphone and camera. On the wiki it says that the wifi requires a reboot for the kill switch to take effect, perhaps that's the one that triggers the eeprom traffic at bootup. Did you kill the wifi at some point?

Also, from looking at the traffic and the schematic, it looks like there's an extra interrupt line in addition to the i2c bus that I didn't capture. The master only reads from the touchpad when there's some activity, so there must be some sort of out of band signaling taking place.

RE: Touchpad, Keyboard, I2C oh my. - resistanceisfutile - 01-16-2020

(01-16-2020, 12:01 PM)C_Elegans Wrote: I did press the kill switches, but I didn't disable the wifi, only the microphone and camera. On the wiki it says that the wifi requires a reboot for the kill switch to take effect, perhaps that's the one that triggers the eeprom traffic at bootup. Did you kill the wifi at some point?

Also, from looking at the traffic and the schematic, it looks like there's an extra interrupt line in addition to the i2c bus that I didn't capture. The master only reads from the touchpad when there's some activity, so there must be some sort of out of band signaling taking place.

Yes I did disable the wifi. I tried all of the kill switches while I was sniffing with a bus pirate.

Regarding the out of band signaling - you guessed correctly. The extra interrupt line is the touchpad IC (HLK H2168) to signal the keyboard IC (SH68F83) that there is something to be read from the touchpad IC. It was not needed in the captures.

I wrote some python to work with the CSVs saved out of DSView - and now understand the flashing protocol.

This helps a lot because, if there is ever an open sourced firmware for the SH68F83, it will need to have code to flash the touchpad IC. Going through the SH68F83 is the only way for the OS to flash the touchpad without physically attaching to that i2c bus.

RE: Touchpad, Keyboard, I2C oh my. - akirakyle - 04-05-2020

(01-15-2020, 05:17 PM)resistanceisfutile Wrote: How I suspect the keyboard and touchpad firmware update process works:
  1. A firmware fw_tp_update.hex is flashed to the SH68F83. This firmware appears to be named XW-TPUTOOL_TV3-US-H1-12-00.
  2. The touchpad update firmware receives tpfw.bin over USB and then flashes it to the touchpad IC (likely over i2c at 400KHz, but could be some OOB bitbang over the i2c bus)
  3. The fw_ansi.hex or fw_iso.hex are then flashed back to the SH68F83.
According to the SH68F83 datasheet, two flashing modes are described. ICP (JTAG) after an undocumented waveform is modulated - followed by the flash - the protocol also undocumented. Another mode, SSP (Self-Sector Programming) is described. This mode is performed by code running on the 8051 MCU, and would thus require said code to be part of the firmware image.
Dissassembly of the 8051 code in the available images has so far been fruitless. The SH68F83 has many application-specific SFRs that - while listed in the datasheet - do not appear in any of the dissassemblies I have tried (after modifying a disassembler to print their names).

If SSP mode is being used, then there should be code in the firmware images that more or less does the following:
  • Get a block of data from the USB transceiver. Using the TX* and RX* SFRs.
  • Fill XPAGE, IB_OFFSET, and IB_DATA SFRs with the flash sector, offset into the sector, and data to write.
  • Kick off a state "gate" by sequentially filling IB_CON1, IB_CON2, IB_CON3, IB_CON4, and IB_CON5 with a magic numbers.
Another theory is that there is perhaps an undocumented USB flashing mode and the updater tool (which I've been told was derived from a mysterious reverse-engineered? windows-based flash tool).

I've been attempting to understand the disassembled firmware and have made some progress in understanding the update mechanism. I'm documenting in detail what I've done in my fork of Jack Humbert's fork of the keyboard updater utility where he started doing some disassembly and reverse engineering mostly to understand the keycodes and generate custom mappings.

I've determined that 0x3000 - 0x4000 in the keyboard firmware is responsible for handling the firmware updates and specifically the function at 0x3D3C starts the SSP mode, going through all the IB_CON steps. I'm trying to get a better idea of the whole update procedure before I go on trying to understand the touchpad communication  since the update mechanism will determine how risky updating the firmware with custom code will be. Having access to the ICP documentation would definitely make this less necessary but right now I feel this is the only way to determine how easily we can test new firmware that touches actual logic (as opposed to just the mostly data patches made so far by Jack Humbert) without bricking the keyboard and touchpad.