search

jwise / x2100-ec

Patches for 51nb X2100 Embedded Controller firmware
17 stars 4 forks source link

Adapter sensing #10

Open exander77 opened 2 years ago

exander77 commented 2 years ago

Charging amperage should be set based on the adapter supplied:

It has a sensing pin, but I don't know if it is connected:

65 W  10 kΩ
90 W  not connected (infinity)
135 W  0 Ω
170 W  1.5 kΩ

It should use 1.5-2A for 65W, 3-3.5A for 90W and above.

65W 4-cell 1.5A
65W 6-cell 2A
65W 9-cell 2A
90W+ 4-cell 1.5A
90W+ 6-cell 3A
90W+ 9-cell 3.5A
jwise commented 2 years ago

I don't think the sensing pin is connected, but I don't know for sure. I assume if they connected it they would have, like, done something with it...

I think USB-C sensing might be more possible. Earlier in the WeChat thread, they said that USB-C was controlled by TPS65987D. It has a SMBus interface (three, in fact!), but I'm not sure if that is connected to the EC or not. There are also a handful of GPIOs, and I'm not sure if and how they are connected, either. On I2C1, the address should be 7'b0100xxx (xxx depending on pin strap); on I2C2, the address should be 7'b0111000 (assuming it hasn't been changed by firmware in flash). It's possible to ask the TPS65987D not just whether it's powered from USB-C, but what the power contract it has negotiated is.

Looking in more detail at strings in the EC, some of the few strings that are there are related to USB-C. For instance, there's a string at 2bd68, "TUSB546Set Err:", which seems to allude to a USB / DP1.4 mux, a lower speed version of TUSB1046 shown in figure 9-6 of the TPS65987 datasheet. And there's a function at 22736 that seems to be called in response to a parameter read from the TPS65987, according to the strings; that callback is set up in what I call do_computed_smbus_query_maybe in what I call the computed_bat_query. (I've since renamed that to usbc_smbus_query, but how that actually gets called is a really deep mystery to me.)

So... I think the EC is theoretically capable of doing something to talk to the USB-C PD chip. What it does, I... could not tell you. I dumped a bunch of the EC RAM associated with the USB-C PD code. All of it seems to be zeroes, which seems to be an indication that the code is never hit.

I added a new Ghidra project dump in 1c1aafb with my latest reversing work on that.

exander77 commented 2 years ago

@jwise @xy-tech Already confirmed that the sensing pin is not connected. I would most likely need to connect it to some EC GPIO if I really wanted this to work.

I think sensing on USB-C and fixed value on the barrel would be a great compromise.

I dumped EC RAM on USB-C and barrel, didn't see anything interesting yet.

jwise commented 2 years ago

I think the next step is probably to manually trigger a bat_query to read some SMBus parameter on the TPS65987 and see if we can successfully do that or not. I'll need to refresh my memory on how the bat_query logic actually works, and when it's safe to trigger one. Maybe in a food coma this evening...

exander77 commented 2 years ago

Looking into this. Doesn't it mean that if enable_disable_charger(1,0) is called by usbc_smbus_query it is charging from USB-C? If that is so, we can pass enable_disable_charger(2,0) to differentiate between normal and USB-C charging.

We could then either statically set input current for USB-C and barrel or perform negotiation on SMBus etc.

jwise commented 2 years ago

Making some progress. I have a patch that I haven't tested yet for the smbus routines that adds a 16byte read opcode. And I wrote an atomic patchloader routine that can be used to safely jam larger patches into memory. Time to start really crashing my laptop tomorrow :)

xy-tech commented 2 years ago

Let me know if you guys need a guinea pig!

exander77 commented 2 years ago

@xy-tech Yeah, We are ready to crash our ECs.

jwise commented 2 years ago

Well, good news: my I2C code seems to work. And the atomic patchloader seems to work. And I wrote a script to scan all four I2C interfaces on the EC. And I found some I2C peripherals that I don't know!

The bad news ... neither of the other I2C peripherals that I found seem to be the USB-C controller.

So I spent a lot of hours and learned a lot, but I think this might be a dead-end, unless we get some news from Shenzhen. @xy-tech I posted in the wechat thread with a question for the ODM about how the USB-C controller is hooked up. Hopefully when they wake up they will see it and be able to find an answer for me.