awesome, me too
would you confirm also getting
1c7882e5d2c00e85b8820bac3eeea10219cad61815ed86d3fedde1fb018bce91 Framework_Laptop_13_Ryzen7040_BIOS_3.03b_efi.zip
2 posts were merged into an existing topic: [RESPONDED] Complexity rules for BIOS password? Why? (Moved)
My charger STILL doesn’t work on this update.
https://satechi.net/products/165w-usb-c-4-port-pd-gan-charger
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.
The specific USB-PD bug that this update fixes is described in the first posts by @patagona here: AMD Framework USB-C charger compatibility issues
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.
1 Like
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.
1 Like
Can anyone confirm the sha1sum of the *.cab is 892d03afc0bb80dd358f5e076667e4191ec35870 ?
2 Likes
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.
3 Likes
Not dev, but I got success flashing with
sha1sum 892d03afc0bb80dd358f5e076667e4191ec35870 Framework_Laptop_13_Amd_Ryzen7040_fwupd_3.03b.cab
2 Likes
The fact the we all have the same hash is irrelevant. We need to know what it is before they supply us with the file.
6 Likes
Thanks for bringing this up. I verified the hashes on the files before they were uploaded to our download site and added them to the first post.
We will include hashes in future releases for everyone.
The windows updater always is signed by the framework EV key, and timestamped.
For the security paranoid, our windows EV certificate is going to be rotated next month, as the current certificate will expire.
14 Likes
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.
Good stuff. Thanks
Hope this is the real you and not some imposter 
@Kieran_Levin do you have any idea when this 3.03b release turns into an official one. At least I got the impression it is a beta release.
2 Likes
… How could I have possibly done this? (I think I updated, or tried to, a month or so ago when I got mine).
Now when I try to run the fwupd command that’s listed I get:
sudo fwupdmgr get-devices 1e8c8470-a49c-571a-82fd-19c9fa32b8c3
Selected device: Fingerprint Sensor
Framework Laptop 13 (AMD Ryzen 7040Series)
│
└─Fingerprint Sensor:
Device ID: 23e[REDCATED]
Summary: Match-On-Chip fingerprint sensor
Current version: 01000252
Vendor: Goodix (USB:0x27C6)
Install Duration: 10 seconds
Serial Number: [REDACTED]
GUID: 1e8c8470-a49c-571a-82fd-19c9fa32b8c3 ← USB\VID_27C6&PID_609C
Device Flags: • Updatable
• Device can recover flash failures
• Signed Payload
Device Requests: • Image
fwupdmgr local-install --allow-reinstall Framework_Laptop_13_Amd_Ryzen7040_fwupd_3.03b.cab
Decompressing… [ \ ]
Specified firmware is older than installed '0.0.3.3 < 771'
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.
1 Like
It said it was already updated… I did reboot, maybe that did something.
Eitherway, it’s working now!
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?
Every answer will be appreciated.