Hallo zusammen,
ich bin gerade dabei ein Konzept für ein FW-Update zu erstellen.
Einen einfachen Bootloader habe ich bereits geschrieben und getestet.
Der macht gerade nicht viel. Er startet nur die eigentliche Firmware.
Er muss nun halt mit Leben befüllt werden.
Das Image liegt auf einer SD-Karte die per SPI angebunden ist.
Damit das Image in das Flash geladen werden kann, muss der Bootloader
also das Interface initialisieren und das FAT(32)-Filesystem
unterstützen.
Beides wird auch vom Hauptprogramm verwendet, daher fragte ich mich
"Warum den Speicher doppelt benutzen"? Kann man den Code für den
SD-Karten Zugriff ebenfalls als eine Art Image ab einer bestimmten
Adresse in den Speicher schreiben und vom Bootloader von von der FW
auszugreifen und nutzen?
Danke & Grüße
Bari
Mach es anders:
Binde einen externen Speicherbaustein an, oder benütze einen Bereich auf
der SD Karte, auf dem du im RAW Format zugreifst.
Die Firmware (entschlüsselt) liest die FW File, vergleicht Sie, ob die
CRC,usw. stimmt und schreibt sie in den von dir definierten Speicher.
Anschliesend wird in den Bootloader gesprungen, der dann den Speicher in
den Flash kopiert -> Fertig.
Hallo Fred,
danke für deine schnelle Antwort.
Naja, also das Image soll wir ja über einen PC auf die SD-Karte geladen.
Also liegt sie nun mal im FAT-System vor. Einen extern Speicher kann ich
nicht (mehr) anbinden.
Der Bootloader muss also das Image direkt von der SD-Karte in das Flash
schreiben. Notfalls könnte er es auch noch im RAM zwischenspeichern,
aber das hilft ja nicht viel ...
Grüße
Bari
Hast du Probleme mit dem Platz im BL-Bereich? Wenn nicht, wirds
komplizierter. Dinge über die nachgedacht werden muss:
- für die Funktionen brauchst du dann Pointer, die auf eine fixe Adresse
im Flash zeigen. Linker muss genau wissen wo er die hinpackt. Verändert
sich die Länge der Funktionen und sind die nahtlos hintereienander
verlinkt, bekommt man Probleme, da sie nicht mehr da sind, wo die fixen
Adressen hinzeigen.
- Kann der Controller gleichzeitig aufs Flash schreiben, während er das
Programm ausführt (gleichzeitig lesender Zugriff)? Manche Controller
verwenden zwei Bänke um genau das zu umgehen oder führen den Code aus
dem RAM aus
- was ist mit den benötigten Interrupt-Vektoren?
Das gibt es sicher noch andere Dinge, die mir gerade nicht einfallen...
FW Update:
- Firmware liegt verschlüsselt auf der SD Karte
- Bootloader liesst blockweise von SD (z.B. 128 Bytes), entschlüsselt,
und ruft eine Funktion auf, die den Block ins Flash schreibt (diese muss
u.U. im RAM liegen)
Flash Algs verwenden idR. eine feste Blockgrösse, welche sich auf den
Flash Vorgang abbildet. Dies könnte auch die Grösse für den Block
(De-)Crypt sein.
Nutzen der Funktionen:
In deinem Bootloader liegt eine Tabelle an immer der gleichen Adresse,
welche Function Pointer auf deine shared functions liegen (ähnlich der
Interrupt Vector Table). Wo dann die Funktionen selbst liegen, was sie
aufrufen und wie gross die sind, ist für den späteren Verlauf egal.
Allerdings sollten sie nicht auf globale Daten zugreifen, wenn deine FW
ein eigenes "startup" hat, da globale Daten im RAM vom Bootloader nach
dem FW start nicht mehr gültig sind (neues ZI / load).
Random .. schrieb:> Nutzen der Funktionen:> In deinem Bootloader liegt eine Tabelle an immer der gleichen Adresse,> welche Function Pointer auf deine shared functions liegen (ähnlich der> Interrupt Vector Table).
Die Tabelle sollte aber nicht im Bootloader Image liegen, sondern in dem
Image, in dem die SD-Karten Funktionen liegen. Wenn das
Applikations-Image und der Bootloader die Start-Adresse (Address der
Tabelle) dieses Images kennen, können die dort die Adressen der
Funktionen nachschlagen.
> Kann man den Code für den SD-Karten Zugriff ebenfalls als eine Art> Image ab einer bestimmten Adresse in den Speicher schreiben> und vom Bootloader von von der FW auszugreifen und nutzen?
Sowas kannst du selbstverstaendlich tun. Allerdings kann diese Section
dann selber nicht mehr bei einem Firmwareupdate geaendert werden. Dann
koennte man sie aber auch direkt in den Bootloader schreiben. Der wird
dann halt recht fett. Dein Hauptprogramm kann natuerlich auch Funktionen
aus dem Bootloader aufrufen damit du dieselben Funktionen nicht mehrmals
im Programm haben musst. Allerdings kannst du dieses Funktionen dann
auch im Rahmen eines Firmwareupdates nicht mehr aendern.
Es waere auch denkbar das der Bootloader ohne Kenntnis des Filesystems
einfach die Karte RAW liesst und nach einer Magickennung sucht und daran
erkennt das hier das File auf der Karte liegt. Damit das klappt muss
aber das File an einem Stueck auf der Karte liegen, also nicht
segmentiert. Das ist machbar aber nicht ganz unproblematisch wenn man
mit Leute auf dem Kenntnislevel von Kunden oder Servicetechnikern zutun
hat.
Olaf
Billy _. schrieb:> - für die Funktionen brauchst du dann Pointer, die auf eine fixe Adresse> im Flash zeigen. Linker muss genau wissen wo er die hinpackt.
Und grade das ist extrem aufwändig beim Gnu LD von AVR-GCC, weil man dan
ein komplexes Linkerskript hacken muss.
In der Praxis hättest Du dann 3 Teile:
- Den SD Kartenzugriff
- die eigentliche Applikation
- den Bootloader
Und die sind dann auch nicht mehr unabhängig voneinander. Blöderweise
will man den SD Zugriff aber manchmal updaten - sei es weil Karten
exotische Fehlerzustände haben oder weil $Kunde SDXC mit ExFAT haben
will.
Und der SD Zugriff dürfte dann auch keine Buildins wie memcpy() aufrufen
- oder müsste eigene Kopien mitbringen. Die RAM Belegung ist dann auch
ein interessantes Problem - die FAT Implementierungen hier haben alle
irgendwelche Globals.
Witzigerweise hat aber grade das Default-Format einer SD(HC) Karte sehr
viel Platz hinter dem Sektor 0 mit der Partitionstabelle - für eine AVR
Firmware würde das locker reichen. Da kommt ein Luser ohne Admin Rechte
unter Windoof nicht mal ran, wäre aber von einem Bootloader leicht
auszulesen.
Olaf schrieb:>> Kann man den Code für den SD-Karten Zugriff ebenfalls als eine Art>> Image ab einer bestimmten Adresse in den Speicher schreiben>> und vom Bootloader von von der FW auszugreifen und nutzen?>> Sowas kannst du selbstverstaendlich tun. Allerdings kann diese Section> dann selber nicht mehr bei einem Firmwareupdate geaendert werden.
Du kannst eine Firmware installieren, die dann den Bootloader oder das
SD-Image aktualisiert.
> Dann> koennte man sie aber auch direkt in den Bootloader schreiben.
Klingt nach einer guten Idee.
Hi zusammen,
ich versuche mal mein Glück...
Werde aber das FAT-Filesystem direkt aus dem Bootloader heraus
unterstützen müssen, da alles auf "Standard-Windows-Weg" funktionieren
sollte.
Das mit dem Verschlüsseln wäre dann evtl. ein nachfolgender Schritt.
Nur ... wenn ich das symmetrische Schlüsselpaar fest kodieren muss, ist
das so gut wie kein Schutz ...
