EDIT: Lösung steht weiter unten in dem Beitrag, der Rest davor waren nur Überlegungen, die man in so einem Falle anstellt ...
=============================================================================================
Das hilft nicht wirklich weiter ... was man da braucht, ist ein "hexdump -C -n 2048
filename" (fürs nächste Mal), denn mit "tail" erwischst Du ja das Ende der Datei ("head" wäre hier eine Möglichkeit, ist aber mehr für Text-Dateien geeignet).
Ich habe mir ja mal selbst ein Image gebastelt (bzw. aus der AVM-Datei "kernel.image" mittels "dd" zurechtgestutzt) und da steht an Offset 8 tatsächlich die "Gesamtlänge" des Images (0xf58790), wie auch noch einmal als 64-Bit-Wert an Offset 0x28.
Das ist - auf den ersten Blick - der einzige Unterschied und auch das erfolgreiche Entpacken mit "unsquashfs4" spricht eigentlich dafür, daß der Aufbau kein anderer ist (auch die squashfs_fs.h aus beiden Kernel-Sourcen - die AVM-Originale - ist identisch, sagt mein "diff"-Kommando). Wenn das also nur dieses Feld ist, was ein erfolgreiches Mounten auf der 7490 verhindert, müßte man mal mit "dd" den Wert an Offset 8 mit einem anderen ersetzen und dann probieren, ob es sich nun mounten läßt. Wobei das auch schon kurios wäre, weil das Datum ja eigentlich egal sein sollte ... alles etwas komisch.
Aber wenn die 7360 an dieser Stelle tatsächlich noch einmal die Länge des Images als 32-Bit-Wert haben will, wäre das eine denkbare Ursache ... auf den korrekten Inhalt der Include-Dateien in den Kernel-Quellen würde ich auch nicht in jedem Falle wetten wollen (habe ich gerade bei der 7490 erst feststellen müssen, daß da wohl noch etwas fehlt beim 3.10.73-Kernel).
Am einfachsten testet man das dann wieder mit einem "handcrafted image file" ... aber das ist sicherlich nichts, was man @elsterkrug jetzt nahelegen sollte. Man müßte mal spaßeshalber in der zusammengesetzten Image-Datei vor dem Flashen die Zeichenkette "sqsh" suchen und an der Stelle, wo diese gefunden wird, einfach 8 Byte weiter denselben Wert eintragen, wie er am Offset 0x2C nach der Fundstelle auch steht.
Startet die Box dann mit diesem Image, ist das mit der 32-Bit-Länge an Offset 8 praktisch erwiesen (im wahrsten Sinne des Wortes) und dann dürfte mal wieder der Inhalt der Kernel-Sourcen nicht so richtig stimmen, denn der ist bei der 7360 und bei der 7490 im Verzeichnis fs/squashfs identisch (in den originalen AVM-Dateien).
- - - Aktualisiert - - -
Als ich letztens irgendwo behauptet habe, die 7360 wäre die erste NOR-Box mit 3er-Kernel, wurde ich auf irgendein anderes Modell hingewiesen ... aber ich weiß auch nicht mehr genau, wo das war.
- - - Aktualisiert - - -
BTW ... die 7272 und die 3272 sind - entgegen Deiner Liste oben - auch NAND-Boxen.
- - - Aktualisiert - - -
Ne, ein "make kernel-source" funktioniert auch für die 7360(v2) mit 06.50 ... aber die Quellen stimmen vermutlich ohnehin nicht 100%ig - jedenfalls dann, wenn die Vermutung mit dem Wert an Offset 8 stimmt.
- - - Aktualisiert - - -
So, hat mir dann doch keine Ruhe gelassen und ich habe folgende Erkenntnisse (auch nur für mich, aber ich schreibe es trotzdem mal auf) gewonnen:
Das Mounten des SquashFS-Images für die 7360 auf einer 7490 scheitert daran, daß da vom "loop device" die Daten nur bis zum Offset 0xf58600 bereitgestellt werden, wenn man das Image nur in der tatsächlichen Größe von 16091024 Byte (0xf58790, ab "sqsh" und ohne TI-Checksumme in den letzten 8 Byte) verwendet. Dann liegen einige Verwaltungsstrukturen außerhalb dieses Bereiches und der Superblock wird als ungültig eingestuft, weil er eine Länge von 0xf58790 Byte enthält.
Bläst man das SquashFS-Image auf die nächste 4K-Grenze mit Nullen aus /dev/zero auf (0xf58800 reichte bei meinem Versuch nicht, aber 0xf59000 - daraus habe ich auf 4K anstelle von 1K (0x800 wären ja auch gleich 2K als integrale Grenze) geschlossen), läßt sich das Filesystem auch wieder auf einer 7490 mounten.
Allerdings funktioniert damit das simple Mounten des originalen "kernel.image" der 7360 mit passendem Offset (der läge irgendwo bei 0x263d00) nicht mehr ohne weiteres auf der 7490, weil eben am Ende der Block nicht voll ist.
Man kann aber einfach das Image von der Prüfsumme befreien (alles bis auf die letzten 8 Byte kopieren mit "dd" oder gleich mit "truncate" - wenn die verwendete Busybox das enthält - passend verkürzen) und dann noch einmal mit einer Blockgröße von 4K und "conv=sync" mit dem "dd"-Kommando kopieren.
Das so erzeugte Image läßt sich dann sowohl mounten als auch flashen (solange man es nicht über die /var/install machen lassen will, dann muß man erst noch an das aufgepumpte Image die TI-Prüfsumme wieder anfügen und da ist dann auf die integrale Länge auch gepfiffen, solange das loop-Device nur genug Daten liefert für die größte Verschiebung im Superblock) ...
es gibt also (trotz des nach wie vor falschen Wertes im SquashFS-Superblock an Offset 8, wo die Timestamp vom mksquashfs hingehören würde)
keinen wirklichen Unterschied im SquashFS4-Format zwischen der 7490 und der 7360.
Es lag alles nur am Loop-Device, was (merkwürdigerweise) zu wenige Daten aus dem Image liefert(e). Man kann diese Diskrepanz leicht überprüfen, indem man das betreffende Image mittels "losetup" auf ein loop-Device aufsetzt und dann durch Kopieren dieses Block-Devices nach /dev/null einfach mal die Bytes "zählen" läßt (falls man kein "wc -c" zur Hand hat). Es hat also mit dem SquashFS-Treiber (und der Art, wie der vielleicht auf die Daten zugreifen will) nichts zu tun ...
Ob das irgendwo dokumentiert ist, weiß ich gar nicht - wenn nicht, ist es in meinen Augen ein netter Bug. Spannend wäre es, was so ein Loop-Device aus einem Image < 4K macht bzw. wo da die Grenze genau liegt, aber das ist schon wieder "something completely different".
- - - Aktualisiert - - -
Das mit der 4K-Grenze war zum Teil ein Testfehler ... an der nächsten 512-Byte-Grenze ändert sich der tatsächliche Fehlercode beim Mounten von "EINVAL" in "EIO" - man sieht es nur beim "normalen" Mounten nicht auf Anhieb, erst wenn man "verbosity" einfordert:
Code:
$ mount [COLOR="#FF0000"]-vv[/COLOR] filesystem_hc.image /var/tmp/test2/
mount: mount('/dev/loop3','/var/tmp/test2/','ext3',0x00008000,'(null)'):-1: Invalid argument
mount: mount('/dev/loop3','/var/tmp/test2/','ext2',0x00008000,'(null)'):-1: Invalid argument
mount: mount('/dev/loop3','/var/tmp/test2/','ext4',0x00008000,'(null)'):-1: Invalid argument
[COLOR="#008000"]mount: mount('/dev/loop3','/var/tmp/test2/','squashfs',0x00008000,'(null)'):-1: Input/output error[/COLOR]
mount: mount('/dev/loop3','/var/tmp/test2/','fuseblk',0x00008000,'(null)'):-1: Invalid argument
mount: mount('/dev/loop3','/var/tmp/test2/','yaffs',0x00008000,'(null)'):-1: Invalid argument
mount: mount('/dev/loop3','/var/tmp/test2/','yaffs2',0x00008000,'(null)'):-1: Invalid argument
mount: mounting /dev/loop3 on /var/tmp/test2/ failed: Invalid argument
Damit spielt dann ab der 512-Byte-Boundary doch wieder der SquashFS-Treiber irgendwo mit ... diese Grenze ist wieder normal bei Blockdevices, das Loop-Device verwaltet seine Kapazität in kompletten Blöcken:
Code:
$ losetup -f;losetup -f filesystem_hc.image
/dev/loop3
$ cat /sys/devices/virtual/block/loop3/size
31428
Diese 31428 Blöcke sind dann wieder (31428 * 512 =) 16091136 Byte an der nächsten 512-Byte-Boundary, aber auch damit funktioniert eben das Mounten noch nicht ... beim vorhergehenden Test hatte ich mich davon irritieren lassen, daß die abschließende Feststellung des "mount"-Kommandos (ohne die wiederholte "v"-Option) sich nicht geändert hatte.
