Die Größe des Speicherauszugs stimmt nicht mit der Größe der MTD-Partition überein

Gerät mit eingebettetem Linux-System auf NAND-Flash-Speicher. Ich habe ein Speicherabbild einiger MTD-Gerätepartitionen erstellt, die die serielle Konsole verwenden, und vom U-Boot-Bootloader die verfügbaren Befehle verwendet. Zuerst habe ich die MTD-Partition gelesen, um sie im Speicher zu adressieren, und dann den Speicher von dieser Adresse in das Terminalfenster übertragen. Zum Beispiel 0x01d60000-0x01e60000 : "FPAR"ist die MTD-Partition die MTD-Partitionsgröße0x00100000 = 1048576 bytes

nand read 0x20000000 0x01d60000 0x00100000
NAND read: device 0 offset 0x1d60000, size 0x100000
1048576 bytes read: OK
md.b 0x20000000 0x00100000

Dann die Logdatei mit Dump als Textdatei gespeichert, zusätzliches Material vor und nach dem Dump herausgeschnitten und für die binäre Verwendung konvertiert

xxd -r -p dump.txt dump.bin

Die resultierende Bin-Dateigröße von 1.310.860 Bytes stimmt nicht mit der MTD-Partitionsgröße (1.048.576 Bytes) überein, sie ist viel größer. Hängt das Problem mit der Hex-Datenkonvertierung zusammen oder weist der Dump-Prozess Fehler auf? Ich verstehe, dass die Größe der MTD-Partition von 1048576 Bytes der gesamten MTD-Partition zugewiesen ist, die tatsächlichen Daten auf der Partition viel weniger Platz einnehmen, der große Platz mit Hex-Werten „ff“ gefüllt ist. Kann jemand außerdem ein gutes Dienstprogramm für die Hex-to-Bin-Datenkonvertierung empfehlen?

Bearbeiten: Ich habe die gleichen Schritte mit einer Datengröße von 64 Byte versucht und den Raw-Log-Sitzungsmodus verwendet, nachdem ich zusätzliches Material gekürzt habe, ist die resultierende ASCII-Datei 318 Byte. Nach der Dump-Konvertierung beträgt die Bin-Größe 87 Byte.

20000000: a0 7c 4f fa 62 61 75 64 72 61 74 65 3d 31 31 35    .|O.baudrate=115
20000010: 32 30 30 00 65 74 68 61 64 64 72 3d 46 46 3a 46    200.ethaddr=FF:F
20000020: 46 3a 46 46 3a 46 46 3a 46 46 3a 46 46 00 6e 65    F:FF:FF:FF:FF.ne
20000030: 74 6d 61 73 6b 3d 32 35 35 2e 32 35 35 2e 32 35    tmask=255.255.25
Was versuchst du damit zu erreichen? Was haben Sie mit dieser Datei vor?
Versuchen Sie das gleiche Verfahren mit einer viel kleineren Speichermenge (z. B. 64 Bytes) und prüfen Sie dann die Ergebnisse in jeder Phase, um zu sehen, wo die 25 % zusätzlichen Bytes hinzugefügt werden.
@Bruce Abbott Ich habe dasselbe mit Daten mit einer Größe von 64 Bytes versucht, Dump mit Gedit bearbeitet: resultierende ASCII-Dateigröße = 318 Bytes. Beschädigt also geditdie Datei. Aber selbst wenn ich die Datei mit einem anderen Editor bearbeite, zum Beispiel Geany, ist die resultierende Dateigröße gleich.
Warum bestehen Sie darauf, dies blind zu tun? Verwenden Sie ein Tool, um sich die Dateien hexdumptatsächlich anzusehen und zu sehen, was anders ist.
Ok, ich sollte nur Hex-Werte aus Hexdump konvertieren, ohne die ASCII-Darstellungstabelle.
Anscheinend habe ich einen falschen Weg verwendet, um Hex-Dump in eine Bin-Datei zu konvertieren, nur Hex-Werte sollten konvertiert werden, die ASCII-Tabelle muss bereinigt werden.

Antworten (1)

Versuchen:xxd -r -seek -0x20000000 dump.txt dump.bin

xxd -r -perwartet Eingaben im reinen Hexadezimalformat, ohne Adressen oder ASCII. xxd -rwithout -seeknimmt an, dass Adressen nullbasiert sind, und sucht oder füllt seine Ausgabe mit Nullen auf, um Bereiche zu überspringen, die nicht im Dump vorhanden sind (die ersten 0x20000000 = 536870912 Bytes).

Ja, dieser Befehl führt die korrekte Konvertierung durch, die Binärausgabe entspricht der tatsächlichen Größe der MTD-Partition. Danke schön.
Die Größe des Speicherauszugs stimmt nicht mit der Größe der MTD-Partition überein
AntwortenHierDatenschutz-Bestimmungen1y, 0v