Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapter sensing #10

Open
exander77 opened this issue Nov 14, 2021 · 8 comments
Open

Adapter sensing #10

exander77 opened this issue Nov 14, 2021 · 8 comments

Comments

@exander77
Copy link
Collaborator

exander77 commented Nov 14, 2021

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
Copy link
Owner

jwise commented Nov 25, 2021

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
Copy link
Collaborator Author

@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
Copy link
Owner

jwise commented Nov 25, 2021

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
Copy link
Collaborator Author

exander77 commented Nov 26, 2021

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
Copy link
Owner

jwise commented Dec 12, 2021

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
Copy link

xy-tech commented Dec 15, 2021

Let me know if you guys need a guinea pig!

@exander77
Copy link
Collaborator Author

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

@jwise
Copy link
Owner

jwise commented Dec 18, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants