Forum: Mikrocontroller und Digitale Elektronik welches Filesystem


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Kevin aus Hürth (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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

von Patrick C. (pcrom)


Lesenswert?

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 ?

von Jim M. (turboj)


Lesenswert?

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
von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Pandur S. (jetztnicht)


Lesenswert?

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
von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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 :-(

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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 ;-)

von Peter II (Gast)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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
von Sebastian V. (sebi_s)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

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.

von Sebastian V. (sebi_s)


Lesenswert?

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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

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.

von Harry L. (mysth)


Lesenswert?

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)

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Harry L. (mysth)


Lesenswert?

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......

von Random .. (thorstendb) Benutzerseite


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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
von Peter II (Gast)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Clemens L. (c_l)


Lesenswert?

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.  :-)

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von FAT - Für Andere Technologien! (Gast)


Lesenswert?

> 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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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!"

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von John-eric K. (mockup)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Mikro 7. (mikro77)


Lesenswert?

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).

von John-eric K. (mockup)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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)

von Kevin aus Hürth (Gast)


Lesenswert?

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 ?!

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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).

von Kevin aus Hürth (Gast)


Lesenswert?

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 .

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.