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.
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.
Well, seems like supporting Qualcomm’s QuickCharge 2.0 might be possible? The twiddling of voltages is all withing the safe <3.3V of USB data lines, so given the frameworks USB controller supports this control, QC 2.0 support/compatibility should be possible?
As for QC 3.0, it seems to be a proper protocol instead of pulling some voltages on certain lines, so dunno how that entirely works… Though maybe thats not even required, if QC 3.0 is backward compatible with 2.0? Is it?
On the other hand, QC 4.0 seems to be a cross compatible variant with USB PD, so not entirely the same, but compatible just fine. So yeah, they should be able to charge a Framework alright, tho I don’t have a QC 4.0 charger at hand. Can anyone confirm this?
Framework laptops do not support QC 2.0. Or any charging algorithm that requires charge negotiation over the usb 2.0 data lines.
This requires special hardware on the usb data lines which we do not use in our design. Except for the framework 12th gen Intel Chromebook, which can support QC.
For laptops that support dumb chargers, we only support 5V@900mA charging.