Fantascienza: bootloader autoriprogrammanti

Leggevo il datasheet (pag. 277):

The program code within the Boot Loader section has the capability to write into the entire Flash, including the Boot Loader memory. The Boot Loader can thus even modify itself, and it can also erase itself from the code if the feature is not needed anymore.

Quindi, oltre a poter modificare la Flash, il Boot Loader può accedere alla sua stessa memoria e riscriversi! Immaginate ora.... Ho uno sketch che legge dei dati. In base a questi dati modifica un valore nella EEPROM e passa poi il controllo al bootloader: non dovrebbe essere difficile, basterebbe (in teoria!) solo un JMP all'indirizzo a cui inizia il bootloader. Il bootloader parte e legge quel valore dalla EEPROM e, in base a questo valore, modifica sé stesso oppure lo sketch in memoria, poi rende il controllo allo sketch!!! In pratica, l'Atmega si autoriprogramma in base a valori letti... Mettiamo che all'assenza di corrente ed al successivo riavvio il bootloader debba fare qualcosa di differente rispetto alla volta precedente...

Fantascienza oppure realizzabile?

Mettiamo che all’assenza di corrente ed al successivo riavvio il bootloader debba fare qualcosa di differente rispetto alla volta precedente…

Io userei un IF. :wink: :wink:

Quanto ne so io la memoria Flash dove alloggia il Bootloader é protetto da sovvrascrittura con dei Fuse Bit. Quanto ne so io i fuse bit non si possono cambiare tramite il Bootloader.

Ciao Uwe

leo72: Fantascienza oppure realizzabile?

E' più un problema software che hardware, i bootloader aggiornabili tramite se stessi esistono da sempre, non sono semplici da scrivere e occupano molto più spazio di un normale bootloader. Se durante l'avvio è necessario eseguire delle elaborazioni diverse in funzione di cosa è successo prima questo si prevede a livello di applicativo e non certo a livello di bootloader.

@Uwe: devo contraddirti. Il datasheet parla chiaro e tramite fuse si può rendere qualsiasi Flash scrivibile o protetta da scrittura. Questo vale anche per la zona del bootloader, che è poi una zona particolare che può essere riscritta dallo stesso bootlader dato che supporta la modalità Write-While-Read ossia di scrittura durante la stessa lettura. Stasera ho studiato :sweat_smile:

@astrobeed: OK. Quindi il gioco non vale la candela. Denghiu per la precisazione.

leo72: @Uwe: devo contraddirti. Il datasheet parla chiaro e tramite fuse si può rendere qualsiasi Flash scrivibile o protetta da scrittura. Questo vale anche per la zona del bootloader, che è poi una zona particolare che può essere riscritta dallo stesso bootlader dato che supporta la modalità Write-While-Read ossia di scrittura durante la stessa lettura.

Ok questo lo so, ma la domanda é: se ho un area protetta riesco a disattivare la protezione per poter cambiare il contenuto di quel area flash? Ciao Uwe

Solo esternamente, ossia tramite i fuse.

Pero io leggo che posso "riservare" un'area per il bootloader ma posso anche permettere che sia riprogrammata on-the-fly. Questo vale sia per la flash dell'applicazione che per quella del bootloader. E vale anche la possibilità di proteggere da eventuali sovrascritture tutta la flash: in questo modo il mio sketch è al sicuro da riprogrammazioni indesiderate.

prova a togliere il lock alla zona del bootloader (cambiando i fusibili) e carica uno sketch dall'ide

il bootloader si autocancella... infatti il lock viene messo per evitare questo problema

m

e se di default i blocchi non ci fossero e venisse scritto il bootloader ad ogni upload dello sketch da pc? comunque si potrebbe avere un "bootloader minimale" da tenere salvato se qualcosa andasse storto.

ma almeno si potrebbe aggiornare il bootloader di continuo. ma ora, che ci sarà mai da aggiornare? :D

La vedo dura in quanto ad affidabilità

c’è una soluzione:scriviamo in grande sull’IDE il numero di cellulare di chi ha scritto il bootloader cosi tutti i beginners che incartano la scheda gli possono telefonare con comodo :slight_smile:

m

[quote author=Massimo Banzi link=topic=63010.msg457703#msg457703 date=1307201062] La vedo dura in quanto ad affidabilità

c'è una soluzione:scriviamo in grande sull'IDE il numero di cellulare di chi ha scritto il bootloader cosi tutti i beginners che incartano la scheda gli possono telefonare con comodo :)

m [/quote] io così vedo solo santi scendere dal paradiso :D

superlol: [quote author=Massimo Banzi link=topic=63010.msg457703#msg457703 date=1307201062] La vedo dura in quanto ad affidabilità

c'è una soluzione:scriviamo in grande sull'IDE il numero di cellulare di chi ha scritto il bootloader cosi tutti i beginners che incartano la scheda gli possono telefonare con comodo :)

m

io così vedo solo santi scendere dal paradiso :D [/quote] ... HiHi :)

@Massimo ma si cancella perchè comunque si sarebbe cancellato , oppure si cancella perchè l’ide non dice ad avrdude di non farlo?

[quote author=Massimo Banzi link=topic=63010.msg457693#msg457693 date=1307200699] prova a togliere il lock alla zona del bootloader (cambiando i fusibili) e carica uno sketch dall'ide il bootloader si autocancella... infatti il lock viene messo per evitare questo problema m [/quote] Potresti levarmi un dubbio che mi sta scervellando? Usando Arduino come ISP ed un altro Arduino come target abbiamo caricato un optiboot in un chip vergine e Arduino UNO lo riconosce. Se però, con lo stesso metodo inviamo, dopo l'optiboot, il blink allo stesso chip, succede che il chip funziona sia in stand-alone che su Arduino ma succede qualcosa all'optiboot perché non si riesce ad inviargli un nuovo sketch tramite IDE. Eppure la board "virtuale" che abbiamo usato ha comunque i fuses che proteggono l'area bootloader (sono identici a quelli della board UNO, per capirci). Cosa succede secondo te? Grazie.