PC bloccato dopo un aggiornamento BIOS: cosa succede e quando si può recuperare

Un aggiornamento del BIOS dovrebbe correggere vulnerabilità e migliorare la compatibilità hardware, non trasformare un notebook perfettamente funzionante in una scheda madre apparentemente da sostituire. È però quanto accaduto a un proprietario di Framework Laptop 13 AMD Ryzen 7040, che ha documentato una procedura di recupero particolarmente interessante: dopo il blocco dell’aggiornamento al BIOS 3.20, il computer è tornato operativo riscrivendo direttamente la memoria flash della motherboard con strumenti dal costo complessivo di circa 20 dollari.

La vicenda merita attenzione anche perché Framework ha costruito buona parte della sua identità commerciale intorno a riparabilità, modularità e diritto alla riparazione. Il Laptop 13 permette di sostituire facilmente RAM, SSD, batteria, display, tastiera e perfino l’intera mainboard. Eppure, quando il firmware non parte più, il confine tra un prodotto facile da smontare e uno realmente riparabile diventa molto più netto.

Nel caso raccontato da Guanzhong “Quantum” Chen, la configurazione monta un chip Ryzen 5 7640U con grafica Radeon 760M e aveva funzionato regolarmente per circa 3 anni. Il problema è comparso durante il passaggio dal BIOS 3.18 alla versione stabile 3.20, pubblicata da Framework nel luglio 2026 e distribuita anche attraverso LVFS per l’aggiornamento da Linux con fwupd.

Perché un BIOS corrotto può rendere inutilizzabile il PC

Nei computer basati su BIOS UEFI la memoria flash contiene numerose regioni e strutture: codice necessario all’inizializzazione della piattaforma, moduli DXE e PEI, variabili UEFI, impostazioni persistenti e altri dati utilizzati nelle primissime fasi dell’avvio.

Se una porzione essenziale del firmware risulta incoerente, il processore può non arrivare neppure al punto in cui il sistema riesce a inizializzare correttamente display, tastiera o dispositivo di boot. Il risultato è quello che comunemente si definisce brick: il computer sembra morto pur non avendo necessariamente alcun componente hardware guasto.

Una progettazione particolarmente robusta può prevedere un firmware di recupero indipendente, una seconda copia del BIOS oppure una modalità capace di caricare un’immagine da USB anche quando il firmware principale non funziona. Diversi produttori hanno adottato meccanismi di questo tipo. Dell, ad esempio, documenta procedure BIOS Recovery su numerosi sistemi; altri costruttori hanno sviluppato soluzioni analoghe nel corso degli anni.

Nel caso descritto, i tentativi suggeriti dal supporto Framework – scollegamento dell’alimentatore, disconnessione della batteria per 30 minuti, successivo ripristino dell’alimentazione – non hanno risolto il problema. Terminati i controlli, il supporto ha indicato come soluzione la sostituzione della mainboard. Poiché la garanzia era scaduta, il costo sarebbe ricaduto sul proprietario.

Framework presentava il BIOS 3.20 come un aggiornamento consigliato: tra le novità figuravano il supporto ad alcuni componenti del Framework Laptop 13 Pro, modifiche al firmware AMD PhoenixPI, correzioni per unità SED, monitor esterni, gestione della batteria e diverse vulnerabilità di sicurezza, tra cui CVE-2025-54502, CVE-2025-29949, CVE-2025-0040, CVE-2024-36355 e CVE-2024-36310.

L’utente aveva già effettuato altri aggiornamenti tramite fwupdmgr senza problemi. Durante l’installazione della versione 3.20, invece, la procedura si è fermata mostrando artefatti grafici anomali. Il portatile continuava a funzionare a livello elettrico, con la ventola attiva, ma l’aggiornamento non avanzava più e il pulsante di accensione non consentiva di interrompere l’operazione.

La flash SPI da 32 MiB è il punto chiave

Il firmware del Framework Laptop 13 risiede su una memoria Winbond W25R256JWEQ, una SPI NOR Flash da 256 Mbit, cioè 32 MiB, che lavora a 1,8 V. È un dettaglio importante: collegare direttamente un programmatore che usa tensioni superiori può danneggiare il chip o altri componenti della scheda.

Il package WSON 8 x 6 mm complica inoltre l’accesso: non ci sono piedini laterali sui quali agganciare una normale clip SOIC. Per evitare la dissaldatura, l’autore ha quindi utilizzato una sonda a pogo pin: la soluzione funziona, ma richiede un contatto stabile per tutta la lettura e la scrittura.

Il diffuso modulo programmatore CH341A sarebbe stato una scelta economica, ma presentava due limiti: il chip Winbond richiede un adattatore a 1,8 V e l’esemplare CH341A provato dall’autore mostrava circa 4,8 V sulle linee logiche. Inoltre, con una flash da 32 MiB, letture e scritture possono richiedere diversi minuti: un intervallo poco pratico quando la sonda deve restare “fissata” sul chip con una pressione manuale. La scelta è quindi ricaduta sul CH347, capace di operare a velocità SPI maggiori.

Il setup finale sfruttato da Guanzhong Chen comprendeva quindi CH347, adattatore 3,3 V/1,8 V e sonda WSON8 a pogo pin. L’autore dichiara una spesa complessiva di 20,41 dollari, nella quale rientrava anche materiale non indispensabile per il recupero.

Prima il backup, poi la riscrittura

Prima di cancellare la memoria flash, l’autore ha eseguito più dump e confrontato gli hash SHA-256, accettando il backup solo dopo aver ottenuto almeno due copie identiche. È una precauzione importante perché un contatto instabile della sonda può introdurre errori nella lettura senza produrre sintomi evidenti.

Con il programmatore CH347 una lettura completa richiedeva meno di 20 secondi. Conservare il dump originale è utile anche perché la memoria non contiene soltanto il firmware generico: possono esserci variabili UEFI, identificatori e informazioni specifiche della macchina.

Framework distribuisce il firmware come capsule UEFI, non come immagine binaria direttamente scrivibile sulla SPI: è quindi necessario estrarre dal pacchetto i 33.554.432 byte corrispondenti ai 32 MiB della flash.

L’autore ha usato InsydeH2O-extractor-2, pubblicando anche un fork compatibile con il proprio ambiente Linux. Il file ottenuto, BIOSFILE.FD, ha esattamente la dimensione della memoria. Per una riparazione reale resta preferibile estrarre personalmente l’immagine dal pacchetto ufficiale Framework invece di affidarsi a file binari scaricati da terzi.

La scrittura con flashrom e il ritorno all’avvio

La programmazione è avvenuta sotto Linux con flashrom: dopo il collegamento del CH347, il software ha rilevato una memoria da 32768 kB e ha riscritto l’immagine BIOS 3.20. Cancellazione e programmazione hanno richiesto meno di un minuto; successive letture hanno confermato l’identità del contenuto tramite SHA-256.

Dopo il ripristino di RAM e SSD, il Framework Laptop 13 è tornato operativo: il primo avvio ha richiesto circa un minuto e le impostazioni del BIOS risultavano azzerate. System UUID e numero di serie mostravano inoltre valori generici: segno che la riscrittura completa aveva cancellato dati specifici della macchina non presenti nell’immagine firmware distribuita dal produttore.

Era sparita anche la voce UEFI usata per avviare Debian, mentre sistema operativo ed EFI System Partition erano ancora integri: l’utente ha quindi avviato manualmente EFI/debian/shimx64.efi tramite l’opzione “boot from file” e ha poi ricreato la configurazione di avvio da Linux.

Riparabilità: il firmware conta quanto l’hardware

La vicenda mette in evidenza un limite interessante del concetto di modularità. Framework permette di sostituire facilmente la mainboard, ma qui il problema reale riguardava una flash da 32 MiB e non CPU, RAM o circuiteria principale: cambiare l’intera scheda avrebbe risolto il guasto, ma con un costo di molto superiore a quello della riprogrammazione.

Il diritto alla riparazione passa anche da firmware accessibili, procedure di recovery, punti di programmazione e documentazione tecnica. Nel caso del Framework Laptop 13 il package WSON e l’assenza di un’interfaccia di recupero dedicata rendono l’operazione possibile, ma non semplice.

Se l’hardware è integro ma la procedura di POST fallisce per un firmware corrotto, la riscrittura della SPI può riportare il computer in vita con pochi strumenti. Resta però un intervento per utenti esperti: tensioni errate, pin invertiti, contatti instabili o immagini firmware sbagliate possono provocare danni permanenti.