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.
Great, thank you for the update! What does the process look like if issues are reported?
We found during testing that the bios password would be cleared during the update if set.
Doesn’t seem as a stopper, password would expire anyway.
How delusional is the hope that the fix for that is disabling the whole bios password expiry and complexity rules bs XD
thank yee for staying on top of it
Hopefully AMD7840U/ GPD Win Max 2 (2023)/ DMI board G1619-04: Hibernation (S4, suspend to disk) or resume hang randomly. (#3168) · Issues · drm / amd · GitLab is fixed in it.
Imagine deploying Frameworks company-wide and the bios password being reset.
That definitely would be a show stopper, and very difficult and time consuming to reconcile.
No more annoying than the fact that practically every time you need to go into the BIOS you need to reset your password anyway.
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).
Makes sense.
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.
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.
Quick update, we got a fix for the bios password that we processing through internal validation.
If no major issues are found we are targeting a release next week.
That is great news! Though going back to the charger topic: are there any plans on supporting dumb charges? As in regular 5V chargers without PD protocol? While these won’t be of much use for any kind of load, being able to load a framework over night without any specific charger would be great!
What about compatibility with Qualcomm’s QuickCharge? Could that even be implemented or would it require some licensing deal or even hardware requirement, thus too expensive to support? There are plenty of chargers or there lacking PD support while supporting QuickCharge.
Just ran into this thread after continuing BSODs.
How did you diagnose this as a firmware issue?
