A BIOS update that doesn't complete – and afterwards the screen stays black. On the Framework Laptop 13 with AMD Ryzen 7040, the BIOS 3.20 firmware package can cause the update process to hang, leaving the notebook unable to boot. This does not automatically erase the data on the SSD – but it does become temporarily inaccessible. What matters now is not attempting any further flash or reset operations.
Framework Laptop 13 BIOS 3.20: notebook won't start – what happened?
On 30 June 2026, Framework released the BIOS 3.20 firmware package as a stable release for the Framework Laptop 13 (AMD Ryzen 7040 Series). It is not a single UEFI update, but a bundle of several embedded firmware components: BIOS 3.20, Embedded Controller (EC, the chip responsible for keyboard, fans and power-on logic) in version ec_320_e0a4f, Power Delivery firmware (PD, responsible for USB-C power supply) 0.0.1C, and AMD Platform Initialization (AMD PI) 1.2.0.0f.
On a subset of devices, this very update process comes to a halt. User reports describe a black screen with the Framework logo and a progress indicator that no longer moves. One case documented in the Framework forum on 7 July 2026 describes an EFI Shell update from BIOS 3.18 to 3.20 that was still stuck at the same point after roughly three hours. Afterwards, the devices are left with no display output or unable to boot normally.
On 19 August 2026, Framework confirmed the incident to Ars Technica. Founder Nirav Patel put it this way to The Verge:
„We've received reports of a small percentage of Framework Laptop 13 7040 Series BIOS updates resulting in non-bootable boards and are investigating the root cause of the issue." – Nirav Patel, founder of Framework, speaking to The Verge
Important for context: Framework has confirmed the end state – non-bootable mainboards – but not the technical cause. There is no reliable figure for how many devices are affected. The manufacturer speaks only of a "small percentage", without giving a base population or a rate. Forum posts, view counts or collective threads are not statistics, and are not treated as such here.
Who and which devices are affected?
- Affected model: Framework Laptop 13 with AMD Ryzen 7040 Series
- Affected firmware: BIOS 3.20 (stable release from 30 June 2026)
- Not affected according to the download page: other Framework Laptop generations – the official download page explicitly limits the package to the Laptop 13 AMD Ryzen 7040 Series
Part of the backstory is that on 24 November 2025, Framework had already fixed a bug with BIOS 3.17 in which a BIOS update could run on the wrong platform and render the system unbootable. An older community report from 24 March 2025 describes a failed update run from BIOS 3.05 to 3.07 – that is a separate, historical isolated case and not the current BIOS 3.20 incident.
How do you recognise the problem?
- During the update: black screen with the Framework logo, progress indicator no longer moving.
- The power button does not respond during the process. On its own, that is no proof of a defect – a locked power button is also a normal safeguard against interruptions during firmware updates.
- After the failed update: the notebook no longer starts normally, or shows no picture at all.
- Individual users report blink codes from the diagnostic LEDs or faulty graphics output. A complete error code table published by Framework specifically for BIOS 3.20 is not present in the sources reviewed.
How to check whether you are affected – without risk
- Check the model. The confirmed incident concerns exclusively the Framework Laptop 13 with AMD Ryzen 7040 Series.
- Read out the BIOS version – only if the device still starts normally. On Windows: press the Windows key + R, enter msinfo32 and read the version under "BIOS Version/Date". On Linux, Framework names the tools dmidecode and lshw for Ubuntu and Fedora respectively. Alternatively, press F2 at startup, go into the Setup Utility and check under "BIOS Version" on AMD systems – the last four digits indicate the version.
- Interpret the result correctly. If it says 3.20, that only means the affected version is installed. It is no proof of damage. Do not start another update and do not downgrade just to check.
- Check encryption. Establish whether BitLocker or Windows device encryption is active, and secure the 48-digit recovery key from another device via your Microsoft or work/school account. Microsoft explicitly points out that BitLocker may demand this key after hardware or security changes – such as a mainboard replacement.
- Document it if it has already happened. Record: the time, the update route (Windows updater, LVFS/fwupdmgr or EFI Shell), the previous and target BIOS version, photos or videos of the display, and any blink codes. These are precisely the details Framework support requests in documented support cases.
What you should do now
- Don't force anything. Don't try to "repair" a hung update with further update, downgrade or reflash attempts. Framework is still investigating the cause.
- Let the device rest. Disconnect accessories, note down the condition and refrain from endless start-up attempts.
- Contact Framework support and state explicitly that a stable-release BIOS update is preventing the system from starting. Framework has pledged to replace mainboards under warranty – and beyond that:
„In the meantime, in addition to replacing in-warranty Mainboards, we are making exceptions for out-of-warranty replacements where we can confirm a stable-release BIOS update caused the board to become non-bootable." – Nirav Patel, Framework, speaking to The Verge
- Before any mainboard replacement: secure the recovery key. Microsoft account, work/school account, printout or USB backup – before the hardware is swapped.
- Treat important data as a separate matter. According to the Framework storage guide, the internal storage of the Framework Laptop 13 is a separate, removable module. A firmware defect on the mainboard therefore does not in itself erase the SSD. Whether and how clean access outside the defective board is possible, however, depends on encryption, the condition of the SSD and proper removal.
What you must never do
This section is the most important one. Most permanent data losses do not arise from the original defect, but from what happens afterwards.
- No "Reset this PC" with the "Remove everything" option. Microsoft describes this function clearly: it reinstalls Windows and removes personal files, apps and settings. That is not a rescue measure, that is deletion.
- Do not format and do not reinstall – least of all on the original SSD. The TestDisk/DDRescue documentation from CGSecurity explicitly warns against formatting a storage device or reinstalling the operating system if content is to be recovered.
- Do not run any repair or recovery software with write access on the only original storage device. CGSecurity on this:
„Instead of working directly on the damaged disk, it's recommended to create a copy and to work on the clone." – CGSecurity, TestDisk/DDRescue documentation
- No DIY external SPI reflash of the firmware chip. A technical first-hand report published by a software developer in August 2026 does describe a successful external reflash as a one-off repair – but at the same time warns clearly:
„One mistake and the chip could be fried, or worse, the whole motherboard." – Guanzhong Chen, software developer, technical first-hand report (not an official fix)
The wrong voltage, the wrong pin connection or unverified firmware can damage the firmware chip or the mainboard. This is not a recovery procedure approved by Framework. - Do not swap hardware or reset Windows without a secured BitLocker key. The key may be absolutely essential after the hardware change – and a reset with "Remove everything" takes your data away before you even need it.
For this specific firmware incident there is no evidence that mere power-on attempts destroy the data on the SSD itself. What permanently destroys data in such cases are the well-meant intermediate steps: the reset, the quick reinstall, the recovery tool writing directly to the original, the reflash attempt with the wrong file. These attempts are precisely the most common reason why data ends up being unrecoverable.
Is there a fix for BIOS 3.20 yet?
As of 22 August 2026, neither a published root-cause fix nor a crisis recovery mechanism documented as available specifically for the Framework Laptop 13 with AMD Ryzen 7040 could be verified. The Framework knowledge base still listed BIOS 3.20 as a download and via LVFS.
Framework has, however, announced a recovery feature. In the community forum, the account labelled "Framework Team" wrote:
„we're introducing 'Crisis Recovery Mode' BIOS functionality to enable a path for failed updates to be directly recoverable." – Framework, community forum
External PR representative Jim Redner named the goal to The Verge: "They are targeting releasing that functionality before the end of year for each product line." So this function will be introduced for upcoming BIOS cycles of the Laptop 12, 13 and 16 – it is a stated target, not a binding date, and as of today not an available fix.
Why this case belongs in professional hands – and how RESQ can specifically help
A laptop that can no longer start because of a failed BIOS update is a special case: there are two separate problems, and they have to be handled separately. First, the mainboard, whose firmware is stuck in an undefined state. Second, your data, which resides on a separate, physically undamaged SSD – but which may be encrypted, and access to which after a hardware swap hinges on the recovery key. Anyone trying to solve both "somehow" in one go risks exactly what they were hoping to avoid.
Professional data recovery at RESQ differs in several respects from what is possible at home with this kind of damage pattern:
- Working on a copy instead of the original. The first step is not repair, but securing the data. An image is first created from the removed SSD – as far as the condition of the storage device permits. All further analysis then runs on this copy. The original remains unchanged, which is crucial when the data exists only once.
- Proper removal and a controlled environment. An M.2 module looks harmless – until it picks up a static charge during removal, is mechanically stressed, or is addressed incorrectly once again on a defective board. Removal, visual inspection and connection to a write-protected diagnostic environment belong in a workshop set up for the purpose, and with mechanically damaged storage devices, in a cleanroom environment.
- Handling encryption. With BitLocker active, it is not the technology that decides but the key. We clarify this with you in advance instead of letting you run into a situation where the board has been swapped and the 48-digit recovery key is missing.
- Experience with firmware failures instead of trial and error. Whether anything sensible can still be done on the board itself, or whether the manufacturer's promised mainboard replacement is the right route, can only be answered seriously after a diagnosis – not by experimenting with your only device.
The process at RESQ is deliberately structured without any upfront commitment on your part:
- Free initial assessment. You describe the case – model, BIOS version, update route, symptoms. You receive an initial expert appraisal of what is realistic in your particular situation. You'll find the way to do so at request a free initial assessment and cost estimate.
- Diagnosis. We examine the storage device and the machine and determine whether the user data is physically intact and readable.
- An honest statement on the prospects and a cost estimate. You learn what is possible – and where the limits lie. Data recovery is always a case-by-case assessment; we do not make promises of success, because they would be dishonest.
- Your decision. Only then do you decide whether we carry out the job. If you would like to get started directly, you can place an order via create an order in your customer account.
If your concern is solely the device and not the data – for example because a current backup exists – then the route via repair at RESQ is the right one. And if this incident reminds you that your last backup was quite a while ago: the backup assistant helps to sort that out for the future. A backup on a different medium is the only protection that completely defuses a failed firmware update.
Conclusion: Framework Laptop 13 dead after BIOS 3.20 – stay calm, have it checked
A Framework Laptop 13 with AMD Ryzen 7040 that no longer starts after BIOS 3.20 is a confirmed mainboard and firmware problem – not proof of deleted data. Framework replaces mainboards under warranty and, where a link to a stable-release BIOS is confirmed, also makes exceptions outside the warranty. A crisis recovery function is coming, but is not yet available for this model.
The greatest risk to your data lies in the next few hours – in the reflash attempt, the reset, the reinstall. Leave the device switched off, swap nothing before the BitLocker key is secured, and write nothing to the original SSD. If there is data on the notebook that you cannot afford to lose: have your case assessed free of charge before you act.
