Quali sono le tecniche per consentire gli aggiornamenti sicuri del software nei sistemi incorporati

Question

Il software di aggiornamento per dispositivi embedded spesso ha la possibilità di "bricking" del dispositivo, ad es. se dovesse accadere che la potenza fallisse mentre si sta scrivendo software su FLASH. Due domande:

1. Quali sono le migliori pratiche per l'implementazione del meccanismo di aggiornamento in modo da ridurre al minimo la probabilità che il dispositivo venga "bricked"?
2. Quali sono le migliori pratiche per rendere il processo di aggiornamento sicuro, in modo da poter recuperare eventi come interruzioni di corrente durante l'installazione del software in FLASH?

Answer 1

Tutto dipende dalla criticità dell'applicazione. I due approcci di base (backup e bootloader) vengono anche combinati a volte.

Molti sistemi hanno un bootloader di sola lettura (come redboot) e quindi due banchi di memoria flash (sullo stesso chip, più spesso). Il bootloader ha quindi un flag per scegliere da quale banca avviare. Il flag cambierà in base a eventi come aggiornamenti (non riusciti o riusciti) e così via.

Quindi, durante l'aggiornamento, la versione in esecuzione copia il nuovo carico nel banco di backup, controlla il checksum, attiva/disattiva il flag di avvio, quindi riavvia il dispositivo. Il dispositivo si riavvia sul nuovo banco, con il nuovo carico. Dopo il riavvio, il nuovo carico può copiare se stesso nel banco di backup.

Spesso c'è anche un timer watchdog con un reset hardware. In questo modo, se il firmware diventa folle, non riesce a calciare il watchdog, il reset dell'hardware riavvierà il dispositivo e il bootloader cercherà un carico sensato.

Il progetto Open Mesh è un buon esempio di questo approccio.

Answer 2

checksum sul flash interna, con una copia di backup di default se il CRC/Checksum non funziona. In questo modo se il dispositivo ottiene un checksum errato, allora sa che l'aggiornamento è incompleto e può ripristinare il firmware predefinito/precedente memorizzato su un altro dispositivo.

Ciò richiede alcuni pre-avvio (forse nel bootloader) per controllare il checksum. Un bit di codice statico.

modifica: oltre ai commenti altrove. Se vuoi controllare il firmware sbagliato, non solo il firmware corrotto, il tuo checsum/checkdata può incapsulare anche le informazioni sulla versione (e un controllo di quell'intestazione) Penso che i router Linksys facciano ciò che può renderli problematici da reflash con firmware personalizzato.

Answer 3

I checksum sono buoni ma salvano solo dai dati danneggiati. cosa succede se si lampeggia in un file di immagine con un checksum valido ma per un modello di prodotto diverso. un boot loader predefinito di sola lettura a cui è possibile accedere in caso di corruzioni di emergenza è la cosa migliore che ho visto.

Answer 4

In particolare ...

scaricare l'immagine sostitutiva ad un'area di memoria senza sovrascrivere QUALSIASI dello spazio programma in corso. Attendere fino al completamento del download, ALLORA calcolare e confrontare i CRC.

Se lo spazio è davvero un problema, è possibile eseguire il 'backup predefinito' AKA 'modalità di ripristino', ma è molto più semplice non farlo in modo distruttivo.

Se sei-veramente-slick ...è possibile eseguire un singolo aggiornamento di scrittura su FLASH per indirizzare il dispositivo all'avvio dalla nuova posizione del codice. Questo eseguirà il ping/pong tra due sezioni di codice completamente separate. Questo è circa il modo più sicuro si può fare questo:

• hanno sempre un recupero bootloader non aggiornabile (Nano-loader), che può essere segnalata per caricare il nuovo codice in qualche modo, se tutto va male.
• Due spazi di programma separati
• Ogni spazio di programma ha un campo "CRC", un "numero di masterizzazione" (superiore al numero di altra pagina di codice) e una parola "non valida" (tutti Fs - non richiedono un cancellare per aggiornare il marcatore "non valido")
• Una volta completato il download, verificare il CRC. Se è buono, masterizza il marcatore 'non valido' nello spazio del programma della vecchia versione.
• Il Nano-loader controlla il contrassegno "non valido" per sapere a quale avvio. Nel caso in cui siano entrambi validi, fare un controllo CRC. Se sono ancora entrambi validi, prendi il numero di masterizzazione più alto

Oh, e quando la gente dice checksum ... non 'controlla la somma' ... Fai un CRC corretto.

Answer 5

1. Mantenere un bootloader sola lettura nella memoria non importa quale
2. Nel bootloader, autorizzare un metodo sicura (per esempio tenendo pulsante X premuto durante il riavvio) di ricaricamento nuova memoria di programma da una fonte disponibile di ingresso (Scheda SD, RS232, qualunque cosa).

Answer 6

Su alcuni dispositivi di laboratorio (piuttosto che di consumo), ho visto le schede costruite con circuiti programmatori. Nel peggiore dei casi, puoi utilizzare la custodia, collegarlo al programmatore e ricaricare il software predefinito --- oppure inviarlo di nuovo per fare lo stesso. 'Corso, questo costa soldi veri.

Alcune schede personalizzate utilizzate in alcuni dei miei progetti hanno avuto ROM sostituibili. Questo è cheeper, ma meno conveniente.

Answer 7

Per rispondere a entrambe le domande, e indipendentemente da eventuali particolari risorse hardware:

• assicura che, prima di eseguire qualsiasi codice dell'applicazione (in fase di avvio, o dopo un download è completato), il bootloader fa un controllo CRC sull'applicazione. Se non è valido, il bootloader non esegue il codice.

• Se il bootloader decide che non può eseguire il codice dell'applicazione, deve avere la possibilità di segnalarlo all'utente e di riavviare il download.

Questi chiaramente più importante se il processore ha flash insufficiente per memorizzare un'applicazione di backup, o RAM insufficiente per memorizzare il nuovo finché non è terminato il download.

In questi casi, ha senso che il file scaricato abbia un'intestazione piccola che consente al bootloader di determinare che il file è appropriato per il sistema. Questa intestazione potrebbe anche avere un CRC. Se l'intestazione è valida per questo sistema e il CRC è corretto, il bootloader può cancellare il flash (ma non se stesso!) E continuare il download. In caso contrario, si interrompe senza toccare il codice dell'applicazione esistente.

Answer 8

nella mia esperienza si riduce a quello che è il tuo punto di costo, se puoi permetterti di avere il doppio del codice/spazio dati sul dispositivo di cui hai bisogno e può riavviare, è semplice, memorizzare la nuova versione in tutti i tuoi extra spazio, eseguo correttamente il checksum sulla nuova immagine e suggerisco anche un controllo più approfondito nella nuova immagine del firmware in quanto potrebbe essere falsificato se non lo fai, ad esempio una sorta di chiave crittografata che garantisce l'origine della nuova immagine. Puoi farlo anche con memorie esterne, per esempio in un progetto usando un PIC ho avuto una EEPROM esterna per la nuova immagine del firmware e un flag che, se impostato all'avvio, caricava una nuova immagine dalla EEPROM.

se non sei così fortunato, non ti puoi permettere quello spazio, quindi la vita diventa più interessante e probabilmente non esiste un modo garantito per evitare completamente la possibilità di errori durante un aggiornamento. In tutti i casi il bootloader dovrebbe essere in un pezzo di memoria protetto da scrittura e se puoi permetterti lo spazio, dovrebbe avere qualche forma base di connettività esterna, ho fatto sistemi con driver USB molto semplici nel bootloader e sistemi con UDP REALMENTE semplice solo stack di rete. O ti consentirà di ottenere almeno una nuova immagine sul dispositivo se si verifica un errore durante un aggiornamento. In questi casi, consiglio vivamente di mettere il bootloader in un'area di memoria di sola lettura, perdi la possibilità di aggiornarlo, ma un aggiornamento in tilt non ti lascerà nemmeno con un dispositivo completamente in muratura. In tal caso, il bootloader è abbastanza piccolo da essere abbastanza sicuro della sua correttezza.

l'ultima possibilità è un sistema che ha bisogno di aggiornare una parte del suo codice durante l'esecuzione ... questo è davvero difficile e di solito richiede il controllo complesso sulla posizione delle funzioni nella memoria e maggiore pianificazione per il futuro nel layout di memoria per raggiungere . Non è divertente ma è fattibile.

Answer 9

So che si risponde a Q, ma alcune persone hanno bisogno di maggiore affidabilità. Se il tuo progetto è davvero mission-critical puoi seguire questa strada.

piano di base è quello di avere sempre un piano di backup che non può fallire.

1. dispongono di PIC o di altri microcontrollori in grado di programmare la memoria flash del processore reale. Puoi usare un checksum su un blocco di dati e interfacciarlo via seriale, usb o anche ethernet (non ridere non è così difficile) Questo dispositivo NON PU be essere riprogrammato sul campo (o forse anche MAI) in modo da essere sempre avere un piano di backup. I PIC possono eseguire server Web su PPP/SLIP o eternet in modo che l'interfacciamento con esso NON sia necessariamente difficile. Google TCP-Lean. Prova a non ridacchiare. (Sito è adatto per lavoro). Metti la porta progrmming da qualche altra parte. La sicurezza non è garantita.

2. Il programma viene eseguito sulla CPU principale ed esegue un boot loader di sua proprietà. Avete tre programmi: un boot loader, un programma di manutenzione e il programma reale.

Ciò consente aggiornamenti al processo di avvio, nonché al programma. È possibile eseguire un caricatore di avvio di backup in alcuni flash aggiuntivi, con un watchdog per ripristinare l'utente e utilizzare il backup se non si avvia.

Così hai un'applicazione integrata aggiornabile, un caricatore di avvio aggiornabile e una modalità di manutenzione aggiornabile. E una modalità di backup che non può fallire.

Spero che nessuno abbia bisogno di trovare questo utile.