I have to plug my phone in to the second port, then unplug it to trigger the charger to actually work on my laptop otherwise the charging indicator just goes on and off and it doesn’t seem to charge.
I bought a USB PD GaN charger which is supposed to be the spec and I’ve had to do hacky work arounds for 3 months with no feedback until a beta bios update that doesn’t even address the issue.
Like guys- I love this laptop, but this and the random blue screens are a joke. At least tell us what’s happening- we’ve had nothing but silence until this update which hasn’t even resolved the issue. Clearly something is wrong with power negotiation because once I do this workaround I can leave the laptop plugged in by itself for as long as I want but if I unplug the laptop I need to do it over again.
USB charging negotiation is probably the most complicated charging scheme in consumer electronics. There is room for many different bugs in both chargers and devices, and some sloppy leeway to allow some bugs to be tolerated or worked-around in some cases, so it’s really hard to assign specific blame, unless you have some kinda expensive equipment and expertise to analyze the situation. Even the cables need chips in them to tell the device it can pull more than 3A through the cable (and probably max voltage too for higher voltages, I’m not sure).
In your case, plugging in your phone first affects the voltage/current offered on the other ports of the multi-port charger, and it depends on which specific ports too - in some cases the laptop is still offered 100W after the phone is plugged in, in other cases it’s only offered 60W. My guess is you need to get the charger in this 60W offering mode for the laptop to charge, the 100W mode doesn’t seem to work between that particular Satechi charger and the Framework 13 AMD and the particular usb-c cable you use. Exactly why, I have no idea, but it can be complicated. Bad luck, sorry.
That sounds super unsustainable (more e-waste on chips) and unreliable (another point of failure). I prefer the traditional way of measuring voltage drop/internal resistance to get whether to draw max current and I don’t want to buy yet another cable specifically to beg for 48V
I have a similar problem, when plugged into a 4 port UGreen power brick the laptop only draws 2.7A the majority of the time as I mentioned before even it draws 2.93A with a 5V3A supply using the same cable, and when the power brick is connected to another smartphone, the laptop will draw 20V2.93A instead of 2.7A, very strange.
EDIT: 5V3A input doesn’t work, I misread the meter as it showed the computer was powering the power bank
Measuring voltage drop was never a thing in laptops, charger-id before was either a resistor divider on the center pin or in some cases some form of onewire eeprom to read how much it can draw from a power supply. Since the cables were part of the psu the computer didn’t also need to know the capabilities of the cable. It’s a safety feature and makes sense as long as there aren’t too many bad actors putting 5A e-markers into cables that’ll melt down at 5A.
48V needs e-marker for a whole other issue, 48V needs better built connectors cause it’ll arc harder if you unplug it under load.
Power sharing implementations in multi-port chargers can get very weird
I found an interesting way of identifying of whether a cable has e-marker chip. On the TC66 both PWR and PD switch ON, connect the TC66 to a power brick, it’ll negotiate 5V. Then plug in your cable after that. If the TC66 switches of the cable has e-marker, if it stays on the cable has no e-marker.
Can any dev confirm the checksums for the 3.03b releases? I’m not to keen on installing a standalone file especially if it’s a bios update without verifying it first.
Appreciate it. @Richard3 is correct though, the hash is only useful before installing it and it has to come from dev team, they are the only ones who know the genuine hash. No point in installing then checking, hash is meant to check against tampering so you don’t install something malicious.
Can you refresh your fwupd metadata?
This is usually caused by no metadata, which fwupdmgr needs to know how to parse the version string. If you never pull metadata, then fwupdmgr will assume the version format is converted from uint32 to int as the packing. Our bios version is encoded as quad byte packing. so 0x00000303 is unpacked to 0.0.3.3
0x00000303 is 771 when unpacked directly.
Did I get that right? AMD Firmware within BIOS 3.03b BETA still remains version PI1002B which means it does not mitigate the security issues mentioned in bulletin AMD-SB-7009.
Are there any plans to include AMD’s fixes anytime soon in a new BIOS release?
they said the beta release is to swiftly remediate the crashing issues while the full 3.03 will fix the security issues, quite literally said in the OP…
