Firmware Update: welches Dateiformat?

> Auf jeden Fall muss man damit rechnen, dass die
> Zeilenenden beliebig verändert werden und Leerzeichen und TAB
> wahllos umgewandelt werden.

Nein, das passierte nur beim Internet Explorer und auch das nur selten. 
Der Bug ist längst behoben.

> Oder die Datei wird inline per Mail weitergeleitet
> und bekommt '> ' vor jede Zeile.

Entschuldige mal, wer macht denn sowas? Datein hängt man an, alles 
andere halte ich für sehr abwegig.

> Oder sie wird mit irgendeinem Programm geöffnet,
> versehentlich gespeichert und bekommt ein BOM verpasst.

Das und das Format der Zelenumbrüche sind die einzigen Flexibilitäten, 
die ich beim Programmieren berücksichtigen würde.

> Also brauche ich ein Dateiformat, dass solche Mißhandlung übersteht.
> ... Erlaubt sind nur A..Z und 0..9

Schau Dir mal base64 an, das müsste Dir bekannt vorkommen. Und - oh 
wunder - genau dieses Format benutzen Email Programme intern. Wenn du 
mit base64 arbeitest, spielen führende und nachfolgende Leerzeichen 
sowie veränderte Zeilenumbrüche keine Rolle. Selbst das ">" Zeichen kann 
der base64 encoder wegschneiden.

Probier es aus: https://www.base64decode.org/

> Wonach entscheidet ein Mail-Programm, wie es einen Anhang verpackt?

Es unterscheidet nicht. Alle Anhänge werden in base64 codiert.

> Wie kann man in einer Base64 kodierten Datei diese Abschnitte
> sicher trennen?

Ich würde einzelne Dateien übermitteln. Ansonsten denkst Du Dir halt 
irgendein beliebiges Dateiformat aus. Zum Beispiel ganz banal:

Byte 0..1: Länge des Blockes
Byte 2: Abschnitts-Nummer
Byte 3..4: Prüfsumme über die Nutzdaten (optional)
Byte 5+ : Nutzdaten

Mehrere Abschnitte können aneinander gehängt werden. Das Unix Programm 
"tar" arbeitet nach diesem Prinzip.

So ein Paket kann beliebig oft wiederholt werden.

> Datei-Offset geht nicht, weil sich die Länge der Zeilenenden
> ändern kann.

Betrachte die Abschnitte als Ansammlungen von Bytes. Selbst wenn dein 
Update aus Text (z.B. eine HEX Datei besteht) besteht, behandle es 
trotzdem wie eine Ansammlung von Bytes ohne deren Inhalt zu 
interpretieren.

Änderungen am Inhalt würde ich gar nicht zulassen. Nicht ein einziges 
Bit. Das einzige, was in gewissem maße verändert werden darf, ist der 
base64 codierte Datenstrom.

1

 Abschnitt 1 \   (Bytes)                    (Text)

2

+Abschmitt2   |-------------base64 encoder-------------Senden

3

+Abschnitt2  /

1

            (Text)                    (Bytes)   /  Abschnitt 1

2

Empfangen-------------base64 decoder-----------|  +Abschnitt 2

3

                                                \ +Abschnitt 3

pptx

Heutzutage wird doch alles binär übertragen. Zip, Pfd, Jpg... 
Irgendwelche Zeichen im Ascii umcodieren macht auch kein Programm mehr. 
Text wird heute als UTF8 verschickt.

Heutzutage wird die Firewall misstrauisch, wenn sie Base64 in *.txt 
findet.

> Irgendwelche Zeichen im Ascii umcodieren macht auch kein Programm mehr.

Doch, und zwar jedes Email Programm und auch jeder Webserver/Browser. 
Das WWW ist trotz zahlreicher Erweiterungen immer noch sehr 
traditionell.

Können wir und drauf einigen: Wenn du in einem Emailprogramm einen 
Anhang speicherst, oder in einem Webbrower "Ziel speichern" anklickst, 
landet die Datei unverändert auf deiner Platte?

Iso8859<->cp437, oder Zeilenende in crlf konvertieren... das machen die 
Programme nicht mehr.

Ich habe gerade die Feststellung gemacht, daß beim Apdate des 
Xoro-DVBT2-Empfängers die neue Firmware nicht erkannt wurde (aus dem 
Internet runtergeladen). Meldung: Datei nicht erkannt.

Aber mit der anderen, einer zweiten, gepackten Datei von der 
Herstellerseite, ging es dann ohne weiteres. Die hatte ich vorher am PC 
entpackt.

Ist das gemeint?

> Wenn der TO davon ausgeht, dass seine Datei mehr oder weniger beliebig
> misshandelt werden kann, sollten wir ihm das erst mal glauben.

Ja. So etwa 99,9% der Misshandlungen sind Download abgebrochen, 
unvollständige Datei übrig geblieben. Und 0,1% speichern das Html der 
Downloadseite ab und benennen dann die Datei um.

Laaangsam, ich kann garnicht so schnell lesen wie ihr schreibt ;)

Route 6. schrieb:
> Wie groß in Anzahl von Bytes etwa sind deine Updates?
> (rein binär gezählt)

aktuell ca. 80KB, aber es wäre nett, wenn das Format auch für 
Linux-Anwendungen reichen würde. Da sind's z.Zt. vielleicht 5MB.

Stefan U. schrieb:
>> Oder die Datei wird inline per Mail weitergeleitet
>> und bekommt '> ' vor jede Zeile.
>
> Entschuldige mal, wer macht denn sowas?

Die Benutzer? Vielleicht nicht genau das, aber dann etwas ähnlich 
Verrücktes.

> Schau Dir mal base64 an

Hab' ich, es scheint die einzig sinnvolle Kodierung zu sein.

>> Wonach entscheidet ein Mail-Programm, wie es einen Anhang verpackt?
> Es unterscheidet nicht. Alle Anhänge werden in base64 codiert.

Doof. Bandbreitenverschwendung. Aber wenn das so einfach geregelt ist, 
wird es wohl funktionieren.

> Ich würde einzelne Dateien übermitteln.

Dann müsste der Boot Loader prüfen, ob keine fehlt und ob die überhaupt 
alle zum gleichen Update gehören. Das wird aufwendig, bis jetzt kann er 
keine Fehlermeldungen ausgeben, nur ok/nicht ok.

> Änderungen am Inhalt würde ich gar nicht zulassen. Nicht ein
> einziges Bit.

Eh klar. Dafür gibt's für jeden Abschnitt CRC32 und für deine optionale 
Prüfsumme würde ich auch CRC32 einbauen.

> Das einzige, was in gewissem maße verändert werden darf,
> ist der base64 codierte Datenstrom.

Ich könnte einfach alle nicht-base64-Zeichen ignorieren. Damit wird die 
Fehlererkennung aber schlechter. Wie man's macht, ist's verkehrt...


Noch einer schrieb:
> Heutzutage wird die Firewall misstrauisch, wenn sie Base64 in *.txt
> findet.

Sehr guter Einwand, genau wegen sowas hab' ich hier gefragt. Wie soll 
man Firmware denn dann verpacken? Quelltext? USB-Stick per Paket 
verschicken? Flash wird vom Röntgenscanner gelöscht. Einen Spezialisten 
hinschicken? Laptop-Verbot im Flugzeug. Dann eben nicht.


Noch einer schrieb:
> Können wir und drauf einigen: Wenn du in einem Emailprogramm einen
> Anhang speicherst, oder in einem Webbrower "Ziel speichern" anklickst,
> landet die Datei unverändert auf deiner Platte?

Nein. Im wirklichen Leben passiert das nur meistens.


S. R. schrieb:
> Du übertreibst.

Übertreibung macht deutlich, sagt man. Mir geht's nicht um technische 
Übertragungsfehler, ich denke, die hat man im Griff. Ich suche erstmal 
ein paar Ideen, was Benutzer alles anstellen könnten.


Max G. schrieb:
> Was ich noch gerne wüsste: wie kommen denn die Daten am Ende
> ins Zielgerät?

In einer konkreten Anwendung wird ein USB-Stick zu einem Linux-Rechner 
mit Monitor getragen, also alles total einfach. Und selbst da sind schon 
Dateien auf dem Weg zwischen Mail und USB-Stick verändert worden.

Der aktuelle Anlass ist ein Cortex-M3, der über eine serielle 
Schittstelle und ein VDrive3 die Datei vom USB-Stick lesen soll. 
Außerdem sollte ein Update per GSM-Modem möglich sein, wobei sich der 
Boot Loader mehrere Dateien von einem Webserver holt. Eine halbwegs 
kompakte Kodierung ist also nicht unwichtig.


juergen schrieb:
> Ich habe gerade die Feststellung gemacht, daß beim Apdate des
> Xoro-DVBT2-Empfängers die neue Firmware nicht erkannt wurde (aus dem
> Internet runtergeladen). Meldung: Datei nicht erkannt.
>
> Aber mit der anderen, einer zweiten, gepackten Datei von der
> Herstellerseite, ging es dann ohne weiteres. Die hatte ich vorher am PC
> entpackt.
>
> Ist das gemeint?

Im Prinzip ja, es passieren einfach seltsame, unerklärliche Dinge. Wobei 
ich es eher umgekehrt kenne: je mehr der Benutzer macht, umso eher geht 
es schief.

> Xoro-DVBT2-Empfängers die neue Firmware nicht erkannt wurde
> Ist das gemeint?

SIcher nicht. Bei den XORO DVB-T2 Empfängern muss man auf die 
Hardware-Revision achten. Die verkaufen unterschiedliche Geräte mit dem 
selben Namen. Wenn du das falsche Image in den USB Port steckst, 
erscheint genau die von Dir genannte Fehlermeldung. Ich bin auch drauf 
hereingefallen.

eagle user schrieb:
> Auf jeden Fall muss man damit rechnen, dass die
> Zeilenenden beliebig verändert werden und Leerzeichen und TAB wahllos
> umgewandelt werden. Oder die Datei wird inline per Mail weitergeleitet
> und bekommt '> ' vor jede Zeile. Oder sie wird mit irgendeinem Programm
> geöffnet, versehentlich gespeichert und bekommt ein BOM verpasst. Was
> kann noch alles passieren?

Man kann eine Datei als Zip-Datei verpacken. Da ist es mir noch nie 
passiert, dass da irgendwelche CR/CRLF umgwandelt werden oder denen ein 
BOM verpasst wurde. Bilder kommen bei mir auch immer heil an, obwohl 
sich da bestimmt an der einen oder anderen Stelle ein 0x0D o.ä. drin 
verbirgt.

my2ct schrieb:
> Da ist es mir noch nie
> passiert, dass da irgendwelche CR/CRLF umgwandelt werden oder denen ein
> BOM verpasst wurde

Irgendwelche Fehler der Benutzer zu korrigieren ist der völlig falsche 
Weg. Ein Firmware-Update ist ein so kritischer Vorgang, dass nur Daten 
dafür in Frage kommen, an denen absolut NICHTS verändert wurde. Die 
Datei wird mit CRC, Hash o.ä. abgesichert und nur eine verifizierte 
Datei ist überhaupt zum Update zugelassen.

Georg

my2ct schrieb:
> Man kann eine Datei als Zip-Datei verpacken. Da ist es mir noch nie
> passiert, dass da irgendwelche CR/CRLF umgwandelt werden (...)

Zufälle gibt's! Gestern Abend, ich so: "wie geht's", Bekannter so: "so 
viel Stress... und jetzt muss ich alles noch mal einzeln verschicken, 
weil ein paar Leute kein zip auspacken können". Tja...

Jan H. schrieb:
> Außerdem ist das ja sehr weit hergeholt - ein völliger
> Computeranalphabet hantiert doch eh nicht mit Firmware.

Ein völliger Computeranalphabet wäre in der Tat ein kleineres Problem, 
der bekäme den USB-Stick per Post und müsste ihn nur noch richtig rum 
einstecken und eine Taste drücken.


Georg schrieb:

> Irgendwelche Fehler der Benutzer zu korrigieren ist der völlig falsche
> Weg. Ein Firmware-Update ist ein so kritischer Vorgang, dass nur Daten
> dafür in Frage kommen, an denen absolut NICHTS verändert wurde. Die
> Datei wird mit CRC, Hash o.ä. abgesichert und nur eine verifizierte
> Datei ist überhaupt zum Update zugelassen.

Das stimmt natürlich für das eigentliche Image, das hat ja immer seine 
eigenen Prüfsumme. Aber wenn es base64-kodiert transportiert wird, kann 
man doch zumindest white space Änderungen drum herum tolerieren. Recht 
viel mehr will ich in einen Boot Loader auch nicht einbauen.

eagle user schrieb:
> Zufälle gibt's! Gestern Abend, ich so: "wie geht's", Bekannter so: "so
> viel Stress... und jetzt muss ich alles noch mal einzeln verschicken,
> weil ein paar Leute kein zip auspacken können". Tja...

Dann nenne die Datei anschließend um. Machen Google, MicroSoft oder 
Oracle doch auch. KMZ, DOCX oder JAR funktioniert bei Millionen von 
unbedarften Nutzer.

Rufus Τ. F. schrieb:

> Hast Du ernsthaft Probleme damit, z.B. ZIP-Dateien per Email zu
> versenden oder zu empfangen?

Ja. Zum Beispiel gestern beim Kollegen kommt ZIP überhaupt nicht in 
Frage, die Empfänger brauchen die Dateien einzeln, weil sie keinen 
Entpacker haben oder nicht bedienen können.

Im anderen Fall ist irgendwo zwischen Mail-Empfang und USB-Stick etwas 
verändert worden. Der Benutzer hat die einzelnen Dateien auf seinem 
Laptop zwischengelagert, evt. auch auf einem Netzwerklaufwerk. Sowas 
kann man schlecht verbieten, aber mit einer einzelnen Datei gibt es 
weniger Fehlerquellen.

Patrick J. schrieb:
> Das hilft Dir aber auch nicht wirklich, da die umbenannte Datei ja
> trotzdem 'entzipt' werden muß - wenn Das der User nicht hinbekommt, muß
> Das Dein Programm können.

Das wäre der Boot Loader - lieber nicht, ist ja auch nicht nötig.


Peter D. schrieb:
> Was stört Dich an IHEX?

Es erinnert an Intel und ich bin mit S19 groß geworden ;)
Beide Formate sind halt etwas sperrig, meine Binärdaten sind 
base64-kodiert  ziemlich genau halb so groß wie im S19-Format. Beim 
Transport per HTTP oder SMTP sehe ich zwischen den dreien keinen 
Unterschied, nur, wenn eine langsame serielle Verbindung ins Spiel 
kommt.

Rufus Τ. F. schrieb:
> Das ist ein Problem der Nutzerkompetenz. Das kannst Du mit Dateiformaten
> nicht lösen.

Man kann die Nutzer/Idioten ausschliessen: Industrie 4.0, IOT, das Gerät 
holt die Updates aus dem Internet ohne die Bediener lange zu fragen. Ob 
das besser ist, ist wohl eine philosophische Frage, aber jedenfalls 
liegt es voll im Trend.

Georg

>> Hast Du ernsthaft Probleme damit, z.B. ZIP-Dateien per Email zu
>> versenden oder zu empfangen?

> Ja. Zum Beispiel gestern beim Kollegen kommt ZIP überhaupt nicht in
> Frage, die Empfänger brauchen die Dateien einzeln, weil sie keinen
> Entpacker haben oder nicht bedienen können.

Entschuldige mal, seit Windows 95 ist diese Funktion doch Bestandteil 
des Dateimanagers. Man öffnet ZIP Dateien durch doppelklick, so wie man 
auch alle anderen Dateien öffnet.

Unter Linux und Mac geht das sogar noch länger. Selbst die meisten 
Smartphones können das ohne Zusatzprogramme.

Die ganze Geschichte wirkt von Anfang bis Ende an den Haaren 
herbeigezogen. Ich glaube Dir kein Wort.

Na gut, überredet, also reine Binärdaten ohne Kodierung und ohne 
Verpackung. Damit reduziert sich meine Frage auf: Welche Dateiendung? Es 
soll halt bei einem Doppelklick nichts passieren. Und ja, natürlich 
versuchen die Benutzer, die Datei zu öffnen.

Auf einem eigenen Webserver kann ich evt. mit Content-Disposition noch 
etwas beeinflussen, aber per Mail habe ich wohl nur die Dateiendung.


Rolf M. schrieb:
>> Der Dateiname ist noch einfach: genau 8 Zeichen, ein Punkt und 3 weitere
>> Zeichen.
>
> Warum? Muss es auch mit MSDOS funktionieren?

Nicht direkt mit MSDOS, aber mit FAT ohne lange Dateinamen. Das VDrive3 
kann nichts anderes, ist aber ansonsten perfekt für diesen Zweck.

Sind eigentlich Dateien ohne Endung praktikabel?

eagle user schrieb:
> Sind eigentlich Dateien ohne Endung praktikabel?

Üblich unter Unix/Linux: was die Datei darstellt, wird durch die 
Ordnerstruktur definiert. Hat den schönen Nebeneffekt, dass ohne die 
exakte Erhaltung der Ordnerstruktur die Daten unbrauchbar werden, was 
besonders Datensicherung richtig spannend macht.

Georg

eagle user schrieb:
> Na gut, überredet, also reine Binärdaten ohne Kodierung und ohne
> Verpackung. Damit reduziert sich meine Frage auf: Welche Dateiendung?

Wie wärs mit .bin?

eagle user schrieb:
> Sind eigentlich Dateien ohne Endung praktikabel?

Würde ich für zumindest als direkten Download nicht empfehlen. Ich habe 
schon mehrmals Dateien von Webseiten runtergeladen, die ohne Dateiendung 
auf der Festplatte landeten. Tatsächlich waren es aber mp3- oder 
pdf-Dateien. Da war wohl der Webserver irgendwie falsch konfiguriert.

Daher würde ich bei einer Datei ohne Endung erstmal rätseln, welches 
Format sie denn tatsächlich hat. Es könnte ja auch eine zip/rar/tar.gz 
o.ä. sein, die ich erst noch entpacken muss, bevor ich sie dem 
Firmware-Update-Tool übergebe. Bei einer .bin-Datei stelle ich mir die 
Frage nicht.

Rolf M. schrieb:
> Ob es unter Windows möglich ist, auch einer nicht vorhandenen
> Dateiendung ein Programm zuzuordnen, weiß ich gar nicht.

Der normale Benutzer schafft es wohl nicht und bekommt immer die 
Rückfrage "öffnen mit?". Wer an der Stelle weitermacht, ist selbst 
schuld. Das ist genau das, was ich brauche. Spannend ist, was das sonst 
für Nebenwirkungen hat.

Hans schrieb:
> wie wär's mit .bin?
Das wäre ja viel zu einfach, außerdem listet filext.com über 50 
Programme für .bin :(


Georg schrieb:
> Üblich unter Unix/Linux: was die Datei darstellt, wird durch die
> Ordnerstruktur definiert. Hat den schönen Nebeneffekt, dass ohne die
> exakte Erhaltung der Ordnerstruktur die Daten unbrauchbar werden, was
> besonders Datensicherung richtig spannend macht.
So schlimm kann es nicht, praktisch haben doch die meisten Dateien keine 
Endung und eine Datensicherung, die die Ordnerstruktur nicht sichert, 
sollte wohl eher als Schredder verkauft werden ;)

Firmware-Images haben häufig die Dateiendung .bin
So würde ich es auch machen.

Aber egal welche du wählst, du wirst nie 100% sicher sein können, daß 
die Endung keinem Programm zugeordnet ist. Denn es gibt Millionen 
Programme, die sich 3 Zeichen teilen und darüber hinaus kann der 
Benutzer des Rechners diese Zuordnung jederzeit ändern.

Dumdi D. schrieb:
> eagle user schrieb:
>> Ich suche erstmal ein paar Ideen, was Benutzer alles anstellen könnten.
>
> Geraet waehrend des Firmwareupdates aus und anzuschalten.

Langweilig, solange nicht der Boot Loader selbst überschrieben wird. Der 
sucht doch sowieso nach einem gültigen Programm und wenn er keins findet 
kann er es nochmal probieren. Oder darauf warten, dass wieder ein 
USB-Stick eingesteckt wird.

Aber danke für den Hinweis! Da das Programm aus mehreren Teilen besteht, 
kann es passieren, dass die Teile hinterher von verschieden Versionen 
stammen. Die Fehlermeldungen muss mit nochmal anschauen.

Und jetzt das vorläufige amtliche Endergebnis:
Die Datei enthält ja ein Image des Flash-Speichers. Für Images gibt es 
das Tagged Image File Format, auch .TIF genannt. Na gut, ein etwas 
einfacheres Image-Format tut's auch, z.B. netpbm. Einen Header mit 
wenigstens der Gesamtgröße brauche ich ja sowieso. Bonus bei netpbm: man 
darf Kommentarzeilen im Klartext in den Header schreiben. Die binären 
Daten (das Programm) muss nur mit 0xff aufgefüllt werden, damit das 
Image (das Bild) rechteckig wird.

Kombiniert mit der Dateiendung .PNM (oder .PBM?) ist das ein Foto. Dass 
dieses Bildformat nicht gleich im Browser oder Mail-Programm angezeigt 
wird, ist gerade richtig. Ein Doppelklick startet halt Photoshop oder 
Irfanview. Ein 30KB großes Programm sieht dann so aus wie im Anhang.

Für das Forum hab' ich es nach PNG konvertiert, mal sehen, ob ich das 
.PNM auch direkt anhängen kann.

> Da das Programm aus mehreren Teilen besteht,
> kann es passieren, dass die Teile hinterher von verschieden Versionen
> stammen.

Das wolltest du doch ausschließen, indem du alle Teile zusammenhängend 
übermittelst.

> Für Images gibt es das Tagged Image File Format, auch .TIF genannt.

Mannomann. Du kannst ja nichtmal Bilder und Firmware Images auseinander 
halten! Glaubst du etwa auch, daß ein Bus-System in der Elektronik am 
Hauptbahnhof anhält?

> Kombiniert mit der Dateiendung .PNM (oder .PBM?) ist das ein Foto.

Nein, sicher nicht.

> Ein Doppelklick startet halt Photoshop oder Irfanview.

Was du ja gerade verhindern wolltest. Kannst du mal erklären, warum du 
dann ausgerechnet solche 100% bekannten Dateiendungen nimmst?

Lass das ganze Projekt mal eine Woche ruhen und schlafe dich stattdessen 
aus. Wenigstesn 8 Stunden pro Nacht, dann kannst du auch wieder einen 
klaren Gedanken fassen.

Rufus Τ. F. schrieb:
> eagle user schrieb:
>> Die Datei enthält ja ein Image des Flash-Speichers. Für Images gibt es
>> das Tagged Image File Format, auch .TIF genannt.
>
> Aua. Auauauauaua - Du verrennst Dich da ganz übel.

Was jetzt? Ich sollte doch ein Binärformat nehmen, weil das per HTTP 
oder SMTP problem- und fehlerlos transportiert wird? Mein Binärformat 
besteht zu 99% aus Cortex-M-Maschinenbefehlen mit einem zweckmäßigen 
Header. Dass manche Programme das für ein Bild halten, ist natürlich 
reiner Zufall ;)


Stefan U. schrieb:
>> Da das Programm aus mehreren Teilen besteht,
>> kann es passieren, dass die Teile hinterher von verschieden Versionen
>> stammen.
>
> Das wolltest du doch ausschließen, indem du alle Teile zusammenhängend
> übermittelst.

Mache ich ja auch. Dieses Problem kann entstehen, wenn das Flashen 
unterbrochen wird, z.B. mit Ausschalten. Meistens sind anschließend die 
ersten Teile neu, ein Teil defekt und der Rest alt. Das gibt mehr oder 
weniger eindeutige Fehlermeldungen, je nachdem welcher Teil defekt ist.

> Mannomann. Du kannst ja nichtmal Bilder und Firmware Images auseinander
> halten! Glaubst du etwa auch, daß ein Bus-System in der Elektronik am
> Hauptbahnhof anhält?

Natürlich, muss er doch, jedenfalls normalerweise (Multi-Master-Systeme 
sind neumodisches Teufelszeug).

>> Kombiniert mit der Dateiendung .PNM (oder .PBM?) ist das ein Foto.
> Nein, sicher nicht.

Sagen wird so: ein normales Programm kann nicht erkennen, dass es kein 
Foto ist.

>> Ein Doppelklick startet halt Photoshop oder Irfanview.
> Was du ja gerade verhindern wolltest.

Wenn ich es aber nicht verhindern kann,
Stefan U. schrieb nämlich auch:
> Aber egal welche du wählst, du wirst nie 100% sicher sein können, daß
> die Endung keinem Programm zugeordnet ist.

Schätzungsweise ist ".PNM", wenn überhaupt, einem Bildverarbeiter 
zugeordnet und der kann die Datei anzeigen. Mit .BIN öffnet irgendein 
Programm die Datei und meint, sie wäre beschädigt -> "Ihr habt mir ein 
kaputtes Update geschickt".


Max G. schrieb:
> Beim Weg Mail/Webbrowser->USB-Stick->Gerät dagegen bleibe ich bei meiner
> Mindermeinung. Bastelnde Benutzer, kaputte Mailclients, selbständig
> entpackende Browser - alles das kommt vor und hat das Potenzial,
> Supportaufwand zu generieren. Die Philosophie "egal wie vermurkst der
> Kanal ist, das Gerät kriegt sein Update da noch raus" ist mir sehr
> sympathisch.

Danke dafür, ich werde ich nochmal drüber schlafen...

> Was jetzt? Ich sollte doch ein Binärformat nehmen, weil das per
> HTTP oder SMTP problem- und fehlerlos transportiert wird?

Jaaaaahaaaaaa. Das habe ich doch auch geschrieben! Wie viele Leute 
sollen es Dir noch wiedeholen?

> Mein Binärformat besteht zu 99% aus Cortex-M-Maschinenbefehlen mit
> einem zweckmäßigen Header.

Das ist doch dem Browser und dem Email Programm vällig egal. Für diese 
Programme sind das einfach nur Ansammlungen von Bytes. Alle möglichen 
Werte in beliebiger Kombination und Reihenfolge werden gleich behandelt. 
Da kommt hinten exakt das raus, was vorne rein geschoben wurde.

Deine Argumentation, warum PNM besser geeignet sein soll, als BIN kann 
ich überhaupt nicht nachvollziehen. Wenn dein Kunde die PNM Datei 
doppelt anklickt, sieht er bunte Knete und reklamiert dann "Ich kann da 
nichts erkennen, das Bild ist kaputt".

Wenn er sich noch blöder anstellt klicht er dann auf den Save Button und 
danach ist die Datei dann wirklich beschädigt, obwohl sie auf dem 
Bildschirm unverändert aussieht.

Stefan U. schrieb:

>> Was jetzt? Ich sollte doch ein Binärformat nehmen, weil das per
>> HTTP oder SMTP problem- und fehlerlos transportiert wird?
>
> Jaaaaahaaaaaa. Das habe ich doch auch geschrieben! Wie viele Leute
> sollen es Dir noch wiedeholen?

> Wenn dein Kunde die PNM Datei doppelt anklickt, sieht er bunte
> Knete und reklamiert dann "Ich kann da nichts erkennen, das Bild
> ist kaputt".
>
> Wenn er sich noch blöder anstellt klicht er dann auf den Save Button
> und danach ist die Datei dann wirklich beschädigt, obwohl sie auf
> dem Bildschirm unverändert aussieht.

Und das passiert mit .BIN oder .FOO nicht?

Na gut, dann geht es eben nicht.

Die kleinste tauschbare Einheit ist eine Europakarte, relativ gut 
zugänglich. Früher hat man die per IC-Kuriergut verschickt für 150 DM, 
netterweise ist das sogar billiger geworden: Hamburg - München nur noch 
143.80 EURO ;)

https://www.time-matters.com/de/transportloesungen/ickurier/

> Und das passiert mit .BIN oder .FOO nicht?

Die kann man normalerweise gar nicht öffnen. Außer mit einem Texteditor, 
wenn man die Dateiendung manuell zuweist. Und ob du es glaubst oder 
nicht: Texteditoren machen binäre Dateien normalerweise nicht kaputt, 
wenn man sie nur lädt und wieder abspeichert.

Stefan U. schrieb:
> Die kann man normalerweise gar nicht öffnen

Mit einem Hex-Editor schon, aber wer das macht, ist schon eher bösartig 
als naiv, und gegen solche Leute kann man eh nichts unternehmen.

Im übrigen bewegt sich der ganze Thread in ziemlich abartige Gefilde. 
Seit Jahrzehnten speichert man Embedded Software als BIN oder HEX - bei 
BIN ist klar, dass Veränderungen unzulässig sind, und bei HEX sind 
Eingriffe wie andere Zeilenendmarkierungen egal. Es besteht nicht der 
geringste Bedarf an irgendetwas anderem.

Aber jedem Tierchen sein Plaisirchen.

Georg

Wieso nicht einfach binär und dann eine crc anhängen?

Ein x-kb firmwarr update wird niemans direkt in den mail-text klatschen 
xD

> Wieso nicht einfach binär und dann eine crc anhängen?

Es geht dem TO nicht nur darum, Veränderungen zu erkennen, sondern er 
will sie zulassen. Jede noch so dumme Veränderung soll toleriert werden. 
Das Update soll immer funktionieren.

Rolf M. schrieb:
> eagle user schrieb:
>> Als Dateiendung kommt wahrscheinlich nur ".TXT" in Frage, damit
>> Virenscanner und Firewall-Filter keinen Verdacht schöpfe und Webserver
>> das als text/plain ausliefern.
>
> Eben genau das nicht! Die genannten Probleme resultieren nämlich gerade
> daraus, dass du es als Text übertragen willst. Nimm direkt die
> Binärdaten, und packe einen eigenen Header davor, der Infos über die
> Firmware und natürlich auch eine CRC enthält. So habe ich das auch schon
> erfolgreich gemacht. Wenn man als Dateiendung nicht gerade sowas wie
> .EXE oder .BAT nimmt, ist das normalerweise auch kein Problem.

Rolf M. schrieb:
> Dann denk dir was aus und such mal im Internet, zu welchem Programm
> diese Dateiendung schon gehört. Wenn dabei was hinreichend obskures
> rauskommt, nimm das. ;-)

Ich dachte, genau das hätte ich gemacht und keiner mag es :(

Also gut, nächster Versuch. Nachdem ich mir alle Beiträge nochmal 
angesehen habe, gibt es wohl eine Mehrheit (siehe unten) für ein 
Textformat. Daran hat mich nur dieses:
Noch einer schrieb:
> Heutzutage wird die Firewall misstrauisch, wenn sie Base64
> in *.txt findet.
und die 2.5mal längere Übertragungszeit gestört. Um einen 
Fortschrittsbalken oder Fehlermeldungen anzuzeigen müsste der Boot 
Loader sehr viel mehr über die Hardware wissen. Damit wächst die Gefahr, 
dass er selbst mal ein Update braucht. Also wird er zweistufig, die 
"unveränderliche" erste Stufe lädt nur die zweite Stufe vom USB-Stick 
ins RAM und die kann dann auch das Display initialisieren und den 
Benutzer bespaßen, während das eigentliche Update im srecord-Format 
geladen wird.

Die Datei wird nicht komplizierter, sie enthält einfach einen Abschnitt 
mehr. Sie bekommt die Endung ".S38", genau passend zum Inhalt, ohne 
Tricks. S38 steht für srecord mit 32-Bit Adressen, ist noch etwas 
seltener als .S19 und anscheinend ziemlich eindeutig.

Für USB-Stick und GSM-Download das gleiche Format zu verwenden, ist in 
der Tat nicht wichtig. Der Download wird ja vom Anwendungsprogramm 
gemacht, nicht vom Boot Loader.


Stefan U. schrieb:
>> Wieso nicht einfach binär und dann eine crc anhängen?
>
> Es geht dem TO nicht nur darum, Veränderungen zu erkennen, sondern er
> will sie zulassen. Jede noch so dumme Veränderung soll toleriert werden.
> Das Update soll immer funktionieren.

Naja, in gewissen Grenzen, Aufwand zu Nutzen und so...




Max G. schrieb:
> Beim Weg Mail/Webbrowser->USB-Stick->Gerät dagegen bleibe ich bei meiner
> Mindermeinung. Bastelnde Benutzer, kaputte Mailclients, selbständig
> entpackende Browser - alles das kommt vor und hat das Potenzial,
> Supportaufwand zu generieren.

Stefan U. schrieb:
> Schau Dir mal base64 an, das müsste Dir bekannt vorkommen.

Stefan U. schrieb:
>> Irgendwelche Zeichen im Ascii umcodieren macht auch kein Programm mehr.
>
> Doch, und zwar jedes Email Programm und auch jeder Webserver/Browser.
> Das WWW ist trotz zahlreicher Erweiterungen immer noch sehr
> traditionell.

Noch einer schrieb:
> Heutzutage wird die Firewall misstrauisch, wenn sie Base64 in *.txt
> findet.

Matthias M. schrieb:
> Dann nimm doch Base64.

S. R. schrieb:
> Intel-Hex erfüllt deine Anforderungen:

Peter D. schrieb:
> Was stört Dich an IHEX?

Hans schrieb:
> Wie wärs mit .bin?

Stefan U. schrieb:
> Firmware-Images haben häufig die Dateiendung .bin
> So würde ich es auch machen.

Rufus Τ. F. schrieb:
> Wenn Du ZIP-Dateien zerstörungsfrei versenden und empfangen kannst, und
> es möglich ist, sie zerstörungsfrei auf einem USB-Stick zu
> transportieren, dann kannst Du auch jedes beliebige andere Dateiformat
> versenden, empfangen und transportieren.

S. R. schrieb:
> Bandbreite ist unwichtig, nimm einfach IHEX oder SREC.
> Ohne Absicht kriegst du das Datei nicht kaputt, die Records haben
> Prüfsummen und das Gesamtergebnis sicherlich auch.

Georg schrieb:
> Seit Jahrzehnten speichert man Embedded Software als BIN oder HEX

Grmpf
.S37 es muss .S37 heissen, nicht .S38

Das ist doch ohnehin alles Schwachsinn weil YAGNI. Welche realen Zahlen 
aus dem Support belegen überhaupt, daß es da ein Problem zu lösen gibt?!

eagle user schrieb:
> S38 steht für srecord mit 32-Bit Adressen, ist noch etwas
> seltener als .S19

Dein Ansatz, ein möglichst seltenes Format zu benutzen, ist von 
vornherein Quatsch. Wenn etwas exotisch ist, dann meistens zu recht, 
weit verbreitete Formate haben sich dagegen offensichtlich bewährt.

Der ganze Thread ist längst nur noch sinnlose Spinnerei und für mich 
beendet.

Georg

Georg schrieb:
> Dein Ansatz, ein möglichst seltenes Format zu benutzen, ist von
> vornherein Quatsch.

Der Ansatz ist von vorgestern. Ich hab' zwischendurch versucht, ein 
reines binär-Format zu verwenden und jetzt das srecord-Format, das 
gleich nach IHEX wohl das normalste für EPROM/Flash-Inhalt ist. Weil ich 
mich aber nicht auf 64K beschränken will, nehme ich 32- statt 16-Bit 
Adressen. arm-none-eabi-objcopy liefert übrigens genau dieses Format.

Georg schrieb:
> Der ganze Thread ist längst nur noch sinnlose Spinnerei und für mich
> beendet.

Nop schrieb:
> Das ist doch ohnehin alles Schwachsinn weil YAGNI.

Natürlich, weil eure Geräte ja nie Updates brauchen.
Wenn euch die Frage zu schwierig ist, lest halt die Bildzeitung.

Zwölf M. schrieb:
> Das Ganze ist ein Furz, ein Montagstroll.

Der 28.07.2017 war ein Freitag, ich brauche kein neues Troll-Format.

Mach dir selbst und allen anderen das Leben leicht:
Jemand, der weiss was er da macht, laedt die Firmware auf einen 
FTP-Server, und von da laedst du es wieder runter. Fertig.
Kein Grund sich ueber Dateiformate, dumme User, kaputte Mail-Clients 
oder sonst was aufzuregen.

eagle user schrieb:

> Natürlich, weil eure Geräte ja nie Updates brauchen.

Doch. Aber es gibt keine Zahlen, die Deine Phantasie-Szenarien mit 
Umwandlung der Firmware in PDF, Word, BMP, Flashplayer und zurück auch 
nur irgendwie belegen würden. Deswegen ist es YAGNI-Quatsch.

Guck Dir einfach mal an, wie Mainboardhersteller ihr Bios auf die 
Webseite setzen. Dann weißt Du, was für den Masseneinsatz offensichtlich 
ausreicht.

Wie wärs mit Steganographie ? Der Kunde kriegt ein PDF mit der 
Update-Anleitung und
die Firmware ist als geheimes Wasserzeichen  Kommentar  Metadaten 
versteckt. Da muss der Praktikant erst mal Acrobat Pro raubmordkopieren 
um da was kaputtzumachen.

Ich würde natürlich versuchen , das PDF auszudrucken und das Blatt 
Papier schön gefaltet in die USB-Buchse zu drücken. Am besten 
funktioniert hier der Ausdruck der Sicherheitskopie welche ich vom PDF 
mit meinem PDF-Drucker gedruckt habe um die Originaldatei nicht zu 
beschädigen.

Nächstes mal schicke ich dann ein Anleitungsvideo in 4K , wo die 
Firmware mit Cinavia eingebettet ist. Selbst der CamRIP davon sollte den 
Zuschauern und meinem Bootloader genügen.

Und wenn der User die EXE Datei mit einem Malprogramm öffnet, 
modifiziert und wieder speichert? Gegen solchen Unsinn wollte der TO es 
ja auch schützen. nein schlimmer noch: Jede denkbare Änderung sollte die 
Datei nicht zerstören können, die soll trotzdem funktionieren. Selbst 
wenn ein Screenshot von der Datei in eine Email oder Word Datei 
eingebettet wird.

Stefan U. schrieb:
> Lass das ganze Projekt mal eine Woche ruhen und schlafe dich stattdessen
> aus. Wenigstesn 8 Stunden pro Nacht, dann kannst du auch wieder einen
> klaren Gedanken fassen.

Gemacht.
Das Ergebnis: die Datei ist jetzt base85 kodiert und vor jedem 
Teil-Image steht eine Kommentarzeile ('#') mit Name, Datum,... Diese 
Info und Flash-Adresse, Größe, CRC,... stehen auch im Image selbst. Am 
Dateianfang können beliebig viele Kommentarzeilen stehen, z.B. für eine 
Erklärung, was das für eine seltsame Datei ist und was man damit machen 
sollte. Der Bootloader ignoriert Kommentarzeilen und white space 
innerhalb der Daten. Bei Zeichen außerhalb des base85-Zeichensatzes oder 
falscher Netto-Zeilenlänge ist die Datei ungültig.

Nop schrieb:
> Guck Dir einfach mal an, wie Mainboardhersteller ihr Bios auf die
> Webseite setzen.

Das war ein guter Tipp. Jeder verwendet seine eigene 
Fantasie-Dateiendung, Fujitsu verwendet noch halbwegs normale, liefert 
aber das Image doppelt aus, mit .rom und .UPD, mit identischem Inhalt. 
Außerdem schreibt filetypeadvisor.com:

1

What is the .ROM file type?

2

The .rom filename extension chiefly serves to denote generic

3

Read-Only Memory (ROM) images saved as files. A .rom file can

4

hold PC BIOS firmware or contents of an electronic device's ROM.

5

It contains identical representation of a binary program code

6

placed into the ROM (flash) memory for persistent storage.

7

8

ROM files usually have specific sizes that are multiple of 8

9

(256, 512, and so on), although the exact format of a given

10

.rom file depends on its origin and purpose. ROM files are

11

commonly used for distributing and updating firmware and may

12

have several other extensions (.bin, .ami) or no extension at all.

13

If used for updating (flashing) firmware, any ROM file is first

14

checked for format correctness and data integrity to avoid

15

'bricking' a device.

Perfekt!

Bernd K. schrieb:
> Warum bist Du so besessen von der Dateiendung?

Weil ich nicht weiss, was alles damit gesteuert wird. Ich vermute, dass 
Dateien mit bestimmten Endungen garnicht beim Benutzer ankommen - egal, 
ob per Download oder per Mail. Daher stammt die erste Idee .TXT zu 
nehmen. Oder eben ein Bild, weil ich glaube, dass Bilder eher harmlos 
sind (aus der Sicht eines Virenscanners oder Proxies).

> Wenn Du Dir ein eigenes Dateiformat ausdenkst dann denk Dir Deine
> ganz persönliche eigene Endung aus, Du bist nicht auf 3 Zeichen
> festgelegt

Das wäre eine gute Lösung, aber dann müsste meine Hardware vfat 
verstehen. Der Aufwand wäre immens, verglichen mit dem fertigen VDrive3 
für 20 Euro. Außerdem hätte ich Bedenken wegen der Microsoft-Patente; 
ich würde ja einen eigenen vfat-Treiber brauchen und nicht nur einen 
mitgelieferten benutzen.

Wenn nichts, wirklich gar nichts das Firmwareupdate zerstören können 
soll, gibt es nur eine einzige wirklich sichere Methode:

Lass es von Chuck Norris persönlich ausliefern und installieren.

Klappt.

Garantiert.

Max G. schrieb:
> Rufus Τ. F. schrieb:
>> Schlechte Idee, weil hier jeder Mailclient/Downloader/Text-Editor seine
>> eigene Interpretation über die Codierung drüberlaufen lassen kann, und
>> dann  funktionieren irgendwelche Sonderzeichen nicht, Zeilenumbrüche
>> sind vermurkst etc.
>
> Langsam dreht sich der Thread im Kreis. Das war ja genau das Anliegen
> des TO, eben damit zurechtzukommen. Wenn ich mir den Thread so anschaue,
> war ich gefühlt der Einzige, der die Idee gut fand.

Nicht wirklich im Kreis und du bist nicht der Einzige. Freiwillig werde 
ich das hier (Beitrag "Re: Firmware Update: welches Dateiformat?") 
beschriebene Format nicht mehr ändern. Das geht mit 7 Bit und verträgt 
veränderte Leerzeichen, Zeilenumbrüche und (in Grenzen) Sonderzeichen. 
Es gibt eine spezielle base64 Kodierung, die extra im Hinblick auf 
Sonderzeichen entworfen wurde, aber mir ist ein kompakteres Format 
wichtiger.

Andererseits gibt es ja immer noch wertvolle Anregungen

Rufus Τ. F. schrieb:
> Es gibt durchaus Maildienste & Webserver, die Bilder nachkomprimieren,
> um im Mobilfunknetz Bandbreite zu sparen.


S. R. schrieb:
> eagle user schrieb:
>> Außerdem hätte ich Bedenken wegen der Microsoft-Patente;
>
> Irrelevant.

Genau wegen solcher Aussagen habe ich Bedenken. Deshalb ist die Sache 
klar: vfat kommt nicht in Frage.

BesterProgrammiererVonWelt schrieb:
> Lass es von Chuck Norris persönlich ausliefern und installieren.

:)

> Ich vermute, dass Dateien mit bestimmten Endungen garnicht beim
> Benutzer ankommen

Manche Virenscanner von Firmen entfernen Dateianhänge, die wie 
ausführbare Programme aussehen. Diese solltest du entweder meiden oder 
wie üblich in ein ZIP einpacken.

Stefan U. schrieb:
> Diese solltest du entweder meiden oder
> wie üblich in ein ZIP einpacken.

Unserer entpackt ZIPs und schaut sich den Inhalt an. Kann er die Datei 
nicht entpacken (ungültiges Format, passwortgeschützt), entfernt er sie.
Anfangs ließ er sich noch überlisten, indem man die Datei einfach .zap 
nannte. Mittlerweile erkennt er wohl den Dateiheader.

Ich sag's ja. Du wirst um Chuck Norris nicht drumherum kommen.

Wer so einen doofen Virenscanner verwendet, weiss das auch (ich kenne 
das aus eigener leidvollen Erfahrung). Du hast Recht, man kann nicht 
alle Komplikationen verhindern.

Von irgendeinem Amt bekam ich mal eine Mail zurück, weil ich angehängte 
Bilder als ZIP zusammen gepackt hatte. Wie wollten Bilder nur mit ganz 
bestimmten Auflösungen, maximal 1MB pro Bild und seltsamerweise durften 
sie nicht gepackt werden. Andere Anhänge waren gar nicht zugelassen.

Wie willst du an so jemandem ein Firmware Image schicken? Geht gar 
nicht, ist aber auch genau so gewollt.

Stefan U. schrieb:
> Wie willst du an so jemandem ein Firmware Image schicken? Geht gar
> nicht, ist aber auch genau so gewollt.

Pragmatische Lösung: Jeder hat doch heute irgendeine Mailadresse mit 
Webmailinterface. ;-)

Bernd K. schrieb:
> Warum verschickst Du die Binärdaten nicht einfach als Binärdatei

Weil er hier unbedingt als leuchtendes Beispiel von absoluter 
Unbelehrbarkeit glänzen will. Dass ihm das gelungen ist muss man neidlos 
anerkennen.

Nächste Runde bitte, aber ohne mich.

Georg

>> Wie willst du an so jemandem ein Firmware Image schicken? Geht gar
>> nicht, ist aber auch genau so gewollt.

> Mit dem Ansatz des TO geht das - einfach als Text einer Mail.

Das wierderum würden einige Mail-Scanner als SPAM werten und ebenso 
entfernen.

Bernd K. schrieb:
> Oder sie schicken eine Download-URL wenn sie das
> an mehr als 3 Leute verteilen wollen oder wenn zu erwarten ist daß
> einige der involvierten Mail-Relays wegen Virengefahr/Spamverdacht
> rumzicken werden.
... oder wenn zu vermuten ist, daß einige Mailserver den Ahnhang wegen 
Größenbeschränkungen nicht akzeptieren.

S. R. schrieb:

sorry, ich schon wieder, aber ich hab' gerade etwas interessantes 
gefunden

> eagle user schrieb:
>> Außerdem hätte ich Bedenken wegen der Microsoft-Patente;
>
> Irrelevant.

FTDI sagt dazu in der AN_189:

1

4 Using the LFAT Driver

2

3

To use the LFAT driver, the customer must first obtain a license from

4

Microsoft, then request the LFAT driver library from FTDI, and finally

5

incorporate it into his Vinculum-II development toolchain.

6

7

4.1 Obtaining a License

8

9

Long filename technology is the intellectual property of Microsoft

10

Corporation. Microsoft controls rights to its technologies through its IP

11

licensing group [2]; the technology licensing program includes rights with

12

regard to the implementation of the FAT File System [3]. To use long

13

filenames, the customer must enter into a licensing agreement with

14

Microsoft before FTDI can distribute the LFAT driver library. Consequently,

15

the LFAT driver is not included in the Vinculum-II Toolchain distribution

16

but can be obtained on request from FTDI Support. Prior to distribution,

17

FTDI will obtain an agreement from the customer, stating customer’s

18

responsibility to obtain the LFN license from Microsoft. With that

19

agreement signed off, FTDI is relieved of any liability for releasing the

20

LFN driver library to the customer. It must be stressed that it is the

21

customer’s responsibility to obtain the license from Microsoft, failing

22

which they could face further consequences from Microsoft. For information

23

on how to obtain the LFN license from Microsoft, see [3].

24

25

4.2 Requesting the Library

26

27

After finalizing a license agreement with Microsoft, the customer must

28

contact FTDI Support to request the LFAT driver library archive.

29

30

31

[2] www.microsoft.com/about/legal/en/us/IntellectualProperty/

32

    IPLicensing/Default.aspx

33

[3] www.microsoft.com/about/legal/en/us/IntellectualProperty/

34

    IPLicensing/Programs/FATFileSystem.aspx

Es muss natürlich so aussehen:

sorry, ich schon wieder, aber ich hab' gerade etwas interessantes
gefunden

> S. R. schrieb:
> eagle user schrieb:
>> Außerdem hätte ich Bedenken wegen der Microsoft-Patente;
>
> Irrelevant.