PD Version 1.0 was actually defined for USB-A. It existed prior to USB-C and was just never implemented. It does not exist in the real world.
The current versions of PD that are actually implemented are not backwards compatible to that first attempt and have replaced most of the stricter concepts of PD 1.0 with better and more flexible alternatives and require USB-C with its CC wires. So any PD today is only valid in combination with USB-C.
USB BC is not defined in the PD standard. It is its own standard designed for USB-A and similar. USB-C is just backwards compatible to it so that legacy adapters work for example with USB-A chargers. And BC is limited to 1.5A for a total of 7.5W. The 5V3A mode of USB-C is defined in the USB-C Standard and called “Type-C Current”, same as the 5V 1.5A mode that USB-C supports independent of USB BC.
And EPR for going above 100W was only added from PD 3.1 onwards.
At least the 12th gen Intel version works with 9V, 12V whatever you want. There were some problems with 11th gen, where 15V I believe was excluded post launch with BIOS updates because it had some hardware problems with that. But since the 12th gen fixed those hardware issues I would presume all the voltages are supported since then. And Framework never had those strict limits to only 20V while operating like many other notebooks have for historical reasons. Though it may not be smart to use that while the FW is running, as chargers that do not supply 20V do not have the power to reliably supply the notebook with more power than it requires itself (i.e. charging the battery needs to be stopped often to supplement with power from the battery).
after this update the FW13 AMD supports most if not all PD ratings except 5V3A, which either won’t charge, or supply 5V3A charging the power bank… Some other computers with PD 20V5A input 5V3A output have the same problem
When can we expect a patch for the LogoFail vulnerability? I’m mostly concerned about that.
Also, if anyone is looking for a great charger, I got this one Nomad 130w. It is a total beast, and has worked flawlessly for me. It’s pricey but on sale right now, 20% off. Can do a 100/30 split and even 70/30/30. It’s small and has great build quality. Paired it with Belkin USB-C Cable. Amazing combo
The beta firmware has improved USB-C PD charging for me. I have a couple of Ravpower chargers (one 65 watt, the other 120 watt) that would get into an infinite loop of handshaking and crashing with the latest released firmware. Now they seem to cycle at most once before starting up and working, so that’s a substantial improvement.
Thanks for the deep link into github; I was never quite sure where to look and which codenames were associated with which products. Much appreciated.
Can someone from the framework team please update about the delayed UEFI release?
Having seen a reddit user post … maybe a month ago that it was coming (still no date but on the way) and no community updates I’m starting to feel like we’re getting strung along for the ride here.
I do very much appreciate that there is any communication whatsoever, that is mega awesome, but what is the hold up?
Hi Everyone,
We are waiting for one critical issue to release our next bios release for the AMD 13 and 16 bios. We integrated AMD updates as well as a Platform update from our bios vendor for this next release. We found during testing that the bios password would be cleared during the update if set.
We have a checkpoint with the bios vendor mid week where we hope they have a fix for us to continue the internal validation and release process.
We have confirmed that this upcoming release fixes Logofail.
It takes us about 1-2 weeks after we get our BIOS build to publicly release it.
We follow the following staged release process.
BIOS team validation.
SA validation at our ODM partner.
Internal validation in parallel with SA validation.
Beta release on our forum.
After the beta release, we will monitor community feedback, and publish to our stable release channel after approximately one week if no major issues are reported.
Absolutely minor inconvenience, compared to day to day dealing with expired passwords with complexity rules, limited length and password history. I can’t imagine any company-wide deployment of AMD Frameworks laptops with BIOS passwords.
Afaik the Framework’s dont have an IP management system employed in their uefi. If there was then yes a minor inconvenience.
I believe, in it’s current state, it would require going to every employee’s workstation asking them to shut down so you can set the bios password, and move on to the next.
While I dont imagine there are large scale deployments of Frameworks at companies yet, it is something I advocate for, and something like that would make it harder to achieve if Framework released a bios with such a bug and failed to communicate it.
I appreciate Frameworks care around releasing well tested bios updates, but I do also feel that a liberal beta program would be nice for home users who are willing to deal with the little hiccups and report bugs.
Especially right now with there being some minor bugs in the bios on every version (retimers, suspend resume issues, general acpi quircks).
Especially considering that currently, the BIOS/AMDFirmware/EC updates are not being pushed via Windows Update, meaning they are entirely manual and optional, and with 3.03 and 3.03b packages available for roll-backs, publishing ‘good enough’ releases with known issues explicitly indicated should be an acceptable way of approaching it, when the final fixed version can’t be made available in short time.
Is there any reason why the microcode in this update isn’t up to date? @Kieran_Levin
Microcodes for AMD consumer CPUs have to be provided by the UEFI/BIOS.
Huh, TIL, the AMD microcode updates in linux-firmware.git are for server CPUs only. That sucks—almost as much as AMD getting into the ECC market segmentation game starting with this CPU generation. Apparently people have been collecting firmware images themselves, and those should probably be safe enough to use given microcode signing, but this situation still seems suboptimal.
It really is pretty frustrating. I’d love to a have a nice fileserver for backups and not worry about my data; but nope, gotta purchase business class servers for mega bucks!
I’d also really like to have updated AMD AGESA and resolved UEFI firmware bugs. Thank you for sharing about the microcode not being included for AMD, I actually had no idea…
On another note… Does anyone know if 7840U has AMD Secure Processor Rollback Protection? Gnome device security report seems to indicate it’s not enabled, and I don’t see an associated setting in UEFI.
P.S. I noticed that when I disabled my TPM2 in UEFI, my UEFI supervisor password was removed without warning.
Tbh my company has provided me a Dell laptop and didn’t set a BIOS password in there. Granted, there isn’t much need to go poking around in there anyway for me, but I can still change enough settings in there to break the installation.
Or maybe their IT support expects most employees to be idiots enough to not realise or know that anyway, but given I work from home and travel a lot, device theft is a possibility that they should take more seriously. I know all you really also have to do is pop the battery anyway but if they have a fTPM set, then my understanding is if Bitlocker (or some other encryption is on that relies on fTPM), then a BIOS reset will wipe that and the drive will remain encrypted. I believe (or would hope so) that they have Bitlocker enabled.
I’ll admit though, I’m a power user, but I’m not as clued into enterprise-level management. They also haven’t caught on that I was so frustrated in how little 8GB is in this day and age after Outlook, antivirus, all their other corporate monitoring tools/vpns, etc gobble up that I upgraded the RAM to 16GB.
