Newsgroup: it.hobby.elettronica.digitale
Titolo: Bootloader x Ethernet: approccio

Vorrei scrivermi un semplice bootloader per l'aggiornamento del firmware 
che utilizza l'Ethernet per lo scaricamento della nuova versione. 
Siccome non vorrei fidarmi dell'applicazione che risiede nel micro (in 
quanto potrebbe essere buggata e quindi bloccata), vorrei utilizzare la 
strategia:
 
1. all'accensione parte il bootloader che tenta di trovare una nuova 
versione del firmware dalla rete;
2. se lo ricerca è andata a buon fine, procede con l'aggiornamento;
3. altrimenti lancia l'applicazione residente in memoria.
 
Il problema con questo metodo è che il bootloader, all'accensione, non 
conosce l'indirizzo IP con cui comunicare per ottenere la nuova versione 
(stavo pensando a TFTP) e non conosce neanche il proprio indirizzo IP 
(magari lo conosce l'applicazione, ma vorrei creare un bootloader 
indipendente dall'applicazione).
 
Stavo pensando di far trasmettere al bootloader un pacchetto broadcast 
Ethernet proprietario con cui chiedo "C'è il server con il mio nuovo 
firmware?". Il computer su cui gira il software di aggiornamento, 
connesso allo stesso segmento LAN, risponde con il proprio indirizzo IP 
all'interno del frame Ethernet di risposta. Così il bootloader capisce 
l'indirizzo IP del server, configura il proprio indirizzo IP in modo che 
possa comunicare sulla stessa sottorete e avvia il trasferimento del 
file tramite TFTP.
 
Secondo voi potrebbe funzionare? Avete altre proposte che soddisfano i 
miei requisiti? Ho la sensazione di reinventare la ruota...

 Ho la sensazione di reinventare la ruota...
 
Il dhcp può fornire delle informazioni standard adatte allo scopo, in 
particolare option 66 e 67.
- 
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml#options
 
- 
http://tools.ietf.org/html/rfc951
 
 
 
-- 
Design for the future, because it will be here sooner than you think.
(C) Eric S. Raymond, from "The Art of Unix Programming"

 miei requisiti? Ho la sensazione di reinventare la ruota...
...effettivamente :-)
Con il tuo approccio il boot loader dovrebbe prima chiedere se c'e'
un nuovo firmware e poi attivare l' applicazione (mi pare di capire).
Questa modalita' su dispositivi a microcontrollore di solito non si usa
e l' aggiornamento va richiesto esplicitamente (per evitare casini in
campo).
 
Per entrare in upgrade di solito si usano uno o piu' di questi
meccanismi:
- Mancanza di firmware (applicazione) a bordo o errore di CRC
   se previsto..
- Hardware: Un pin di IO collegato a un jumper-lo stato del pin alto
   o basso letto dal boot loader attiva l' aggiornamento o meno del
   firmware.
- A tempo: Il boot attende per un tempo x (ad esempio 10..15sec) un
   comando di aggiornamento via seriale o ethernet prima
   di attivare l' applicazione.
   ( se e' tollerabile ritardare la partenza dell' applicazione)
- da applicazione: Un comando esplicito vas previsto nell' applicazione
   per saltare al boot loader.
 
Per quanto riguarda IP (e presumibilmente MAC address), se
la scheda dispone di EEPROM, questi parametri devono avere
un formato e posizione comune nota ad applicazione e boot loader,
oppure il boot deve avere un meccanismo per passarli all' applicazione.
E' possibile implementare un BOOTP o un DHCP, ma dipende da quanto
spazio ha  a disposizione il boot loader.
Se ci sono piu' nodi in rete contemporaneamente c'e' una leggera 
complicazione da tenere prtesente per il riconoscimento dei vari nodi,
specie se il  firmware deve essere diverso :-)
 
 
a.

 specie se il firmware deve essere diverso :-)
 
In realtà l'unica complicazione che vedo è se i diversi nodi si 
accendono contemporaneamente, ma anche questo può essere gestito dal 
computer che gestisce l'aggiornamento (potrebbe avvenire con BOOTP un 
aggiornamento contemporanea ai vari nodi).
 

 aggiornamento contemporanea ai vari nodi).
 
 
Io invece li tratterei separatamente. Cioï¿œ anche se piï¿œ nodi 
richiedessero in contemporanea l'aggiornamento li servire parallelamente 
ma in maniera indipendente.
 
Ciao!
Marco
 
 

 miei requisiti? Ho la sensazione di reinventare la ruota...
 
Dai un'occhiata ai sorgenti del bootloader per la famiglia Stellaris di TI,
potrebbe darti degli spunti. Non ricordo in quale pacchetto � incluso,
probabilmente nella driver library:
 
http://www.ti.com/tool/sw-drl
 
 
-- 
Fletto i muscoli e sono nel vuoto.

 ma in maniera indipendente.
si, Ogni nodo puo' essere gestito da un thread parallelo indipendente, 
assicurandosi che ci sia una buona robustezza e gestione delle eventuali 
anomalie.
 
 
 

 una applicazione piu' complessa sul server.
 
Non ho ancora approfondita, ma il BOOTP dovrebbe funzionare con una
manciata di pacchetti UDP per l'assegnazione di un indirizzo IP e una
connessione
TFTP per lo scaricamente dell'immagine da caricare/flashare.



 
In effetti questo usa proprio BOOTP+TFTP.
 

 nulla e sono i nodi a fare da client e chiedere la connessione
 
 
Mi sono spiegato male ma intendevo esattamente questo.
 
Ciao
Marco


Io ho diverse schede su cui abbiamo installato un bootloader ethernet.
 
Ti descrivo la nostra implementazione:
- Il boot è stabilmente flashato sulla scheda, esso non può essere 
modificato se non connettendosi con un programmatore jtag.
- Il boot ha uno stack di rete quasi completo (ha solo l'udp) tramite il 
quale può prendere un indirizzo IP con il dhcp. Il tcp non serve in 
questo caso.
- Il boot ha un server TFTP a bordo. Non è il boot che si connette da 
qualche parte e scarica il firmware, ma è necessario attivamente 
connettersi e uploadare l'immagine.
- All'avvio parte sempre il bootloader, rimane in ascolto per 5 secondi 
di trasferimenti TFTP, altrimenti controlla se nel resto della flash 
trova un firmware valido (check con CRC), e se presente lo fa partire.
- Se il firmware non è presente, rimane in attesa di un trasferimento 
tftp per sempre.
- Le immagini del firmware uploadate via rete hanno un CRC, in modo da 
poter controllare che il trasferimento sia andato a buon fine.
- Quando l'applicativo è in esecuzione, è possibile dare un comando di 
riprogrammazione che consiste in un semplice reset della scheda.
- C'è una sola informazione condivisa tra boot e applicativo: il MAC 
address della scheda.
- Se anche il firmware principale fosse buggato, c'è sempre il modo di 
riprogrammare la scheda resettandola.
- Sia il firmware che il boot, hanno un processo di heartbeat: esso 
invia in broadcast UDP un pacchetto contenente i dati della scheda (tipo 
di scheda, versione fw, mac address, e indirizzo IP). In questo modo è 
semplicissimo fare un programma che sta in ascolto sulla porta UDP 
stabilita e mostra tutte le schede attive.
- La riprogrammazione non avviene mai in modo automatico ma solo in modo 
mirato e volontario da parte dell'utente. Per conoscere l'ip del 
dispositivo da programmare basta usare il broadcast descritto nel punto 
precedente.
 
La procedura per riprogrammare una scheda è quindi la seguente:
 
- Scopro l'indirizzo della scheda con il broadcast UDP
- Lancio l'upload del firmware via TFTP. Il programma tftp deve essere 
configurato in modo da riprovare per qualche secondo.
- A seconda del tipo di scheda, do il comando di reset alla stessa/la 
resetto manualmente.
- Al riavvio l'upload tftp parte e il firmware viene riflashato.
 
Spero possa esserti utile,
Ciao!
-- 
  _|/ Francesco Sacchi - Develer S.r.l.
   |\
http://www.develer.com/
 - 
http://www.bertos.org/
 

 Spero possa esserti utile,
 
Certo che è utile, ti ringrazio di aver condiviso la tua esperienza.
 
 

 il DHCP non hai problemi di sapere anticipatamente l'indirizzo IP.
 
Questo non l'ho capito. Forse ti riferisci al fatto che il server DHCP 
conosce gli indirizzi che ha assegnato? Questo è vero, ma non è una cosa 
semplicissima da sapere per chi non è il server DHCP stesso :-)
 
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org
 

 semplicissima da sapere per chi non è il server DHCP stesso :-)
 
Infatti io sottintendevo di scrivermi il server che assegna l'indirizzo 
IP :-)
 
Il tuo sistema ha il pregevole vantaggio di non utilizzare un software 
proprietario per l'aggiornamento, ma un semplice e standard DHCP server 
e TFTP client che dovrà uploadare un nuovo firmware sul server.  Di 
contro, però, hai bisogno di un software proprietario per conoscere 
l'indirizzo IP della scheda... tanto vale fare un software che si occupa 
di tutto l'aggiornamento.
 
Se poi l'applicazione è buggata e non ti permette di fare il discovery 
dell'indirizzo IP, sei messo male.  E' vero che puoi resettare, ma a chi 
invii il firmware tramite il TFTP client senza conoscere l'indirizzo IP 
della scheda?  Se resetti, non avrai il tempo di fare il discovery, 
configurare il client TFTP e procedere con l'aggiornamento.
 
E' vero che puoi fare un paio di reset (uno per scoprire l'indirizzo IP 
e l'altro per lanciare il client TFTP), ma se ti affidi ad un DHCP 
server che si trova sulla LAN, quindi non gestito direttamente da te, 
rischi che l'indirizzo IP scoperto durante il discovery sia diverso da 
quello che la scheda otterrà al suo riavvio.

 quello che la scheda otterrà al suo riavvio.
 
Stiamo parlando del caso sfigato in cui ho flashato un firmware buggato 
che non invia l'heartbeat. Siccome l'heartbeat serve proprio a vedere se 
la scheda è accesa, è praticamente impossibile che un bug del genere 
passi inosservato ai test (che sono automatici tra l'altro). Può 
accadere durante lo sviluppo, ma non in produzione.
 
Ma anche se fosse, le lease DHCP non durano mica 1ms eh ;-)
I server DHCP riassegnano lo stesso IP allo stesso MAC se la lease non è 
scaduta. Il valore di default è 1 giorno, quindi a meno che tra i reset 
consecutivi non passino più di 24 ore il problema non c'è :-)
 
 
-- 


 consecutivi non passino più di 24 ore il problema non c'è :-)
 
Sinceramente non sono esperto di DHCP.  Sta di fatto che, anche in 
questo caso, devi fidarti di un server DHCP non sotto il tuo controllo 
che, per un qualsiasi motivo, potrebbe essere configurato in modo strano.
 
Comunque sia, mi rendo conto che le possibilità sono infinite, così come 
gli scenari, i requisiti che si vogliono ottenere e le specifiche volute 
da terzi.  Per questo non credo esista LA soluzione ottimale, ma è 
comunque piacevole parlare delLE possibili soluzioni e dei loro pro e 
contro.
 

 contro.
 
Certamente, come detto bisognerebbe conoscere in dettaglio la tua 
applicazione per poter pensare un'architettura ottimale, il confronto 
poi porta sempre a scoprire soluzioni nuove.
 
Ciao!
 
-- 


 attivo.
 
Il mio programma custom servirebbe solo per il firmware upgrade, 
interfacciandosi con il bootloader, e non per il normale utilizzo. 
L'applicazione può essere stata configurata per funzionare con un IP 
fisso o automatico dall'utente e così continuerà a funzionare.  Il 
bootloader, invece, dovrebbe utilizzare *sempre e comunque* la 
comunicazione con il mio software per l'aggiornamento... ma in questo 
caso l'esecuzione di questo software è prevista.
 
Tra l'altro mi viene in mente un'altra domanda: la tua scheda utilizza 
sempre il DHCP, cioè puoi sempre fidarti dell'esistenza di un DHCP sulla 
LAN dove è collegata?  Se non è così, cioè se l'utente ha configurato la 
scheda con un indirizzo IP statico, come faresti a fare l'aggiornamento 
del firmware?

 del firmware?
 
Nel mio caso la scheda richiede sempre il DHCP, non funziona senza. Ma 
non viene installata in una rete generica, è in installazioni 
industriali ad hoc e il DHCP fa parte dei servizi necessari per il sistema.
 
Non sono sicuro di aver capito la domanda, in ogni caso, anche se avesse 
l'IP fisso non cambierebbe nulla. La scheda continuerebbe ad inviare i 
suoi heartbeat e il sw di discovery continuerebbe a scoprire gli IP.


 suoi heartbeat e il sw di discovery continuerebbe a scoprire gli IP.
 
Forse non ho capito io, ma come fa il bootloader a conoscere l'indirizzo 
IP se non viene usato il DHCP, ma un indirizzo IP fisso?  Immagino che 
solo l'applicazione conosca l'indirizzo IP scelto dall'utente, a meno 
che tu non condivida anche questa informazione con il bootloader.
 

 che tu non condivida anche questa informazione con il bootloader.
 
Adesso non viene condivisa perché non serve, ma se dovessi avere gli IP 
fissi anche questa informazione dovrebbe essere disponibile al 
bootloader (come già succede per il MAC).


 bootloader (come già succede per il MAC).
 
Infatti, è l'unico modo.