Touchpad, Keyboard, I2C oh my.
#1
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:
  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).

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]

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.
  Reply
#2
I have a logic analyzer fast enough to capture 400kHz i2c, but I do have a question that I'd want answered before hooking my pbp up.

1. How do I use the laptop with the cover removed safely? The wiki mentions possible structural damage to the computer if you open it while the bottom cover is off. To capture the firmware I could leave the laptop closed and do the update via SSH or something, but in order to capture the i2c traffic from the trackpad itself, I'd need to have it open with the trackpad available while the cover is off.
  Reply
#3
(01-15-2020, 05:17 PM)resistanceisfutile Wrote: * 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.)


Can't you instrument the kernel i2c driver to log what it sends out?
  Reply
#4
(01-15-2020, 06:03 PM)C_Elegans Wrote: I have a logic analyzer fast enough to capture 400kHz i2c, but I do have a question that I'd want answered before hooking my pbp up.

1. How do I use the laptop with the cover removed safely? The wiki mentions possible structural damage to the computer if you open it while the bottom cover is off. To capture the firmware I could leave the laptop closed and do the update via SSH or something, but in order to capture the i2c traffic from the trackpad itself, I'd need to have it open with the trackpad available while the cover is off.

If you haven't yet dissassembled it, there are some gotchas I don't think were mentioned. Namely the two speakers. The bottom shell is SHARP, so be mindful. The speakers have an adhesive and sometimes stick to the bottom shell. They're connected by very thin wires. When you're pulling the bottom shell off, do so very slowly and check to see if either of the speakers are sticking to the bottom shell. You'll need to carefully unstick them before fully removing the shell.

After dissassembly, the first thing I did was unhooked the battery. There is a yellow sticker with an important note about the bypass cable. Each end of the bypass cable is stuck to the internal chassis with some black adhesive near/under the yellow sticker. AFTER AND ONLY AFTER you have disconnected and/or removed the battery, connect the bypass cable. DO NOT forget to unhook the bypass cable before hooking the battery back up and re-assembling!!!

I then soldered my probe wires to the touchpad's test points.

Then, while only placing pressure with my fingers as close to the hinges as possible, I very carefully and slowly opened the hinges and turned the laptop over to it's normal operating position - with the probe wires sticking out in front of the unit.

After reassembly, the hinges appear fine. No apparent damage. Oh - don't forget about the two plastic retainer clips!

(01-15-2020, 06:10 PM)Der Geist der Maschine Wrote:
(01-15-2020, 05:17 PM)resistanceisfutile Wrote: * 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.)


Can't you instrument the kernel i2c driver to log what it sends out?

99% certain this i2c bus is not visible to the SoC, so the kernel won't see anything.
  Reply
#5
(01-15-2020, 06:16 PM)resistanceisfutile Wrote:
(01-15-2020, 06:10 PM)Der Geist der Maschine Wrote:
(01-15-2020, 05:17 PM)resistanceisfutile Wrote: * 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.)


Can't you instrument the kernel i2c driver to log what it sends out?

99% certain this i2c bus is not visible to the SoC, so the kernel won't see anything.

That would be i2c bus 0, 1, 4, 9 and 10. The schematics probably tell you where they are connected.


lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-0 -> ../../devices/platform/ff3c0000.i2c/i2c-0/i2c-dev/i2c-0
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-1 -> ../../devices/platform/ff110000.i2c/i2c-1/i2c-dev/i2c-1
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-10 -> ../../devices/platform/fec00000.dp/i2c-10/i2c-dev/i2c-10
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-4 -> ../../devices/platform/ff3d0000.i2c/i2c-4/i2c-dev/i2c-4
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-9 -> ../../devices/platform/ff970000.edp/i2c-9/i2c-dev/i2c-9


If you are right, then that will complicate things quite a lot ...
  Reply
#6
(01-15-2020, 06:28 PM)Der Geist der Maschine Wrote: That would be i2c bus 0, 1, 4, 9 and 10. The schematics probably tell you where they are connected.


lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-0 -> ../../devices/platform/ff3c0000.i2c/i2c-0/i2c-dev/i2c-0
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-1 -> ../../devices/platform/ff110000.i2c/i2c-1/i2c-dev/i2c-1
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-10 -> ../../devices/platform/fec00000.dp/i2c-10/i2c-dev/i2c-10
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-4 -> ../../devices/platform/ff3d0000.i2c/i2c-4/i2c-dev/i2c-4
lrwxrwxrwx  1 root root 0 Jan 15 15:58 i2c-9 -> ../../devices/platform/ff970000.edp/i2c-9/i2c-dev/i2c-9


If you are right, then that will complicate things quite a lot ...

Just looked. This i2c bus is not exposed to the SoC. See page 20 of the schematic.
  Reply
#7
Quote: Then, while only placing pressure with my fingers as close to the hinges as possible, I very carefully and slowly opened the hinges and turned the laptop over to it's normal operating position - with the probe wires sticking out in front of the unit.

After reassembly, the hinges appear fine. No apparent damage. Oh - don't forget about the two plastic retainer clips!

Thanks, That's what I wanted to know. I'll try and give it a shot Friday or Saturday
  Reply
#8
(01-15-2020, 06:33 PM)C_Elegans Wrote:
Quote: Then, while only placing pressure with my fingers as close to the hinges as possible, I very carefully and slowly opened the hinges and turned the laptop over to it's normal operating position - with the probe wires sticking out in front of the unit.

After reassembly, the hinges appear fine. No apparent damage. Oh - don't forget about the two plastic retainer clips!

Thanks, That's what I wanted to know. I'll try and give it a shot Friday or Saturday

On second thought - I'm looking more closely at this to be 100% on it. The SH68F83 is on the main board, so it's possible? If so, then all of this probing craziness is unneeded.

That's a no. Page 20 shows SDA/SCL 19. Page 10 has the GPIOs. No connection between this i2c bus and the SoC.
  Reply
#9
Well, I got impatient and decided to do it this morning: https://drive.google.com/open?id=1D5SfKV...7bmsBweSOb

Included files:
click.dsl     -  a single click using the mouse button
drag.dsl     -  me dragging my finger around for a few seconds
i2c1.dsl      - random clicks, drags, and taps
start1.dsl     - Recording of the i2c activity on laptop startup
start2.dsl     - Same as start1
tap.dsl         - a single tap
updater-step1.dsl      - The i2c activity while running step1 of the update utility
updater-step2.dsl      - The i2c activity while running step2 of the update utility



These files are compatible with DSView, however I'll try to convert them to a more open-source friendly format this evening.
  Reply
#10
(01-16-2020, 10:03 AM)C_Elegans Wrote: Well, I got impatient and decided to do it this morning: https://drive.google.com/open?id=1D5SfKV...7bmsBweSOb

Included files:
click.dsl     -  a single click using the mouse button
drag.dsl     -  me dragging my finger around for a few seconds
i2c1.dsl      - random clicks, drags, and taps
start1.dsl     - Recording of the i2c activity on laptop startup
start2.dsl     - Same as start1
tap.dsl         - a single tap
updater-step1.dsl      - The i2c activity while running step1 of the update utility
updater-step2.dsl      - The i2c activity while running step2 of the update utility



These files are compatible with DSView, however I'll try to convert them to a more open-source friendly format this evening.

Beautiful! I installed DSView here and was able to export the decoded i2c to CSV files for further analysis. Thank you very much!

I take it you've never activated any of the kill switches? Your two startup captures don't show any traffic to the eeprom. I noticed on my end that once kill switches have been pressed, the startup looks quite different forever there after. No need to capture again though. These are great.

updater-step2.dsl looks the most promising. Looks like an eeprom inside the HLK H2168 is behind address 0x1A Smile
Your captures are good. Now we know how tpfw.bin gets flashed, but I still don't know what exactly the bytes in tpfw.bin are.

Thanks again.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Major keyboard and touchpad fiemware issues Nick_dnepr 5 243 08-03-2020, 02:05 AM
Last Post: Nick_dnepr
  Pinebook Pro Revised Keyboard Firmware jackhumbert 58 15,475 07-29-2020, 02:54 PM
Last Post: as400
  Keyboard transplant issues U47 3 218 07-06-2020, 09:10 PM
Last Post: U47
  Up Arrow on US Keyboard PitCritter 0 157 06-17-2020, 07:33 AM
Last Post: PitCritter
Question Is work still being done on the Pinebook Pro keyboard drivers Feakster 5 605 06-12-2020, 10:10 AM
Last Post: Arwen
  Keyboard - Some keys not working Christoph.Krn 0 166 05-19-2020, 05:36 AM
Last Post: Christoph.Krn
Question Help: Keyboard and trackpad SPI update utility broke trackpad Feakster 9 652 04-03-2020, 06:29 PM
Last Post: petertog
  Center touchpad under typing keys in future versions? Damon 3 344 03-21-2020, 02:01 PM
Last Post: Dendrocalamus64
Exclamation Firmware/Keyboard Failure on ANSI PBP Jeremiah Cornelius 1 285 02-08-2020, 06:59 PM
Last Post: bcnaz
  ANSI PBP Keyboard Mapping for Tilde character appdev46 3 320 01-15-2020, 05:33 AM
Last Post: bcnaz

Forum Jump:


Users browsing this thread: 1 Guest(s)