Hallo, ein Consumer-Elektronik Produkt, hat einen USB-Anschluss. Dieser soll verwendet werden, damit man dort Firmware-Updates rauf spielen kann. Das Gerät erscheint dabei als Mass Storage Device und der Kunde kann ein Firmware installieren, in dem er eine Datei darauf kopiert. Nun muss ich ja wohl so etwas wie ein Dateisystem auf dem Gerät implementieren, damit PCs auf das Gerät zugreifen können. Welches Dateisystem bietet sich da an? Ich habe einen recht alt erscheinenden Wikipedia Artikel gefunden, dem nach würde sich FAT16 oder FAT32 anbieten (Firmware-Updates sind garantiert kleiner als 1MByte). Hat jemand von euch Erfahrung mit so etwas ähnlichem gemacht und kann eine Empfehlung aussprechen? Was gibt es sonst noch so bei der Auswahl zu berücksichtigen (Lizenzkosten etc.)? Schönen Dank für jeden Tipp im Voraus! mfg Torsten
Ich geh mal aus das die Firmware im Flash gespeichet wird, dann solltest du dich nach einem Flash Filesystem umschauen. Oder du überlässt das ganze gleich einen Embedded Profi da du offensichtlich Probleme damit hast, den Anwendungsfall präzise zu formulieren.
Torsten R. schrieb: > Nun muss ich ja wohl so etwas wie ein Dateisystem auf dem Gerät > implementieren, damit PCs auf das Gerät zugreifen können. Welches > Dateisystem bietet sich da an? du könntest auch MTP verwenden https://de.wikipedia.org/wiki/Media_Transfer_Protocol
Welchen Controller benutzt du ? Ist das Produkt hardware-maessig schon fertig ? Wieviel memory gibt es ? Ist da schon einen SD card oder anderes memory inside ?
Torsten R. schrieb: > Ich habe einen recht alt erscheinenden > Wikipedia Artikel gefunden, dem nach würde sich FAT16 oder FAT32 > anbieten (Firmware-Updates sind garantiert kleiner als 1MByte). Das wäre dann FAT12. Die Anzahl der FAT Bits ist abhängig von der Größe des Dateisystems. Gibts übrigens fertich - in Hardware - beim NXP LPC1343. Benutzerfreundlich ist das aber nur für Entwickler. Für End-LUser möchtest Du das in ein fertiges Programm giessen, da wäre dann eine andere (Custom-USB) Schnittstelle IMHO besser geeignet.
:
Bearbeitet durch User
Hallo Patrick, Patrick C. schrieb: > Welchen Controller benutzt du ? > Ist das Produkt hardware-maessig schon fertig ? > Wieviel memory gibt es ? > Ist da schon einen SD card oder anderes memory inside ? Natürlich hat die HW Speicher, in der die Firmware abgespeichert wird. Es ist flash Speicher. Wie würde es die Datei-System-Auswahl ändern, wenn es anderer Speicher wäre? Es ist ein STM32L4, die HW ist schon fertig. Für Firmware stehen ca. 2x400KByte flash im Controller für 2 Versionen der Firmware, zur Verfügung. mfg Torsten
Es gibt ein Filesystem, dh eine Datenstruktur, die fuer die Ansteuerung der USB Drive Schnittstelle erscheinen muss, und es gibt eine Implementation davon. Beide muessen nicht identisch sein. Falls es nur genau ein File sein kann/muss, naemlich die Firmware selbst, kann man das Ganze vereinfachen. Der Bootloader ist ausserhalb und enthaelt diese Drive und Ladefunktionalitaet. Zb ist der freie Platz ohne File der zur Verfuegung stehende Bereich. Und mit dem File ist der freie Platz gleich Null. Und alles andere sind Konstanten. zB ist der Drivename gleich einer Konstanten, plus die Seriennummer des Geraetes.
:
Bearbeitet durch User
Oh D. schrieb: > Es gibt ein Filesystem, dh eine Datenstruktur, die fuer die Ansteuerung > der USB Drive Schnittstelle erscheinen muss, und es gibt eine > Implementation davon. Beide muessen nicht identisch sein. Ja, richtig. Aber welches Filesystem würdest Du wählen? Bis jetzt habe ich zur Auswahl: FAT16, FAT32, MTP und mir fehlen noch ein wenig die Kriterien, um mich für eines zu entscheiden. Das bedeutet, ich muss mich jetzt in alle einlesen und ich kann keine von Vorhinein ausschließen :-(
Jim M. schrieb: > Das wäre dann FAT12. Die Anzahl der FAT Bits ist abhängig von der Größe > des Dateisystems. wie sähe es mit der Unterstützung von "üblichen" Betriebssystemen aus (z.B. Windows, Linux, OS/X). > Benutzerfreundlich ist das aber nur für Entwickler. Für End-LUser > möchtest Du das in ein fertiges Programm giessen, da wäre dann eine > andere (Custom-USB) Schnittstelle IMHO besser geeignet. Entwicklungskosten spielen auch eine Rolle. Es ist auch nicht der einzige Update-Pfad, den das Gerät kennt (es gibt noch BLE). Also: FAT12, FAT16, FAT32 oder MTP, puh wird nicht einfacher ;-)
MTP hat den Vorteil, das der Host das "Dateisystem" nicht kaputt machen kann. Es ist in dem sinne auch kein Dateisystem sondern eine API zum Datenaustausch. Bei Dateisystemem hast du das Problem, das Host und µC nicht gleichzeitig darauf zugreifen können.
Peter II schrieb: > MTP hat den Vorteil, das der Host das "Dateisystem" nicht kaputt machen > kann. Es ist in dem sinne auch kein Dateisystem sondern eine API zum > Datenaustausch. > > Bei Dateisystemem hast du das Problem, das Host und µC nicht > gleichzeitig darauf zugreifen können. Danke Peter! Ich lese mir gerade die Spec durch und versuche heraus zu bekommen, wie der Support von MTP bei Linux und OS/X aussieht. Für meinen Kunden wird aber auf jeden Fall die leichte Bedienung (Explorer öffnen, herunter geladene Datei auf Gerät ziehen, fertig) im Vordergrund stehen. Kaput machen wäre nicht so problematisch, da Platz für 2 Firmwaren vorgesehen sind und der Bootloader vor Start der Firmware einen Checksummen-Test über die Firmware macht. Problematischer könnte sein (und hier muss ich mich entschuldigen, dass ich das Detail ausgelassen habe), dass ich nicht zulassen möchte, dass man die Firmware auch vom Gerät herunter laden kann (das sie verschlüsselt und ggf. komprimiert ist; dann müsste ich sie entsprechend wieder verschlüsseln und komprimieren). mfg Torsten
Torsten R. schrieb: > Also: FAT12, FAT16, FAT32 oder MTP, puh wird nicht einfacher ;-) Welche FAT-Variante zu wählen ist, hat mit der Gesamtgröße des ansprechbaren Speichers zu tun. Daß Deine Firmwareupdates unter 1 MB groß sind, sagt noch nichts über die Gesamtgröße des mit dem Dateisystem ansprechbaren Speichers aus. Es ist aber anzunehmen, daß das weniger als 2 GB sein werden, also ist FAT32 'raus. FAT12 kann bis zu 30 MB Dateisystemgröße verwendet werden, darüber ist FAT16 erforderlich. MTP ist kein Dateisystem, sondern ein anderes USB-Protokoll als MSD. Das setzt also an einer anderen Stelle an.
Torsten R. schrieb: > Problematischer könnte sein (und hier muss ich mich entschuldigen, dass > ich das Detail ausgelassen habe), dass ich nicht zulassen möchte, dass > man die Firmware auch vom Gerät herunter laden kann (das sie > verschlüsselt und ggf. komprimiert ist; dann müsste ich sie entsprechend > wieder verschlüsseln und komprimieren). soweit ich MTP verstanden haben, könntest du einfach verhindern das die Datei vom PC geladen wird.
Peter II schrieb: > soweit ich MTP verstanden haben, könntest du einfach verhindern das die > Datei vom PC geladen wird. Ja, ich würde das auch eher als Argument für MTP sehen. Wenn ich das richtig sehe, hat OS/X aber schon mal keinen nativen Support für MTP.
Rufus Τ. F. schrieb: > FAT12 kann bis zu 30 MB Dateisystemgröße verwendet werden, darüber ist > FAT16 erforderlich. Dann würde FAT12 ganz locker reichen. Ich hab nur etwas Angst, dass das wiederum keinen großen Support bei den OS-Herstellern hat. In einem anderen Teil des Internets habe ich gelesen, dass FAT32 das verbreitetste Format sein soll.
Torsten R. schrieb: > Ich hab nur etwas Angst, dass das wiederum keinen großen Support bei den > OS-Herstellern hat. Die brauchst Du nicht haben, das kann jedes OS, das FAT unterstützt. Denn jedes OS kann Disketten lesen (auch wenn praktisch kein PC mehr Diskettenlaufwerke enthält, lassen sich die als USB-Gerät anschließen), und aufgrund der lächerlichen Kapazität werden Disketten mit FAT12 formatiert. Sei also unbesorgt.
:
Bearbeitet durch User
Falls du dich für MTP statt Mass Storage Device entscheidest könnte ich dir eine MTP Device Library für den STM32 von mir anbieten. Ich wollte die schon länger mal unter einer Open Source Lizenz veröffentlichen, bin aber bisher noch nicht dazu gekommen. Bisher sind mir auch keine Open Source Libraries für MTP Devices für Mikrocontroller bekannt (die von Android zähle ich mal nicht, weil ich nicht weiß wie gut sich das für Mikrocontroller eignet). Falls interesse besteht schicke mir eine PM.
Sebastian V. schrieb: > Falls du dich für MTP statt Mass Storage Device entscheidest könnte ich > dir eine MTP Device Library für den STM32 von mir anbieten. Hi Sebastian, wenn ich mich für MTP entscheide, hätte ich natürlich sehr viel Interesse an Deiner Library. Hast Du Erfahrung gemacht, wie weit MTP von nicht-MS Betriebssystem so unterstützt wird? mfg Torsten
Torsten R. schrieb: > Kaput machen wäre nicht so problematisch, da Platz für 2 Firmwaren > vorgesehen sind und der Bootloader vor Start der Firmware einen > Checksummen-Test über die Firmware macht. Es geht nicht um die Beschädigung einzelner Dateien, sondern des gesamten Dateisystems. Bei dem zugrundeliegenden MSD (mass storage device) kann das Gerät eigentlich auch nicht wissen, wann ein Dateizugriff des Hosts abgeschlossen ist, da es auf der Abstraktionsebene von Blockgeräten keine Dateien gibt, sondern eben nur feste Speicherblöcke. Sofern das Dateisystem nicht auch noch für andere Zwecke verwendet wird, sollte es sinnvollerweise beim Systemstart des Gerätes neu formatiert werden. Alternativ kann es auch komplett virtuell sein, d.h. nicht bzw. nicht vollständig mit Speicher hinterlegt. Allerdings mag es da von Hostbetriebssystem zu Hostbetriebssystem unterschiedliche Ausprägungen der Blockzugriffe geben, d.h. Eintragen der Speichernutzung in der FAT, usw.. Sofern es für den Kunden praktikabel ist, kann man auch vorsehen, dass das Gerät nur beim Systemstart nachschaut, ob ein Firmware-Update in dem Dateisystem abgelegt wurde. Dieses wird dann installiert. Wenn man bei jedem Systemstart zunächst den Speicher löscht und dann das Dateisystem neu formatiert, sollten auch keine Rückstände des Update-Datei mehr auslesbar sein. > Problematischer könnte sein (und hier muss ich mich entschuldigen, dass > ich das Detail ausgelassen habe), dass ich nicht zulassen möchte, dass > man die Firmware auch vom Gerät herunter laden kann (das sie > verschlüsselt und ggf. komprimiert ist; dann müsste ich sie entsprechend > wieder verschlüsseln und komprimieren). Eine Verschlüsselung der Firmware ist kein Schutz gegen Mehrfachnutzung oder Manipulation, denn ein Angreifer kann den Schlüssel für die Entschlüsselung ggf. aus einem vorhandenen System auslesen. Wesentlich wichtiger ist eine kryptografische Signatur, denn der für die Signaturprüfung erforderliche öffentliche Schlüssel nützt ihm gar nichts, da er zum Erstellen gefälschter Firmware den nicht zugänglichen geheimen Schlüssel benötigt. In solch ein Konzept lassen sich auch sehr gut Seriennummernlisten von Geräten einbinden, auf denen ein bestimmtes Firmwareupdate installiert werden darf.
Unter Linux läuft MTP mit den entsprechenden Paketen ebenfalls. Bisher bin ich mit der gvfs (Gnome Virtual File System) Unterstützung von MTP recht zufrieden. Allerdings haben etwas ältere Distributionen diese Pakete möglicherweise noch nicht im Repository. Bei Ubuntu gibts das wohl erst seit 13.10 standardmäßig. Etwas nervig war unter Linux die VID/PID Erkennung der USB Geräte. Die libmtp Library hat eine Liste mit allen bekannten MTP Geräten und wenn das eigene Gerät dort nicht auftaucht wird es manchmal nicht erfolgreich erkannt. Theoretisch sollte es zwar doch erkannt werden (nach meinem Verständnis vom libmtp Code), in der Praxis gab es da aber manchmal Probleme. Das müsste ich mir nochmal genauer anschauen. Zu OS X kann ich nichts sagen.
Ach so, bei FAT solche man sich auch noch darüber informieren, welche Version wo patentiert oder mit anderen relevanten Schutzrechten belastet ist. Hinsichtlich der Gültigkeit und Anwendbarkeit der entsprechenden Microsoft-Patente gibt es sehr unterschiedliche Gerichtsentscheidungen. Wenn man auf Nummer Sicher gehen will, nimmt man das gut abgehangene FAT-12. Man beachte, dass es bei den o.a. Patenten nicht primär darum geht, mit seinem Nischenprodukt selbst von MS verklagt zu werden, sondern darum, dass die "Mainstream"-Betriebssystemhersteller dies befürchten müssen und daher entsprechend problematische Dateisysteme gar nicht erst unterstützen, wie z.B. eFAT.
Andreas S. schrieb: > Bei dem zugrundeliegenden MSD (mass storage device) kann das Gerät > eigentlich auch nicht wissen, wann ein Dateizugriff des Hosts > abgeschlossen ist, Hier ist ein probates Mittel das Erkennen des Trennens des USB-Gerätes vom Host. Erst wenn das erfolgt ist, greift das Gerät "unter eigenem Dampf" auf das Dateisystem zu und wertet aus, was der geneigte Nutzer dort hinterlegt hat.
Hallo Andreas, Andreas S. schrieb: > Sofern das Dateisystem nicht auch noch für andere Zwecke verwendet wird, > sollte es sinnvollerweise beim Systemstart des Gerätes neu formatiert > werden. Ich hatte eigentlich auch überhaupt nicht vor, die Verwaltungsstrukturen des Dateisystems wirklich im Flash abzulegen, sondern vielmehr das sich durch ein bestimmtes Dateisystem, implizit ergebene Protokoll zu implementieren. Der Host schreibt eine komprimierte und verschlüsselte Datei auf das "USB-Device" -> Im Flash Speicher landet ein Header gefolgt von der unkomprimierten, unverschlüsselten Firmware. > Alternativ kann es auch komplett virtuell sein, d.h. nicht bzw. > nicht vollständig mit Speicher hinterlegt. Allerdings mag es da von > Hostbetriebssystem zu Hostbetriebssystem unterschiedliche Ausprägungen > der Blockzugriffe geben, d.h. Eintragen der Speichernutzung in der FAT, > usw.. Das deckt sich glaube ich, mit meiner Vorstellung, wenn ich Dich richtig verstehe. Welche Probleme siehst Du? Dass z.B. ein Host die Datei in umgekehrter Reihenfolge schreibt, oder Blöcke nach einem irgend wie schrägen Schema belegt? > Eine Verschlüsselung der Firmware ist kein Schutz gegen Mehrfachnutzung > oder Manipulation, denn ein Angreifer kann den Schlüssel für die > Entschlüsselung ggf. aus einem vorhandenen System auslesen. Der Schlüssel steckt im Bootloader und da müssen wir uns darauf verlassen, dass die HW-Schutzmechanismen von ST greifen. Der Kunde möchte damit vor allem das Kopieren der Geräte verhindern. mfg Torsten
Torsten R. schrieb: > Für meinen Kunden wird aber auf jeden Fall die leichte Bedienung > (Explorer öffnen, herunter geladene Datei auf Gerät ziehen, fertig) im > Vordergrund stehen. Dann bleibt dir in der Tat nur die Wahl, entweder MSD (mass storage device) oder MTP (media transfer protocol) zu implementieren. Und bei MSD hast du anschließend noch die Qual der Wahl, welches Filesystem auf dem exportierten Speicherblock drauf sein soll. Als kleinster gemeinsamer Nenner bleibt da wohl nur FAT. > Kaput machen wäre nicht so problematisch, da Platz für 2 Firmwaren > vorgesehen sind und der Bootloader vor Start der Firmware einen > Checksummen-Test über die Firmware macht. Das ist nicht der Punkt. MSD stellt dem Host ein Stück Speicher zur Verfügung, das er blockweise lesen oder schreiben kann. Im Prinzip genau wie eine Diskette. Was der Host dann damit macht ist allein seine Sache. Der Host kann z.B. ein Firmware-Image einfach so auf das Blickdevice schreiben (unter Linux mit Bordmitteln: dd if=firmware.bin of=/dev/sdx). Der Host kann das Blockdevice partitionieren (vulgo: eine Partitions- tabelle drauf schreiben) und dann die Partitionen als Filesysteme ansprechen. Der Host kann Filesysteme neu erzeugen. Und wenn der Host ein Filesystem (selber erzeugt oder vorgefunden) mounted, dann kann er da Files ablegen oder lesen. Was dir vorschwebt ist: der Host findet ein Filesystem (z.B. FAT16) vor und mounted es. Dann schreibt er genau ein File da drauf und unmounted das Filesystem. Dann liest dein Controller das File und wenn es die üblichen Tests besteht, wird es in den Firmware-Bereich des Flashs gebrannt. Nur: der Anwender muß sich da nicht dran halten. Und deswegen mußt du überlegen, was du dagegen tust. Was machst du z.B. wenn du keinen gültigen FAT16 Header vorfindest? (um mal bei der Annahme zu bleiben daß du dich für FAT16 entscheidest). Was machst du wenn das Filesystem inkonsistent ist? Was machst du mit Files, die kaputt sind? Was wenn da zwei gültige Firmware-Images drauf sind? Torsten R. schrieb: > Ich hatte eigentlich auch überhaupt nicht vor, die Verwaltungsstrukturen > des Dateisystems wirklich im Flash abzulegen, sondern vielmehr das sich > durch ein bestimmtes Dateisystem, implizit ergebene Protokoll zu > implementieren. Das kannst du ganz schnell vergessen. Das funktioniert nicht. Jeder Host kann (und wird) das gleiche Filesystem anders ansprechen. Z.B. was die Reihenfolge der Schreibzugriffe angeht (Daten zuerst oder FAT zuerst? FAT und Daten immer im Wechsel oder FAT nur einmal im Block? etc. pp.). Deine einzige Chance ist, den Host das Blockdevice nach Gutdünken verwursten zu lassen und darauf zu hoffen, daß am Ende ein konsistentes Filesystem da drin ist. Deswegen braucht dein µC auch eine besonders stabile und fehlertolerante Implementierung des verwendeten Filesystems.
Torsten R. schrieb: > Das deckt sich glaube ich, mit meiner Vorstellung, wenn ich Dich richtig > verstehe. Welche Probleme siehst Du? Dass z.B. ein Host die Datei in > umgekehrter Reihenfolge schreibt, oder Blöcke nach einem irgend wie > schrägen Schema belegt? Genau. Die Reihenfolge der logischen Blöcke ergibt sich dann aus den FAT-Einträgen. Das Gerät muss auf jeden Fall auch das Lesen der FAT ermöglichen, damit der Host vorher und hinterher (und mittendrin) nachschauen kann, wie der "Datenträger" heißt, wie viel Platz noch verfügbar ist und was sich schon darauf befindet. Ansonsten kann es ggf. mehr oder minder subtile Fehler auf der Hostseite geben. Die Einstellung, ob Schreibzugriffe gecacht werden dürfen, sollte sich in Form des removable-Flags in den USB-Deskriptoren befinden.
Wie man aus so einer einfachen Frage so eine Wissenschaft machen kann, ist mir unerklärlich. Bei Manchen hat man das Gefühl, daß sie einfach nur mit ihrem (unnützen) Wissen kokettieren wollen. Die Antwort ist doch wirklich ganz einfach: FATxx Das wird von JEDEM Betriebssystem unterstützt, ist einfach selbst zu implementieren , und ob man FAT12, -16 oder -32 wählt wird durch die Speicher-Grösse bestimmt (wobei grösser immer geht, aber eben mehr Platz für die Verwaltungsinformationen benötigt)
Hallo Axel, Axel S. schrieb: > Was dir vorschwebt ist: der Host findet ein Filesystem (z.B. FAT16) vor > und mounted es. Dann schreibt er genau ein File da drauf und unmounted > das Filesystem. Dann liest dein Controller das File und wenn es die > üblichen Tests besteht, wird es in den Firmware-Bereich des Flashs > gebrannt. so wird es leider nicht funktionieren, dafür hat der Controller zu wenig Speicher. Entweder ich schaffe es zumindest große Teile der Firmware direkt ins Firmware-Flash zu schreiben (ich kann ja noch fast das gesamte RAM des devices benutzen), oder ich kann das nicht umsetzen. Verschlüsselt ist die FW mit AES in CBC betrieben, dass würde schon mal bedeuten, dass der erste CBC block nicht entschlüsselbar ist, bis der vorherige FAT Block geschrieben wurde. > Nur: der Anwender muß sich da nicht dran halten. Und deswegen mußt du > überlegen, was du dagegen tust. Was machst du z.B. wenn du keinen > gültigen FAT16 Header vorfindest? (um mal bei der Annahme zu bleiben daß > du dich für FAT16 entscheidest). Was machst du wenn das Filesystem > inkonsistent ist? Was machst du mit Files, die kaputt sind? Was wenn da > zwei gültige Firmware-Images drauf sind? Dann wird die alte Firmware verwendet und der Update-Versuch als gescheiter angesehen. mfg Torsten
Hallo Harry, Harry L. schrieb: > Die Antwort ist doch wirklich ganz einfach: FATxx > > Das wird von JEDEM Betriebssystem unterstützt, ist einfach selbst zu > implementieren , und ob man FAT12, -16 oder -32 wählt wird durch die > Speicher-Grösse bestimmt (wobei grösser immer geht, aber eben mehr Platz > für die Verwaltungsinformationen benötigt) na, dass ist doch mal ein Wort ;-) mfg Torsten
Harry L. schrieb: > Bei Manchen hat man das Gefühl, daß sie einfach nur mit ihrem (unnützen) > Wissen kokettieren wollen. wenn es nach dir geht, hätte man wohl nie Luftbereifung erfunden. Dann Holzwagenräder habe auch viel Jahre funktioniert und Ersatzteile konnte man überall finden.
Harry L. schrieb: > > Die Antwort ist doch wirklich ganz einfach: FATxx Nein, so einfach ist das (leider) nicht. Z.B. ist FAT nicht offen sondern von diversen Patenten und ähnlichen Schutzrechten geplagt. In wie weit die Schutzgelder berechtigt sind, die die üblichen Verdächtigen (z.B. Google für Android) an Microsoft zahlen, darüber kommen Gerichte weltweit immer mal wieder zu ganz gegensätzlichen Urteilen. Auf jeden Fall ist das ein Minenfeld und man tut durchaus gut daran, sich vorher zu überlegen, ob man da reinspazieren will. > Das wird von JEDEM Betriebssystem unterstützt, ist einfach selbst zu > implementieren Die meisten frei verfügbaren FAT Implementierungen dürften nicht ansatzweise robust genug für den geplanten Anwendungsfall sein. Man würde mindestens das Äquivalent von CHKDSK haben wollen bevor man versucht, mit dem µC Daten von so einem Filesystem zu lesen.
Axel S. schrieb: > Die meisten frei verfügbaren FAT Implementierungen dürften nicht > ansatzweise robust genug für den geplanten Anwendungsfall sein. Man > würde mindestens das Äquivalent von CHKDSK haben wollen bevor man > versucht, mit dem µC Daten von so einem Filesystem zu lesen. naja, man kann es auch übertreiben, eine einfache CRC32 (oder zur not md5/SHA512) sollte man eh über die Firmware machen. Damit sind schon alles Fehler im Dateisystem ausgeschlossen.
Peter II schrieb: > naja, man kann es auch übertreiben, eine einfache CRC32 (oder zur not > md5/SHA512) sollte man eh über die Firmware machen. Damit sind schon > alles Fehler im Dateisystem ausgeschlossen. Ja, ein CRC32 ist in der Datei vorhanden und liegt auch später im Flash und wird auch noch vom Bootloader vor Start geprüft.
Axel S. schrieb: > Nein, so einfach ist das (leider) nicht. Z.B. ist FAT nicht offen > sondern von diversen Patenten und ähnlichen Schutzrechten geplagt. Das Problem existiert für exFAT, aber nicht für FATx Axel S. schrieb: > Die meisten frei verfügbaren FAT Implementierungen dürften nicht > ansatzweise robust genug für den geplanten Anwendungsfall sein. Jaja...mit Kanonen auf Spatzen schiessen... Es geht um EINE Datei mit einer neuen Firmware, die selten geschrieben wird, und die man auch problemlos mit einer Prüfsumme (notfalls in einer weiteren Datei) auf Integrität prüfen kann. Sollte das FS im Zielssystem wirklich korrumpiert werden, wird es einfach neu formatiert, und gut ist. Man kann sich auch die Schuhe hydraulisch zu machen......
Torsten R. schrieb: > Axel S. schrieb: >> Was dir vorschwebt ist: der Host findet ein Filesystem (z.B. FAT16) vor >> und mounted es. Dann schreibt er genau ein File da drauf und unmounted >> das Filesystem. Dann liest dein Controller das File und wenn es die >> üblichen Tests besteht, wird es in den Firmware-Bereich des Flashs >> gebrannt. > so wird es leider nicht funktionieren, dafür hat der Controller zu wenig > Speicher. Aber genau so funktioniert es. Die Firmware wird in kleinen Blöcken von dem Filesystem gelesen, entschlüsselt, und ins Flash des Controllers geschrieben. Anders gehts mit wenig RAM nicht. In meinem Fall laufen auch die Flash Routinen selbst im RAM, da das für den Flash Vorgang notwendig ist.
Torsten R. schrieb: > Axel S. schrieb: >> Was dir vorschwebt ist: der Host findet ein Filesystem (z.B. FAT16) vor >> und mounted es. Dann schreibt er genau ein File da drauf und unmounted >> das Filesystem. Dann liest dein Controller das File und wenn es die >> üblichen Tests besteht, wird es in den Firmware-Bereich des Flashs >> gebrannt. > > so wird es leider nicht funktionieren, dafür hat der Controller zu wenig > Speicher. Entweder ich schaffe es zumindest große Teile der Firmware > direkt ins Firmware-Flash zu schreiben (ich kann ja noch fast das > gesamte RAM des devices benutzen), oder ich kann das nicht umsetzen. Das verstehe ich nicht. Der Overhead von FAT ist vergleichsweise gering. Der von dir als MSD exportierte Teil des Flash muß ja nur geringfügig größer sein als das Firmware-File selber. Wenn du soviel Platz nicht hast, dann kannst du die ganze Sache vergessen. Allerdings spricht ja erstmal nichts dagegen, den exportierten Speicherbereich ganz oder teilweise auf µC-RAM zu mappen. Für den Host ist das transparent. > Verschlüsselt ist die FW mit AES in CBC betrieben, dass würde schon mal > bedeuten, dass der erste CBC block nicht entschlüsselbar ist, bis der > vorherige FAT Block geschrieben wurde. Das ist blöd. Denn es gibt keine Garantie, daß der Host die Blöcke in der von dir gewünschten logischen Reihenfolge schreibt. Praktisch wird er das vermutlich tun, aber du hast eben keine Garantie dafür. Am Ende bleibt dir nichts, als den Host erst das komplette Image schreiben zu lassen, bevor du darauf zugreifst. Eine entschlüsselte Kopie brauchst du ja nicht vorzuhalten. Du kannst einmal blockweise entschlüsseln (im RAM) um das Image zu prüfen. Und wenn die Prüfung erfolgreich war, noch ein zweites Mal und diesmal blockweise ins Flash schreiben. >> Was machst du z.B. wenn du keinen >> gültigen FAT16 Header vorfindest? (um mal bei der Annahme zu bleiben daß >> du dich für FAT16 entscheidest). Was machst du wenn das Filesystem >> inkonsistent ist? Was machst du mit Files, die kaputt sind? Was wenn da >> zwei gültige Firmware-Images drauf sind? > > Dann wird die alte Firmware verwendet und der Update-Versuch als > gescheiter angesehen. Und es gehen nie wieder Updates per MSD? Eine geeignete Strategie wurde weiter oben schon genannt: der µC sollte das Filesystem immer dann selber neu anlegen, wenn er entweder a) ein Firmware-Image gefunden und verwurstet hat oder b) irgendein logischer Fehler beim Zugriff auf das Filesystem auftritt Und natürlich sollte er im Sinn der Ergonomie den Anwender jeweils davon benachrichtigen. Genauer gesagt sollte der µC nur zwei Zustände des Filesystems akzeptieren: den jungfräulichen Zustand in dem er selber das Filesystem hinterläßt. Und den Zustand wo der Anwender genau ein gültiges Firmware- Image draufgespielt hat.
:
Bearbeitet durch User
Torsten R. schrieb: > so wird es leider nicht funktionieren, dafür hat der Controller zu wenig > Speicher. Entweder ich schaffe es zumindest große Teile der Firmware > direkt ins Firmware-Flash zu schreiben dann vergiss es. Wenn du vorher nicht die komplette Firmware mit der Prüfsumme vergleichen kannst, kannst du ja nicht garantieren das der Rest stimmt. Du brauchst zwingend den Platz im das File komplett im µC zu haben. Als alternative muss du ein PC-Tool schreiben, was die Firmware updatet. Dazu braucht der µC noch ein Bootloader das er auch bei defekter Firmware noch neue Firmware empfangen kann.
Axel S. schrieb: > Torsten R. schrieb: >> Dann wird die alte Firmware verwendet und der Update-Versuch als >> gescheiter angesehen. > > Und es gehen nie wieder Updates per MSD? Ich glaube wir reden hier zum Teil sehr kräftig an einander vorbei. Ich habe nicht vor, ein Dateisystem persistent auf dem Controller zu halten. Wenn ein Upload Versuch gescheitert ist, dann wird jeder nächste, lesende Zugriff auf das "Medium" so aussehen, als wäre das Medium wieder leer.
Harry L. schrieb: > Axel S. schrieb: >> Nein, so einfach ist das (leider) nicht. Z.B. ist FAT nicht offen >> sondern von diversen Patenten und ähnlichen Schutzrechten geplagt. > > Das Problem existiert für exFAT, aber nicht für FATx Und (wenn man Microsoft glaubt) für lange Dateinamen auch bei FAT. ("Firmware" hat 8 Zeichen. :-)
Harry L. schrieb: > Axel S. schrieb: >> Nein, so einfach ist das (leider) nicht. Z.B. ist FAT nicht offen >> sondern von diversen Patenten und ähnlichen Schutzrechten geplagt. > > Das Problem existiert für exFAT, aber nicht für FATx Das sieht schon Wikipedia anders: https://en.wikipedia.org/wiki/File_Allocation_Table#Patents und denen glaube ich mehr als dir >> Die meisten frei verfügbaren FAT Implementierungen dürften nicht >> ansatzweise robust genug für den geplanten Anwendungsfall sein. > > Jaja...mit Kanonen auf Spatzen schiessen... > Es geht um EINE Datei mit einer neuen Firmware, die selten geschrieben > wird, und die man auch problemlos mit einer Prüfsumme (notfalls in einer > weiteren Datei) auf Integrität prüfen kann. Wenn man keine Ahnung hat ... https://blog.fefe.de/?ts=a9f560e2 ff TL;DR: ein Filesystem ist ein Einfallstor. Ein bösartiger Host kann da allen möglichen Mist drauflegen und deinen µC z.B. dazu bringen, interne Datenstrukturen offen zu legen. Ein solcherart genutztes Filesystem muß Verwaltungsstrukturen (z.B. Blocknummern bei FAT) auf Validität prüfen bevor es sie verwendet.
> Ich hatte eigentlich auch überhaupt nicht vor, die Verwaltungsstrukturen > des Dateisystems wirklich im Flash abzulegen, sondern vielmehr das sich > durch ein bestimmtes Dateisystem, implizit ergebene Protokoll zu > implementieren. Gut, dann blicken wir mal kurz zurück in der Geschichte, auf Zeiten und (Peripherie-)Geräte bei denen es ausser Frage war ein Dateisystem zwecks FW-Update zu implementieren. Ich spreche da z.B. von Analogmodems, Seriell ans den Host angeschlossen. Hier war es z.B. üblich diese per AT-Kommando in den FW-Update-Empfangsmodus zu versetzen und anschliessend die FW-Binärdatei per X-Modem-Protokoll "gesichert" zu übertragen. Ob das Peripheriegerät die Datei nun erst im RAM aufnahm um auf Plausibilität zu prüfen oder "direkt ins FLASH-ROM streamte" bleibt Sache des Geräteentwicklers - jedenfalls dem Anwender/Updater verborgen. Auf die Anfrage hier umgelegt: Was spricht dagegen dass sich das USB-Peripheriegerät als CDC (Serielleschnittstelle) Präsentiert? Der Host kann so "runterschreiben" wie ihm lustig ist: was im Header des Datenstroms nicht dem entspricht was das Gerät aufnehmen DARF landet im Orkus - der Datenstrom der per Header qualifiziert gültig erscheint wir aufgenommen (on-the-fly entschlüsselt) und (via RAM oder auch nicht) schlussendlich im FLASH-ROM abgelegt. Leseaufforderungen an das USB-Peripheriegerät können nach belieben gar nicht, mit einer statischen "Hello, world!" Nachricht/Datei oder mit einer dynamischen Statusnachricht (Betriebszustand, FW-Version(en), Seriennummer, ...) beantwortet werden. Wird der Header des (Datei-)Transfers clever ausgelegt, kann das FW-empfangende Gerät zw. verschiedenen Dateien/Zwecke unterscheiden: FW, Bootloader, Konfigurationsdaten, neusetzen v. Decryptions-Keys, usw. Die Cleverness in dieser Headerdeutung dient als vereinfachter Ersatz des Dateisystems, ohne die in obigen Post angedeuteten Vielfalt der Blockorientieren wahlfreien Zugriffe. Voraussetzung auf der Hostseite: ein Beliebiges Kommunikationsprogramm welches serielle Ports bedienen kann UND z.B. X-Modem beherrscht. Solches gibt's für etablierte OS wie Sand am Meer zur auswahl.
Peter II schrieb: > dann vergiss es. Wenn du vorher nicht die komplette Firmware mit der > Prüfsumme vergleichen kannst, kannst du ja nicht garantieren das der > Rest stimmt. Du brauchst zwingend den Platz im das File komplett im µC > zu haben. Der controller hat Patz für 2 Bootloader und 2 Firmwaren. Bei einem Update wird immer die gerade nicht aktuelle Firmware aktualisiert. Bei der Strategie, zuerst einmal eine komplette Datei in einem Filesystem abzulegen um es dann von dort aus in einen Firmware-Bereich zu kopieren, würde der doppelte Speicherbereich nötig sein. Ich liebäugle jetzt damit, den Host die Datei auf das Device schreiben zu lassen und dabei nur die Daten ins Flash zu schreiben und die Verwaltungsdaten im RAM zu halten. Sollte der Host die Daten "in order" schreiben, dann könnte ich bereits beim Schreiben der Daten mit Entschlüsseln und CRC berechnen anfangen (das wäre aber eine Optimierung, für die wahrscheinlich eh keine Zeit ist). Wenn nicht, muss ich bis später warten und am "Ende" die Firmware auspacken und prüfen. Ich habe die FAT Spec noch nicht komplett durch, aber das erscheint mir machbar. mfg Torsten
Torsten R. schrieb: > Ich liebäugle jetzt damit, den Host die Datei auf das Device schreiben > zu lassen und dabei nur die Daten ins Flash zu schreiben und die > Verwaltungsdaten im RAM zu halten. Sollte der Host die Daten "in order" > schreiben, dann könnte ich bereits beim Schreiben der Daten mit > Entschlüsseln und CRC berechnen anfangen (das wäre aber eine > Optimierung, für die wahrscheinlich eh keine Zeit ist). Wenn nicht, muss > ich bis später warten und am "Ende" die Firmware auspacken und prüfen. > > Ich habe die FAT Spec noch nicht komplett durch, aber das erscheint mir > machbar. das halte für einen bösen Hack. Jedes Betriebssystem oder Kopierprogramm kann sich in jeder Version anders verhalten.
FAT - Für Andere Technologien! schrieb: > Voraussetzung auf der Hostseite: ein Beliebiges Kommunikationsprogramm > welches serielle Ports bedienen kann UND z.B. X-Modem beherrscht. > Solches gibt's für etablierte OS wie Sand am Meer zur auswahl. Ja, das würde mir auch besser gefallen (dann wäre ich jetzt schon längst fertig damit). Aber, spätestens wenn ich die Anleitung für den Firmware-Update dem Kunden zeige, sagt er mir (zu recht), dass er es doch lieber mit dem Drag'n Drop haben möchte ;-) Oder wie einer meiner Professoren immer sagte: "Don't argue with the customer!"
Peter II schrieb: > das halte für einen bösen Hack. Jedes Betriebssystem oder Kopierprogramm > kann sich in jeder Version anders verhalten. Den verstehe ich jetzt nicht. Ich würde dabei jede Permutation möglicher Zugriffe auf die "Sectoren" unterstützen.
Axel S. schrieb: > TL;DR: ein Filesystem ist ein Einfallstor. Ein bösartiger Host kann da > allen möglichen Mist drauflegen und deinen µC z.B. dazu bringen, interne > Datenstrukturen offen zu legen. Ein solcherart genutztes Filesystem muß > Verwaltungsstrukturen (z.B. Blocknummern bei FAT) auf Validität prüfen > bevor es sie verwendet. Ja, aber da würde ich jetzt auch nicht zu viel drauf legen. Das gilt schließlich für jede Form von Kommunikation mit der Aussenwelt. Da muss man drauf achten, aber das kann man fehlerfrei hin bekommen.
Torsten R. schrieb: > Den verstehe ich jetzt nicht. Ich würde dabei jede Permutation möglicher > Zugriffe auf die "Sectoren" unterstützen. Und dafür machst du auch eine QS? Also von Win95 bis Suse 4.1 und MacOS? Bei Linux wird alles beim umount geschrieben, in welcher Reihenfolge die FAT und die Daten geschrieben werden steht vermutlich nirgends geschrieben.
Wie wäre es mit DFU (Device For Update) wo ST auch eine Demo hat mit Software (zumindest für den F103 weiß ich es)? Man beschreibt dort direkt den Flash speicher in Blöcken, das kann der Interne oder auch Externer sein. AN3156 - http://www.st.com/content/ccc/resource/technical/document/application_note/6a/17/92/02/58/98/45/0c/CD00264379.pdf/files/CD00264379.pdf/jcr:content/translations/en.CD00264379.pdf Der Treiber von denen ist beim Windowsupdate mit drinnen.
Peter II schrieb: > Torsten R. schrieb: >> Den verstehe ich jetzt nicht. Ich würde dabei jede Permutation möglicher >> Zugriffe auf die "Sectoren" unterstützen. > > Und dafür machst du auch eine QS? Jep, die üblichen Unit Tests, bei denen dann ggf. sogar in "zufälliger" Reihenfolge geschrieben wird. > Also von Win95 bis Suse 4.1 und MacOS? Nein, die Unit Tests und ein paar Stichproben müssen reichen.
John-eric K. schrieb: > Wie wäre es mit DFU (Device For Update) wo ST? Das würde dann endgültig nur für Windows funktionieren. Ausserdem müsste der Kunde dann unverschlüsselte Firmware in die Hände bekommen.
Axel S. schrieb: > Das sieht schon Wikipedia anders: > https://en.wikipedia.org/wiki/File_Allocation_Table#Patents > und denen glaube ich mehr als dir Ungültiges Patent: http://juris.bundespatentgericht.de/cgi-bin/rechtsprechung/document.py?Gericht=bpatg&Art=en&nr=1659&pos=0&anz=1&Blank=1.pdf Ich würde aber auch zu FAT16 tendieren mit 8.3 Namen. Lesender Zugriff ist da recht trivial zu implementieren (OT: paßte auch noch mit in ein 512B Bootrecord).
Torsten R. schrieb: > John-eric K. schrieb: >> Wie wäre es mit DFU (Device For Update) wo ST? > > Das würde dann endgültig nur für Windows funktionieren. Ausserdem müsste > der Kunde dann unverschlüsselte Firmware in die Hände bekommen. Warum Thorsten? http://dfu-util.sourceforge.net/ "Most Linux distributions ship dfu-util in binary packages for those who do not want to compile dfu-util from source. On Debian, Ubuntu, Fedora and Gentoo you can install it through the normal software package tools. For other distributions (namely OpenSuSe, Mandriva, and CentOS) Holger Freyther was kind enough to provide binary packages through the Open Build Service." Zwecks unverschlüsselt: Wer sagt das der mit DFU beschreibbare Bereich direkt die auszuführende Firmware beherbergt. Das kann ein Interner Speicherbereich sein oder ein externer Flashspeicher. Die bieten doch den Quellcode an. Die signierte/verschlüsselte Firmware ließt der Bootloader dann beim Neutstart ein und entpackt sie z.B.
John-eric K. schrieb: > Warum Thorsten? Selbst wenn es alternative Tools gibt: Drag'n Drop (oder ähnlich einfaches) ist einfach einfacher ;-) Und damit mit der Support für das Protocol in den meisten OSs eingebaut sein.
Torsten R. schrieb: > Axel S. schrieb: >> TL;DR: ein Filesystem ist ein Einfallstor. Ein bösartiger Host kann da >> allen möglichen Mist drauflegen und deinen µC z.B. dazu bringen, interne >> Datenstrukturen offen zu legen. Ein solcherart genutztes Filesystem muß >> Verwaltungsstrukturen (z.B. Blocknummern bei FAT) auf Validität prüfen >> bevor es sie verwendet. > > Ja, aber da würde ich jetzt auch nicht zu viel drauf legen. Das gilt > schließlich für jede Form von Kommunikation mit der Aussenwelt. Da muss > man drauf achten, aber das kann man fehlerfrei hin bekommen. Ich habe auch nicht behauptet, daß man das nicht hinbekommen kann. Sondern nur, daß die üblichen FAT-Implementierungen für µC alles andere als robust sind. I.d.R. sind sie schon von der Funktionalität so weit wie nur möglich abgespeckt. Plausibilitätstests oder gar harte Verifizierung der Verwaltungsstrukturen erwarte ich da gar nicht erst. Genau das würde man aber eigentlich haben wollen. Sonst kann man sich den Zirkus mit Verschlüsselung der Firmware auch gleich sparen. DFU erscheint mir übrigens als sehr gute Alternative. Immerhin ist es genau für den intendierten Anwendungsfall gemacht. Und daß es das Klicki-Bunti GUI Gedöhns nur für Windows gibt, ist auch kein Beinbruch. Die Leute, die mit Linux unterwegs sind, brauchen das sowieso nicht. Die können auch eine Kommandozeile bedienen.
Axel S. schrieb: > DFU erscheint mir übrigens als sehr gute Alternative. Immerhin ist es > genau für den intendierten Anwendungsfall gemacht. Und daß es das > Klicki-Bunti GUI Gedöhns nur für Windows gibt, ist auch kein Beinbruch. Gibt es da was für Windows, dass bereits bei Windows dabei ist? > Die Leute, die mit Linux unterwegs sind, brauchen das sowieso nicht. Die > können auch eine Kommandozeile bedienen. Und dann wären da noch die OS/X Nutzer, die keine SW-Entwickler sind. Ein Protokoll, dass mir garantiert, dass die Daten in definierter Reihenfolge ankommen, fänd' ich auch am charmantesten. Wenn ich aber für jede Plattform noch ein Tool zur Verfügung stellen muss, dann ist der Aufwand plötzlich nicht mehr so gering.
Torsten R. schrieb: > Ein Protokoll, dass mir garantiert, dass die Daten in definierter > Reihenfolge ankommen, fänd' ich auch am charmantesten. Wenn ich aber für > jede Plattform noch ein Tool zur Verfügung stellen muss, dann ist der > Aufwand plötzlich nicht mehr so gering je nach Anwender geht es überall auf der "console" Windows: copy Firmware COM1 Linux cp Fimware /dev/ttyUSB1 MacOS (vermutlich wie Linux)
Torsten R. schrieb: > damit man dort Firmware-Updates rauf spielen kann. Das > Gerät erscheint dabei als Mass Storage Device und der Kunde kann ein > Firmware installieren, in dem er eine Datei darauf kopiert. > > Nun muss ich ja wohl so etwas wie ein Dateisystem auf dem Gerät > implementieren, damit PCs auf das Gerät zugreifen können. Also Firmware ist doch der Bootloader?! Oder das was der Bootloader lädt und startet -> Also muss es ein Filesystem sein was der Bootloader/Flash controller versteht?! Das wird aus Resourcengründen kein FS sondern einfach ein inkrementierter Addressbereich sein der mehr oder weniger 1:1 ins RAM copiert wird und wird auf Adresse 0 gesprungen. Anders wäre es ein Henne-Ei Problem: In der Firmware ist der Treiber für das fs - aber um diesen Treiber zu starten muss man bereits auf das fs lesen zugreifen können!! Schau mal wie uBOOT das macht: https://en.wikipedia.org/wiki/Das_U-Boot das kann auch ect2 und so, es ist jetzt interessant wieviel kB vom uboot dafür verschwendet werden - du hast janur 400k im System ?!
Kevin aus Hürth schrieb:
(Blödsinn)
Meine Güte. Lies doch einfach erst mal ein paar Postings im Thread,
damit du überhaupt die Fragestellung verstehst.
Hallo Kevin, Kevin aus Hürth schrieb: > Torsten R. schrieb: > > Also Firmware ist doch der Bootloader?! Oder das was der Bootloader lädt > und startet -> Also muss es ein Filesystem sein was der Bootloader/Flash > controller versteht?! zweiteres. Oder anders herum, ich muss den Bootloader so implementieren, dass die Anforderungen erfüllt werden. > Schau mal wie uBOOT das macht: https://en.wikipedia.org/wiki/Das_U-Boot Wenn ich das richtig überblicke, dann kann der von einem Mass Storage Device booten. Ich möchte aber, dass unser Gerät als Mass Storage Device funktioniert. mfg Torsten
Peter II schrieb: > Windows: > copy Firmware COM1 > > Linux > cp Fimware /dev/ttyUSB1 > > MacOS (vermutlich wie Linux) Ich fürchte, dass müsste man dann noch etwas consumer-tauglicher in eine GUI verpacken. Das fände ich immer noch keine schlechte Lösung, den die Firmware muss der Kunde eh von der Webseite des Herstellers herunter laden. Und ob ich nun eine Firmware herunter laden, oder einen Installer, macht aus Kundensicht keinen Unterschied. Mit Boost und Qt kann man sogar exakt den gleichen Code für viele Plattformen verwenden. Eine ausliefernde Web-Applikation kann anhand des HTTP-Clients dann sogar schon mal eine zu 99% korrekte Vorauswahl treffen. Aber: das ist vom Aufwand her auf der Build-Infrastruktur und Web-Seite deutlich mehr (auf der Bootloader-Seite deutlich weniger).
Axel S. schrieb: > Kevin aus Hürth schrieb: > > (Blödsinn) > > Meine Güte. Lies doch einfach erst mal ein paar Postings im Thread, > damit du überhaupt die Fragestellung verstehst. Bitte erklär mir mal den Blödsinn! Torsten R. schrieb: > Wenn ich das richtig überblicke, dann kann der von einem Mass Storage > Device booten. Ich möchte aber, dass unser Gerät als Mass Storage Device > funktioniert. Ja das ist mir klar, aber das storage im fs ist doch nicht Selbstzweck. Oder? du willst doch im fs gespeicherte Firmware booten. Also brauchst du ein bootfähiges fs. Oder soll dein USB-device nur nach aussen wie eine fs-API funktionieren also einen filehandler mit fopen,fstat,fwrite,fread realisieren aber das Speicherimage ist propitär und schlank. Es realisiert also kein MBR, Partitiontable, Stammverzeichniss, File allocation table etc. ?? Dann schau mal nach virtual filesystem, also einen Abstraction layer fürs fs https://en.wikipedia.org/wiki/Virtual_file_system . Mglw. ist das generischen filesystem das was du suchst http://elm-chan.org/fsw/ff/00index_e.html .
Kevin aus Hürth schrieb: > Axel S. schrieb: >> Kevin aus Hürth schrieb: >> >> (Blödsinn) >> >> Meine Güte. Lies doch einfach erst mal ein paar Postings im Thread, >> damit du überhaupt die Fragestellung verstehst. > > Bitte erklär mir mal den Blödsinn! Aber gerne doch. Gleich hier steht schon wieder welcher: > du willst doch im fs gespeicherte Firmware booten. Nein. Will er nicht. Wie gesagt: wenn du wenigstens ein paar Beiträge des Threads gelesen hättest - im Prinzip hätte schon aufmerksames Lesen des Eröffnungsposts gereicht, dann wüßtest du auch was der TE will und warum das was du "beiträgst" ihm nicht hilft.
Hallo, vielen Dank für die viele, konstruktiven Beiträge, Tipps und Vorschläge. Das hat mir gut geholfen, das ganze Thema an einem Tag relativ komplett zu überblicken. Ich habe mich jetzt dafür entschieden, auf dem device ein FAT12 zu implementieren. Sector-größe ist gleich Cluster-Größe ist gleich 512 bytes. Das Device gaukelt dem Host dabei vor, etwas mehr Kapazität zu haben, als an Flash für die Firmware zur Verfügung steht. Dass sollte dazu führen, dass selbst wenn ein Host wie OS/X da noch irgend welche zusätzlichen Dateien rauf spielt, der volle Flash-Umfang zur Verfügung steht. Der Größteil der Daten-Sektoren sind mit dem Flash des Firmware-Bereichs unterlegt, dazu noch etwas RAM für die „Übergröße“ und damit am Ende beim Sortieren der Cluster nicht zu häufig im Flash geschrieben werden muss. Die Verwaltungsinformationen wie FAT und RootDirectory liegen komplett im RAM und damit lässt sich sehr einfach ein leeres, bespielbares Mass Storage Device initialisieren. Zusätzlich gibt es noch ein Bit im RAM für jeden Daten-Sector, damit ich verhindern kann, dass ein Host lesend auf einen Sektor zugreift, den er nicht vorher geschrieben hat (in dem Fall bekommt er einen komplett leeren Sektor). Wenn das device vom Host ausgeworfen wird, geht der Bootloader los, und sucht im Root-Directory nach einer Datei, die einen passenden Header enthält, läuft die Liste der Sektoren ab und reicht diese zum Entschlüsseln und Flashen weiter. Überschreitet die Menge der dabei installierten Sektoren, die erwartete, maximale Größe der Firmware, dann bricht der Bootloader ab (so kann ich mir die Ressourcen zum Test auf Rekursionen in der FAT sparen). Anschließend überprüft der Bootloader noch die Checksumme der unverschlüsselten Firmware mit der im header gegebenen Checksumme und aktiviert die neue Firmware. mfg Torsten
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.