01-15-2020, 05:17 PM
(This post was last modified: 01-15-2020, 05:21 PM by resistanceisfutile.
Edit Reason: Added note about bCountryCode
)
As of the latest firmware update for the keyboard and touchpad that is miles better for the keyboard, users have been reporting a sort of input lag with the touchpad. With the right libinput tweaks, it is a little annoying but usable.
I too did some experimenting, but did not get very far.
The keyboard is driven by the SH68F83, which presents two interfaces over USB - one for keyboard and one for touchpad. The touchpad is connected to the SH68F83 over an i2c bus. An eeprom is also connected to the SH68F83 i2c bus and is used only for persisting the kill switches states. When the touchpad is touched, interrupts are fired alerting the SH68F83 to read registers and proxy data back to the OS over USB.
@xalius has been attempting to reverse the the firmware that runs on the SH68F83, a USB/keyboard MCU with an 8051 core.
How I suspect the keyboard and touchpad firmware update process works:
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:
Access to the i2c bus is available on the touchpad. Can access the eeprom here too. I forgot to mark V33 (3.3V) is the pad next to D1.
![[Image: yYI8392.jpg]](https://i.imgur.com/yYI8392.jpg)
From the factory, the eeprom is erased (all 0xFF). What this tells us is the firmware running the SH68F83 is checking for 0xFF at address 0x00 of the eeprom and ensuring none of the kill switches are enabled.
The 3 LSBs of address 0x00 in the eeprom correspond to the state of the kill switches:
Pine+F10 = Bit 1
Pine+F11 = Bit 2
Pine+F12 = Bit 3
All other bits will be zero. Once a kill switch is pressed, the 3 LSBs will hold the state of each switch and the rest of the bits will remain zero forever. High = kill switch enabled, Low = disabled.
When the system boots, the SH68F83 firmware accesses the eeprom to read these 3 bits. This occurs regardless of what is happening with the SoC.
All I have is a Bus Pirate - and it's not fast enough to sniff even the 100KHz i2c. I was able to capture partial data from both the eeprom accesses and from the touchpad. However, the flash operation over i2c (or OOB something?) was either running at 400KHz or it's not i2c. The idea is to get a dump of what gets sent to the touchpad IC during step-2 of the firmware updater tool, as that is when i saw the largest burst of traffic over i2c.
Regarding the touchpad IC. The spec sheet from the pinebookpro wiki says the touchpad is using a PCT1336QN - for which a datasheet is available. It is a QFN48. Even though the pcb is the same model number, they're not using a PCT1336QN. It's a QFN40 part number HLK H2168. Searches for any information on this part have come up with nothing. No idea what it is. And without a $400 Saleae, I've exhausted my options.
Hoping somebody with more toys and experience can pick up from here? Here's what we're hoping for:
Additional note: I found the bCountryCode byte in both the ISO and ANSI firmwares in what I think is what the datasheet refers to as the "Information Block", which could be useful. Gave @xalius a link to my patched firmwares for testing. This could be helpful in terms of further updates - the flasher tool could detect the country code and thus eliminate the need to specify it when running the update.
I too did some experimenting, but did not get very far.
The keyboard is driven by the SH68F83, which presents two interfaces over USB - one for keyboard and one for touchpad. The touchpad is connected to the SH68F83 over an i2c bus. An eeprom is also connected to the SH68F83 i2c bus and is used only for persisting the kill switches states. When the touchpad is touched, interrupts are fired alerting the SH68F83 to read registers and proxy data back to the OS over USB.
@xalius has been attempting to reverse the the firmware that runs on the SH68F83, a USB/keyboard MCU with an 8051 core.
How I suspect the keyboard and touchpad firmware update process works:
- A firmware fw_tp_update.hex is flashed to the SH68F83. This firmware appears to be named XW-TPUTOOL_TV3-US-H1-12-00.
- 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)
- The fw_ansi.hex or fw_iso.hex are then flashed back to the SH68F83.
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.
Access to the i2c bus is available on the touchpad. Can access the eeprom here too. I forgot to mark V33 (3.3V) is the pad next to D1.
From the factory, the eeprom is erased (all 0xFF). What this tells us is the firmware running the SH68F83 is checking for 0xFF at address 0x00 of the eeprom and ensuring none of the kill switches are enabled.
The 3 LSBs of address 0x00 in the eeprom correspond to the state of the kill switches:
Pine+F10 = Bit 1
Pine+F11 = Bit 2
Pine+F12 = Bit 3
All other bits will be zero. Once a kill switch is pressed, the 3 LSBs will hold the state of each switch and the rest of the bits will remain zero forever. High = kill switch enabled, Low = disabled.
When the system boots, the SH68F83 firmware accesses the eeprom to read these 3 bits. This occurs regardless of what is happening with the SoC.
All I have is a Bus Pirate - and it's not fast enough to sniff even the 100KHz i2c. I was able to capture partial data from both the eeprom accesses and from the touchpad. However, the flash operation over i2c (or OOB something?) was either running at 400KHz or it's not i2c. The idea is to get a dump of what gets sent to the touchpad IC during step-2 of the firmware updater tool, as that is when i saw the largest burst of traffic over i2c.
Regarding the touchpad IC. The spec sheet from the pinebookpro wiki says the touchpad is using a PCT1336QN - for which a datasheet is available. It is a QFN48. Even though the pcb is the same model number, they're not using a PCT1336QN. It's a QFN40 part number HLK H2168. Searches for any information on this part have come up with nothing. No idea what it is. And without a $400 Saleae, I've exhausted my options.
Hoping somebody with more toys and experience can pick up from here? Here's what we're hoping for:
- A proper dissassembly of the SH68F83's 8051 code from the firmware .hex files.
- A dump of sniffed i2c traffic during a firmware update of the touchpad.
- A dump of sniffed i2c traffic while using the touchpad, with correlation to what was happening on the touch pad (tapping, two fingers, scroll, pressing the buttons, etc.)
- What the heck is the HLK H2168? Datasheets or any info anyone can find about this chip are greatly appreciated.
Additional note: I found the bCountryCode byte in both the ISO and ANSI firmwares in what I think is what the datasheet refers to as the "Information Block", which could be useful. Gave @xalius a link to my patched firmwares for testing. This could be helpful in terms of further updates - the flasher tool could detect the country code and thus eliminate the need to specify it when running the update.
