Problems with BIG_ENDIAN

Problems with BIG_ENDIAN

[Steven Scholz]

Hi there,

I am having trouble creating a big endian image with the latest CVS version of
mkfs.jffs2!

> mkfs.jffs2 -d /tmp/initrd.tmp.5530 -o images/pFlashdisk -l -p
> hexdump -n 16 -x images/pFlashdisk 
0000000    1985    2003    000c    0000    b0b1    e41e    1985    e001

> mkfs.jffs2 -d /tmp/initrd.tmp.5530 -o images/pFlashdisk -b -p
> hexdump -n 16 -x images/pFlashdisk 
0000000    1985    2003    000c    0000    b0b1    e41e    1985    e001

Both options -l _and_ -b result in the same byteorder!!!

An older version (mkfs.jffs2 revision 1.28) shows

scholz@pinguin:~/Projekte/SELF> hexdump -n 16 -x images/pFlashdisk 
0000000    1985    e001    0032    0000    76f3    5037    0001    0000

for "-l" and 

scholz@pinguin:~/Projekte/SELF> hexdump -n 16 -x images/pFlashdisk 
0000000    8519    01e0    0000    3200    295a    e78c    0000    0100

when using "-b" !!!

Thanks,

Steven


BTW "mkfs.jffs2 -V" does _not_ work! "mkfs.jffs2 --version" works!

Problems with BIG_ENDIAN

[Grant Edwards]

On Sun, Dec 08, 2002 at 07:11:10PM +0100, Steven Scholz wrote:

> I am having trouble creating a big endian image with the latest
> CVS version of mkfs.jffs2!
> 
> > mkfs.jffs2 -d /tmp/initrd.tmp.5530 -o images/pFlashdisk -l -p
> > hexdump -n 16 -x images/pFlashdisk 
> 0000000    1985    2003    000c    0000    b0b1    e41e    1985    e001
> 
> > mkfs.jffs2 -d /tmp/initrd.tmp.5530 -o images/pFlashdisk -b -p
> > hexdump -n 16 -x images/pFlashdisk 
> 0000000    1985    2003    000c    0000    b0b1    e41e    1985    e001
> 
> Both options -l _and_ -b result in the same byteorder!!!

Yup.  And it looks like it's still that way.  Oddly, a comment
at the top of the file says that cross-endian support has been
added, but it sure looks like "-l" and "-b" are just ignored.

I tried undefining JFFS2_NATIVE_ENDIAN and defining
JFFS2_BIG_ENDIAN, but then nothing builds.  (RH7.3 IA32 host)

Where can I get a version of mkfs.jffs2 that pays attention to
the "-b" flag?  [I unfortunately can't access the CVS archives.]

Thanks,

-- 
Grant Edwards
grante at visi.com

Problems with BIG_ENDIAN

[Grant Edwards]

On Fri, Feb 14, 2003 at 04:28:20PM -0600, Grant Edwards wrote:
> On Sun, Dec 08, 2002 at 07:11:10PM +0100, Steven Scholz wrote:
> 
> > I am having trouble creating a big endian image with the latest
> > CVS version of mkfs.jffs2!
[...]
> > Both options -l _and_ -b result in the same byteorder!!!
> 
> Yup.  And it looks like it's still that way.  Oddly, a comment
> at the top of the file says that cross-endian support has been
> added, but it sure looks like "-l" and "-b" are just ignored.
> 
> I tried undefining JFFS2_NATIVE_ENDIAN and defining
> JFFS2_BIG_ENDIAN, but then nothing builds.  (RH7.3 IA32 host)

I'm having a go at fixing this, but I'm a bit confused by
something in jffs2.h:

  /* Values we may expect to find in the 'magic' field */
  #define JFFS2_OLD_MAGIC_BITMASK 0x1984
  #define JFFS2_MAGIC_BITMASK 0x1985
  #define KSAMTIB_CIGAM_2SFFJ 0x5981 /* For detecting wrong-endian fs */

Where does the value 0x5981 come from?  If the endian setting
is wrong, the bytes within a 16 bit word are swapped and you
see 0x8519 instead of 0x1985.

-- 
Grant Edwards
grante at visi.com

Problems with BIG_ENDIAN

[Grant Edwards]

--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Feb 14, 2003 at 05:04:00PM -0600, Grant Edwards wrote:

> > > I am having trouble creating a big endian image with the latest
> > > CVS version of mkfs.jffs2!
> [...]
> > > Both options -l _and_ -b result in the same byteorder!!!
> > 
> > Yup.  And it looks like it's still that way.  Oddly, a comment
> > at the top of the file says that cross-endian support has been
> > added, but it sure looks like "-l" and "-b" are just ignored.
> > 
> > I tried undefining JFFS2_NATIVE_ENDIAN and defining
> > JFFS2_BIG_ENDIAN, but then nothing builds.  (RH7.3 IA32 host)

Attached is a patch that makes the utils build properly if
JFFS2_BIG_ENDIAN is selected.  No idea if it breaks anything
else....

-- 
Grant Edwards
grante at visi.com

--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Description: bigendianutils.patch
Content-Disposition: attachment; filename="mtdutil.patch"

--- mtd-orig/include/linux/jffs2.h	Wed Jan 22 17:00:08 2003
+++ mtd/include/linux/jffs2.h	Fri Feb 14 17:17:12 2003
@@ -96,16 +96,21 @@
 #define cpu_to_je16(x) ((jint16_t){x})
 #define cpu_to_je32(x) ((jint32_t){x})
 #define cpu_to_jemode(x) ((jmode_t){os_to_jffs2_mode(x)})
 
 #define je16_to_cpu(x) ((x).v16)
 #define je32_to_cpu(x) ((x).v32)
 #define jemode_to_cpu(x) (jffs2_to_os_mode((x).m))
 #elif defined(JFFS2_BIG_ENDIAN)
+#include <netinet/in.h>
+#define cpu_to_be16(x) htons(x)
+#define cpu_to_be32(x) htonl(x)
+#define be16_to_cpu(x) ntohs(x)
+#define be32_to_cpu(x) ntohl(x)
 #define cpu_to_je16(x) ((jint16_t){cpu_to_be16(x)})
 #define cpu_to_je32(x) ((jint32_t){cpu_to_be32(x)})
 #define cpu_to_jemode(x) ((jmode_t){cpu_to_be32(os_to_jffs2_mode(x))})
 
 #define je16_to_cpu(x) (be16_to_cpu(x.v16))
 #define je32_to_cpu(x) (be32_to_cpu(x.v32))
 #define jemode_to_cpu(x) (be32_to_cpu(jffs2_to_os_mode((x).m)))
 #elif defined(JFFS2_LITTLE_ENDIAN)

--G4iJoqBmSsgzjUCe--

Problems with BIG_ENDIAN

[David Woodhouse]

On Fri, 2003-02-14 at 23:04, Grant Edwards wrote:
> On Fri, Feb 14, 2003 at 04:28:20PM -0600, Grant Edwards wrote:
> > On Sun, Dec 08, 2002 at 07:11:10PM +0100, Steven Scholz wrote:
> > 
> > > I am having trouble creating a big endian image with the latest
> > > CVS version of mkfs.jffs2!
> [...]
> > > Both options -l _and_ -b result in the same byteorder!!!
> > 
> > Yup.  And it looks like it's still that way.  Oddly, a comment
> > at the top of the file says that cross-endian support has been
> > added, but it sure looks like "-l" and "-b" are just ignored.

Looks like it got ripped out when I made the kernel code itself handle
variable endianness. Restored now.

> I'm having a go at fixing this, but I'm a bit confused by
> something in jffs2.h:
> 
>   /* Values we may expect to find in the 'magic' field */
>   #define JFFS2_OLD_MAGIC_BITMASK 0x1984
>   #define JFFS2_MAGIC_BITMASK 0x1985
>   #define KSAMTIB_CIGAM_2SFFJ 0x5981 /* For detecting wrong-endian fs */
> 
> Where does the value 0x5981 come from?  If the endian setting
> is wrong, the bytes within a 16 bit word are swapped and you
> see 0x8519 instead of 0x1985.

I plead stupidity. Fixed now too. Thanks for pointing it out.

-- 
dwmw2