Hallo, ich habe zwei unterschiedliche USB Geraete (einer auf STM32 und einer auf AVR32 Basis) und wuerde den Endanwendern gerne die Moeglichkeit geben, die Firmware zu aktualisieren. Ich will nicht die Software der Hersteller verwenden sondern habe bereits eine Loesung gefunden um die Firmwaredaten an das USB Geraet zu schicken. Desweiteren sollte vor der Aktualisierung der Hashwert der neuen Firmware durch die bisherige Firmware ueberprueft werden. Nur wenn diese Ueberpruefung erfolgreich ist sollte die Aktualisierung durchgefuehrt werden. Insbesondere stellt sich mir die Frage, ob ich fuer die Aktualisierung also 200% Flash-Speicher benoetige oder ob es platzsparendere Verfahren gibt. Habt Ihr Tipps hierzu oder kennt Ihr beispielhafte Software die ich mir angucken koennte?
Bootloader überprüft den Flash, wenn der Flash falsch programmiert wurde, bleibt der im Bootloader hängen und der Kunde muss erneut programmieren. Natürlich darf der Bootloader sich niemals selbst überschreiben.
Doppelt großer Flash bringt ja nur was, wenn der Bootloader bzw. der Chip an sich eine Logik hat, bei fehlgeschlagenem Boot vom updatebarem Flash das "Golden Image" zu starten. Wird bei aktuellen FPGAs zum Beispiel so gemacht.
Danke fuer das Feedback. Heisst das ich muesste einen eigenen Bootloader schreiben der das Flashen durchfuehrt und den Hash der Firmware ueberprueft? Ein Bootloader der sowas leistet ist mir naemlich von ST bzw. Atmel nicht bekannt. Gibt es entsprechende Quellen oder einen Open Source Bootloader auf denm ich aufsetzen koennte?
Das bringt doch nix. Der Bootloader kann doch den Hash der neuen Firmware gar nicht kennen. Den müsstest du ja auch erst übertragen, und dabei kann´s auch schon zum Fehler kommen. Ich würde die neue Firmware im RAM abspeichern, dann ein Verify machen. Dann die Firmware ins Flash schreiben, nochmal Verify und dann erst Reset. Der Bootloader muss am besten von außen startbar sein, auch wenn trotz aller Maßnahmen doch das neue Image nicht startet, also beispielsweise durch einen Taster beim Booten drücken startet der Bootloader.
Ja, selbst schreiben. Open-Source kenne ich nicht. Ich habe mal einen geschrieben für den STM, der ist aber nicht OpenSource.
Du musst dem Bootloader "nur" verbieten, sich selbst zu überschreiben, sofern das nicht hw-mäßig geht, sowie der Bootloader sollte eine Möglichkeit haben, wie z.B. eine Led, mit welcher er anzeigt, daß er sich im Bootloader- Status befindet. Sollte mit einem Adressvergleich und ein paar and/or machbar sein jeden Bootloader so umzustricken. Um den Bootloader zu updaten musst du eine FW runterflashen,welches nichts anderes macht, als den Bootloader zu überschreiben, natürlich mit entsprechenden Sicherheitscheck. Sollte da was daneben gehen, dann gehen sie meistens nicht mehr. Ist so. Intelligentere Systeme verwenden einen Boot-Jumper, welcher eigentlich fast nie upgedated wird. Dieser prüft die Checksumme des FW sowie hat die FW auch zusätzlich eine Feature-ID. Kann auch nur ein Bit sein. Geht davon hervor daß die FW bootbar ist, dann wird gleich die angesprungen und nicht der Bootloader. Damit vermeidet man auch die Probleme, daß wenn beim Update des Bootloaders Stromausfall oder sonstwas passiert, das Gerät automatisch defekt ist. Kann aber auch sein, daß der Boot-jumper nur die Checksum des Bootloaders überprüft und sofern falsch die Applikation direkt angesprochen wird. Es gibt da mehrere Strategien. Aber Achtung auf die Lizenz. z.B. LGPL welche du statisch linkst, was ja in jedem uC der Fall ist, bist du gezwungend die ganze FW im Source offen zu legen, dazu gibt es einige Gerichtsurteile. Nur Open-Source heist nicht auch verwendbar.
Ich habe vor neue Firmwareimages zu signieren, so dass der Bootloader die Signatur gegen einen hinterlegten Schluessel pruefen kann/soll. Bisher scheint mir daher der Vorschlag von Christian am passensenten zu sein: 1. Die neue Firmwarevim RAM abspeichern 2. Die Signatur der Firmware pruefen 3. Dann die Firmware ins Flash schreiben 4. Evtl. nochmal Verify, wobei ich dies fuer optional halte 5. Reset
Gast
#2411590
Sowas hatte ich vor einigen Jahren mal geschrieben: Beitrag "MMC/SD Bootloader füt ATMega16" In der Firmware wird an eine feste Stelle eine Prüfsumme, ausserdem eine Geräte ID hinterlegt, so dass man nicht die falsche Firmware auf das falsche Gerät flasht. Wenn alles ok ist wird das Hauptprogramm gestartet. Gruß Stefan
> 1. Die neue Firmwarevim RAM abspeichern Da brauchst Du einen µC der mehr RAM als Flash hat. Das findest Du kaum auf dem Markt, Du bräuchtest dafür also extra ein externes RAM. > 2. Die Signatur der Firmware pruefen > 3. Dann die Firmware ins Flash schreiben An der Stelle ist es unsicher: der User schaltet aus, der Strom fällt aus, das Kabel hat Wackelkontakt,... Dann hast Du nur die halbe Firmware im Flash. Ein Bootloader der selbst nie überschrieben wird und in der Lage ist vom User neue Firmware zu empfangen ist da besser. Der kann dann prüfen ob die Firmware im Flash korrekt signiert ist und startet erst dann die richtige Applikation. Ansonsten wartet er nur auf neue Firmware vom User. Gruß, Gerd
Gast
#2411933
Beachten sollte man auch 1. Software egal welche ist nie frei von Fehlern. 2. je complexer ein stück software ist um so mehr fehler sind enthalten. Für den Booter bedeutet das: je weniger funktionen darin enthalten sind umso weniger fehler können sich einschleichen. Minimal variante währe umschalter ob FW1 oder FW2 gestartet werden muss. z.B. an einem valid marker der nach einem erfolgreichen Update gesetazt wird (oder counter um zu ermitteln welche der beiden jetzt die neuere ist). hat den nachteil, der flasch müste in 3 Teile Booter, FW1 und FW2 aufgeteilt werden. wobei der booter hier recht klein ausfällt. Wichtig ist hier, den Update mechanissmuss gründlichst bei jeder FW freigabe zu testen. Ist die defekt, dann hast du jede menge sondermüll mit dem FW Update produziert (oder jede menge arbeit und kosten) Die Grosse Variante Nur ein FW image, Booter enthält Update mechanismus. Hier ist der Booter vor der freigabe gründlichst zu prüfen. wenn der fehler enthält wird es schwierig die wieder im Feld auszubügeln. Wenn hierbei dann noch was schiefgeht, produziert man wieder arbeit und kosten. Wichtig ist beim Update selber, das das was man ins flash schriebt gegengelesen wird, und geprüft wird ob das io ist oder nicht und erst danach der vaildmakrer gesetzt / die fw gestartet wird. Wenn ich schrott empfange, und schrott ins flash schreibe ist das erstmal unschön, nur starten darf ich den schrott nicht! Wie ich die sicherung nun realisiere CRC32 MD5 Signierung oder gar verschlüsselt ist geschmakssache. gruss
Danke fuer das Feedback. Nun habe ich verstanden welche Ansaetze moeglich sind und muss mir ueberlegen welcher fuer mich der richtige ist.
Ich wuerde gerne noch mal diese Diskussion wieder aufmachen: Da ich nun evtl. den Updatemechanismus in den Bootloader schreiben werde wuerde ich gerne wissen, welche Moeglichkeiten es gibt eine neue Firmware vom PC via USB auf das Geraet zu uebertragen. Hierbei wuerde ich gerne vermeiden, dass der Anwender eine geraetespezifische Software (auf PC Seite) oder sogar Geraetetreiber zur Aktualisierung verwenden muss. Gibt es dafuer eine einheitliche USB Schnittstelle bzw. universale Software?
dein Gerät könnte als USB-Massenspeicher erscheinen und registrieren, wenn jemand eine Datei mit dem Update dort hinterlegt.
USB Massenspeicher waere in der Tat eine elegante Moeglichkeit. Allerdings weiss ich nicht ob so ein virtueller Massenspeicher nicht zu komplex waere um es im Bootloader unterzubringen. Ausserdem wuerden die Benutzer immer das Massenspeichergeraet im Computer angezeigt bekommen, obwohl sie es nur in Ausnahmefaellen nutzen wuerden. Welche anderen Moeglichkeiten gibt es?
Das DFU-Protokoll in einem Bootloader. Soweit ich weiss, braucht man für Windows nur die libusb, welche als DLL im Ordner liegt oder statisch gegen die PC-Software gelinkt wird, um per DFU zu kommunizieren. Gibt da z.B. das dfu-util. Wieviel Platz hast du denn für den Bootloader verfügbar?
Wenn das ein STM32 ist, dann hat der als Boot-ROM über USB einen DFU Bootloader* drin. (* Nicht bei allen STM32 Typen) Dazu gibt es "DfuSe_Demo_V3.0.2_Setup.exe" von ST.
Wieviel Platz ich fuer den Bootloader habe? Da habe ich keine harte Grenze, allerdings wuerde ich gerne 1. moeglichst viel Speicher fuer zukuenftige Firmwareversionen zur Verfuegung haben und 2. die Komplexitaet des Bootloaders moeglichst gering halten damit dieser auch wirklich stabil laeuft. Ja, ich verwende STM32 und AT32UC. Ich werde mal gucken ob der Bootloader bei meinem Modell vorinstalliert ist. Danke fuer den Tipp. Hier gibt es ja eine klasse Uebersicht von Bootloadern. http://www.mikrocontroller.net/articles/Bootloader Leider ist keiner fuer STM32 dabei (lediglich ein paar fuer ARM allgemein). Kennt Ihr noch weitere die hier nicht aufgefuehrt sind? Hier habe ich uebrigens die Spec von DFU gefunden, ist auf USB Ebene spezifiziert. http://www.usb.org/developers/devclass_docs/usbdfu10.pdf
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.