Fixing a bricked AMD 7040 series Framework 13” laptop with $20 tools
64 points by LolPython
64 points by LolPython
So... Framework push BIOS updates via fwupd that are bricking laptops, pushing people heavily to install them, and then disclaiming all responsibility when it actually bricks the hardware?
That's scummy as all hell.
This was a good read, especially since I'm about to update my 11th gen intel framework to the latest bios.
He lost me on the Metabase stuff.
Finally, it is not clear why Framework needs a “business intelligence” provider in the first place, let alone one that stores customer data in an insecure fashion. It is also not clear why this provider needed information like my phone number or street address. In the communication I’ve received, Framework did not explain why this information was shared or what they were doing with this data, nor has Framework provided any update on their investigation at the time of writing over a week later.
Um, BI tools are just so they can have any information necessary to run a consumer facing business. The alternative to having a BI provider is doing the same thing with excel spreadsheets, or not doing any sort of BI at all and being totally surprised when 100 people order your product in Australia without you noticing the need to ship to that country.
BI is kinda fundamental to a company being able to provide a good customer experience. And good on Framework for using an open source BI system.
Immediately cease any unnecessary data sharing with third parties.
But they didn't. A third party didn't have the use of the data, any more than you share data with Atlassian when you put stuff in a Jira ticket.
This last paragraph is misleading. Framework says they were using Metabase cloud. Whether that third-party was using the data or not is immaterial to the breach.
Jira is all Atlassian cloud. Yes the third party was breached leading to the data being stolen, but the data was not meaningfully handed to the third party any more than using Jira involves handing the data to Atlassian.
It does, though, surely? The point about data security and privacy is where the data goes, not what the label on the form says. If a third party has access to data, then you've shared the data with that third party. If this is not personal data then nobody really cares, but people get worked up about personal data because if people do wrong things with personal data, bad things happen.
This is also why the big cloud providers have data centres in multiple places around the world, and in particular also in Europe, for example, to satisfy demands that data does not leave the EU that exists in some situations. (Because data entering the US, or other places, may have practical consequences for the security of that data.)
I am surprised they don't have an A/B BIOS jumper or at least a "hidden" process where BIOS B is flashed, booted to, then, if the boot succeeded, A is overwritten or something. We are talking about cents this would cost. As mentioned by @projectgus, when the BIOS quality is so bad, then this is a natural solution.
As far as I’m aware this setup is way less common than you’d think. In the world of custom PCs Gigabyte is known for having this for the longest time on their motherboards, but I’m not aware of anyone else doing so
I'm not that familiar with UEFI, but one of the issues is that a single laptop "BIOS update" runs a bundle of firmware updates as well as the main UEFI update (firmware for the Thunderbolt controller, USB retimers, Embedded Controller, other things I can't think of right now).
So for a solid A/B boot process you'd ideally want all of those components to also A/B boot, otherwise you've now got a combinatorial set of possible firmware versions that could be booting together.
Maybe you could move flashing of external chips out of the UEFI update path and into the UEFI boot path, so the main UEFI boot process would check all of these components' versions on each boot and flash them if necessary. This adds complexity and another failure point, but maybe not the worst idea?
In any case, I think it is a genuinely hard thing to get right.
BIOS quality on the Intel Frameworks was also a mess when I looked into it two years ago. I fear this is the reality of a small VC-funded company making laptops, technical resources end up focused on developing new models to sustain growth. Everything else is consequently less important.
My Framework 13 also died immediately after a BIOS update, although in that case it was probably a coincidence[^]. Like the author I discovered the only supported "repair" was to buy a new mainboard. Instead I replaced my Framework with an ex-corporate ThinkPad and haven't looked back.
(In my case I have the skills and tools to attempt a mainboard repair, and even bought some replacement chips, but haven't yet been able to motivate myself to actually do the repair. Motivation dropped further after the first six months or so, when I learned about Framework's questionable choices in OSS financial support.)
[^] Specifically that the Embedded Controller had been running for a while, but it reset after the BIOS update and failed to initialise the onboard charger IC.
I'll be honest, I don't know any vendor who does a good job with BIOS/firmware. Any time any of them try anything more complicated than setting defaults and hiding options something breaks (making ACPI a virtual machine was a mistake.)
At least UEFI capsules made bricking a lot less likely, and made it so you no longer had to boot DOS.
They substantially improved their firmware release cadence over the last year or two, after getting caught with their pants down. I had been updating faithfully after each release, though with a month delay. But, think I'll skip this 3.20 release as the notes primarily mention the Pro, and not interested in brick recovery.
Speaking of, anyone had a go with the new (Intel) Framework 13 Pro?
(Seems like there was quite a backlog, the site says it will ship in November if you order now)