Byteorder im aktuellen Kernel fuer cramfs geaendert?

[dbox_dbox]

Hi,

wenn ich in einem yadd mit kernel 2.4.22-pre9 ein cramfs flashe, kann ich es nicht mounten. Ich bekomme immer:

cramfs: wrong magic
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000200: 0x453d id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000204: 0x0040 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000208: 0x0300 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000210: 0x436f id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000214: 0x7265 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000218: 0x6564 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000021c: 0x4f4d id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000220: 0x1813 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000228: 0xf307 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000022c: 0xc901 id
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000: 0xb468 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004: 0x14e0 id
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020008: 0xefb7 id

usw.

Deshalb funktioniert dann das booten auch nicht aus dem flash.

Das geflashte cramfs mit einen alten Kernel geht ohne Probleme.

Daraufhin habe ich ein cramfs auf einer ppc Maschine erstellt, und siehe da, ich kann es ploetzlich auch mounten. Leider kann das u-boot nun, wegen der "falschen" Byteorder den Kernel nicht mehr aus dem cramfs lesen.

Wo steckt das der Fehler im Kernel? Er scheint jetzt nur noch BIG-ENDIAN cramfs lesen zu koennen.

MfG

[Voldemort]

Hallo dbox_dbox,

die Feststellung dass die Byteorder falsch ist habe ich bereits im Thead http://tuxbox-cvs.sourceforge.net/forum ... hp?t=23913 vor 4 Tagen getroffen.

Es wurde aber behauptet der Kernel sei in Ordnung, ist er ja vielleicht auch.

Aber wenn man aber die Dateien ../include/linux/cramfs_fs.h und ../fs/cramfs/inode.c des Kernels 2.4.20-dbox2 mit dem neuen Kernel 2.4.22-pre9 vergleicht wird man gewaltige Unterschiede feststellen.
Im alten Kernel wird fleisig die Byteorder gedreht im neuen nicht.

Ok Byteorder drehen bedeutet Zeitaufwand, und vielleicht soll das ja so bleiben wie es jetzt ist.
Dann muss man das aber auch bei der Erstellung des Images berücksichtigen.

Frage also an die Entwickler:
Soll das so bleiben wie es jetzt ist, oder wurde das nur beim Anpassen des Kernels vergessen?
Wenn das so bleiben soll, welche Version des Mkcramfs muss ich benutzen damit ich ein Image mit anderer Byteorder bekomme?
Mein Mkcramfs kennt scheinbar die Parameter b und l nicht.

[obi]

ich wuerde eine big endian byteorder bevorzugen, weil es einfach performanter auf der box ist. ich bin aber eh nicht die zielgruppe. dazu muesste wohl mal jemand das aktuelle mkcramfs patchen. was gerade im kernel ist und was im mtd cvs aktueller stand ist, muss aber jemand anderes beantworten.

[dbox_dbox]

Frage also an die Entwickler:
Soll das so bleiben wie es jetzt ist, oder wurde das nur beim Anpassen des Kernels vergessen?
Wenn das so bleiben soll, welche Version des Mkcramfs muss ich benutzen damit ich ein Image mit anderer Byteorder bekomme?
Mein Mkcramfs kennt scheinbar die Parameter b und l nicht.

Hallo Voldemort,

soweit ich weiss gibt es keine Version von mkcramfs, bei der man die Byteorder drehen kann. Aber wie gesagt, ich habe ein cramfs auf einer ppc-Maschine gemacht und der Kernel konnte es dann auch mounten, nur u-boot muesste dann auch noch angepasst werden...

Also irgendwie muesste man sich mal einig werden...

MfG

[Voldemort]

Doch, es muss ein eine Version geben die die Byteorder dreht.
Jedenfalls lese ich das aus einigen alten Thread's heraus.

Ich habe mir mal die Mühe gemacht den 2.4.22-pre9 Kernel mit den Cramfs-Unterschieden zum 2.4.20-dbox2 Kernel zu kompilieren.
Ich habe dann das selbe Ergebnis wie Du mit deinem auf einer PPC-Maschine erzeugten Cramfs Image.
Es läuft!

[rasta12]

Ich könnte euch ein diff dazu anbieten, was ich mir schon am 03.08 gemacht hatte, aber ich weiss hier nicht wohin damit, da man hier nichts anhängen kann. Es hat so 60k und wäre für den Thread zu mächtig.
..aber ihr habt's ja schon.
Nur wenn das noch ins CVS soll, dann wäre es halt nützlich. Vorrausgesetzt es hat sich nichts mehr seit dem 03.08 geändert. Glaube aber nicht.
Gruss
rasta12

[JOCKYW2001]

Am I correct with this assumption? :
On a lowendian system only the bytes in root-cramfs.img must be swapped before cdk/Makefile invokes flashmanage.pl

JockyW