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...
Wenn es aber mehrere Funktionen sind ... Die sich ja auch untereinander aufrufen ... ?!?
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 ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.