Touchpad, Keyboard, I2C oh my.
#11
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.
  Reply
#12
(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.
  Reply
#13
(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.
  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Keyboard - Some keys not working Christoph.Krn 0 50 05-19-2020, 05:36 AM
Last Post: Christoph.Krn
  Pinebook Pro Revised Keyboard Firmware jackhumbert 55 9,298 05-07-2020, 08:18 PM
Last Post: mil
Question Help: Keyboard and trackpad SPI update utility broke trackpad Feakster 9 526 04-03-2020, 06:29 PM
Last Post: petertog
  Center touchpad under typing keys in future versions? Damon 3 182 03-21-2020, 02:01 PM
Last Post: Dendrocalamus64
Exclamation Firmware/Keyboard Failure on ANSI PBP Jeremiah Cornelius 1 202 02-08-2020, 06:59 PM
Last Post: bcnaz
  ANSI PBP Keyboard Mapping for Tilde character appdev46 3 230 01-15-2020, 05:33 AM
Last Post: bcnaz
  Keyboard keys rearrangable? the7thstranger 6 386 01-14-2020, 09:30 AM
Last Post: jackhumbert
Lightbulb Keyboard Shortcut Suggestion Feakster 1 157 11-27-2019, 10:27 AM
Last Post: Arwen
  keyboard problem romansvec 12 758 11-11-2019, 02:45 PM
Last Post: CryptoRick
  Future ANSI Keyboard Option? Updates? u974615 6 629 11-04-2019, 11:40 PM
Last Post: Der Geist der Maschine

Forum Jump:


Users browsing this thread: 1 Guest(s)