Mounting big endian jffs2 images on mtdram on a x86

Mounting big endian jffs2 images on mtdram on a x86

[Hans-Christian Egtvedt]

Hello,

I am trying to mount an JFFS2 image made with mkfs.jffs2 on my x86
laptop. The image is made with --big-endian set.

I do the following:
modprobe mtdram total_size=8192 erase_size=64
modprobe mtdchar
modprobe mtdblock
modprobe jffs2
dd if=jffs2.image of=/dev/mtd0
mount -t jffs2 /dev/mtdblock0 /some/mount/point

And I get:
mount: /dev/mtdblock0: can't read superblock

AFAIK this is related to the image being big endian, while my computer
is little endian. The JFFS2 image is valid when I program it into flash
and mount it on my embedded system.

Any hints, tips, how-to's or similar? I have tried google without much
luck.

-- 
Best regards
Hans-Christian Egtvedt

Re: Mounting big endian jffs2 images on mtdram on a x86

[Artem Bityutskiy]

On Mon, 2007-05-14 at 11:05 +0200, Hans-Christian Egtvedt wrote:
> Hello,
> 
> I am trying to mount an JFFS2 image made with mkfs.jffs2 on my x86
> laptop. The image is made with --big-endian set.

I think you cannot do this without re-compiling JFFS2. I am not sure,
just glance to the code (to je32_to_cpu and the like macros).

> I do the following:
> modprobe mtdram total_size=8192 erase_size=64
> modprobe mtdchar
> modprobe mtdblock
> modprobe jffs2
> dd if=jffs2.image of=/dev/mtd0
> mount -t jffs2 /dev/mtdblock0 /some/mount/point

FYI, mtdblock is not needed and is ancient and confusing way to mount
jffs2. 

http://www.linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Mounting big endian jffs2 images on mtdram on a x86

[Haavard Skinnemoen]

On Mon, 14 May 2007 13:34:52 +0300
Artem Bityutskiy <dedekind@infradead.org> wrote:

> FYI, mtdblock is not needed and is ancient and confusing way to mount
> jffs2. 
> 
> http://www.linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock

Btw, newer versions of busybox seem to be able to mount jffs2
filesystems without using mtdblock.

~ # mount -tjffs2 mtd3 /usr
~ # umount /usr
~ # mount -tjffs2 mtd:spi0.0-AT45DB642x /usr
~ # ls -l /bin/mount
lrwxrwxrwx    1 root     root            7 Apr 17  2007 /bin/mount -> busybox
~ # busybox
BusyBox v1.4.2 (2007-04-17 15:34:55 CEST) multi-call binary

Haavard

Re: Mounting big endian jffs2 images on mtdram on a x86

[Hans-Christian Egtvedt]

On Mon, 2007-05-14 at 13:34 +0300, Artem Bityutskiy wrote:
> On Mon, 2007-05-14 at 11:05 +0200, Hans-Christian Egtvedt wrote:
> > Hello,
> > 
> > I am trying to mount an JFFS2 image made with mkfs.jffs2 on my x86
> > laptop. The image is made with --big-endian set.
> 
> I think you cannot do this without re-compiling JFFS2. I am not sure,
> just glance to the code (to je32_to_cpu and the like macros).

Oki, then I at least know where to look. It would have been a nice
feature to add support for choosing endianess when loading the module.

I would not recommend customers or less experienced Linux people to
recompile one of their kernel modules to support big endian JFFS2
images.

<cut jffs2 image mounting>

> > mount -t jffs2 /dev/mtdblock0 /some/mount/point
> 
> FYI, mtdblock is not needed and is ancient and confusing way to mount
> jffs2. 
> 
> http://www.linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock

Oh, thanks, and as Håvard stated it is also supported in the latest
busybox.

-- 
Mvh
Hans-Christian Egtvedt

Re: Mounting big endian jffs2 images on mtdram on a x86

[Josh Boyer]

On Mon, 2007-05-14 at 16:37 +0200, Hans-Christian Egtvedt wrote:
> On Mon, 2007-05-14 at 13:34 +0300, Artem Bityutskiy wrote:
> > On Mon, 2007-05-14 at 11:05 +0200, Hans-Christian Egtvedt wrote:
> > > Hello,
> > > 
> > > I am trying to mount an JFFS2 image made with mkfs.jffs2 on my x86
> > > laptop. The image is made with --big-endian set.
> > 
> > I think you cannot do this without re-compiling JFFS2. I am not sure,
> > just glance to the code (to je32_to_cpu and the like macros).
> 
> Oki, then I at least know where to look. It would have been a nice
> feature to add support for choosing endianess when loading the module.
> 
> I would not recommend customers or less experienced Linux people to
> recompile one of their kernel modules to support big endian JFFS2
> images.

Ideally, we would have the capability for doing a -o loop mount of
jffs2.  Requiring a device to shove the data in sucks.  If this ever
materializes, we should add an endian-ness parameter to it to
automatically do some mapping.

josh

Re: Mounting big endian jffs2 images on mtdram on a x86

[David Woodhouse]

On Mon, 2007-05-14 at 13:34 +0300, Artem Bityutskiy wrote:
> 
> > I am trying to mount an JFFS2 image made with mkfs.jffs2 on my x86
> > laptop. The image is made with --big-endian set.
> 
> I think you cannot do this without re-compiling JFFS2. I am not sure,
> just glance to the code (to je32_to_cpu and the like macros).

Edit fs/jffs2/nodelist.h and set JFFS2_BIG_ENDIAN instead of
JFFS2_NATIVE_ENDIAN.

The reason it's not a runtime option is because that would be quite
slow, and it's a very esoteric feature.

I'm sorry. I should have just made it either big- or little-endian right
from the very beginning and never made the mistake of letting it be
host-endian.

-- 
dwmw2

Re: Mounting big endian jffs2 images on mtdram on a x86

[Hans-Christian Egtvedt]

On Tue, 2007-05-15 at 08:42 +0800, David Woodhouse wrote:
> On Mon, 2007-05-14 at 13:34 +0300, Artem Bityutskiy wrote:
> > 
> > > I am trying to mount an JFFS2 image made with mkfs.jffs2 on my x86
> > > laptop. The image is made with --big-endian set.
> > 
> > I think you cannot do this without re-compiling JFFS2. I am not sure,
> > just glance to the code (to je32_to_cpu and the like macros).
> 
> Edit fs/jffs2/nodelist.h and set JFFS2_BIG_ENDIAN instead of
> JFFS2_NATIVE_ENDIAN.

Ah, thanks for this hint.

> The reason it's not a runtime option is because that would be quite
> slow, and it's a very esoteric feature.

For development systems it would be a great feature, hence my original
email. But for an embedded system this should not be present at all.

> I'm sorry. I should have just made it either big- or little-endian right
> from the very beginning and never made the mistake of letting it be
> host-endian.

What I would have liked was a possibility to choose which read/write
operations should be used when using my developing machine, but for the
kernel I boot my embedded target with I would like an optimized jffs2
driver.

Use native endianess by default, but have a possibility to override at
runtime.

</thoughts>

-- 
Best regards
Hans-Christian Egtvedt

Re: Mounting big endian jffs2 images on mtdram on a x86

[Artem Bityutskiy]

On Tue, 2007-05-15 at 09:45 +0200, Hans-Christian Egtvedt wrote:
> For development systems it would be a great feature, hence my original
> email. But for an embedded system this should not be present at all.

Sorry, I did not find an explanation what for do you need different
endianess? Why not just to live with the default one?

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Mounting big endian jffs2 images on mtdram on a x86

[David Woodhouse]

On Tue, 2007-05-15 at 09:45 +0200, Hans-Christian Egtvedt wrote:
> What I would have liked was a possibility to choose which read/write
> operations should be used when using my developing machine, but for
> the kernel I boot my embedded target with I would like an optimized
> jffs2 driver.
> 
> Use native endianess by default, but have a possibility to override at
> runtime.

I suppose I wouldn't be _entirely_ averse to a 'JFFS2_BI_ENDIAN' option
which stores a flag in the jffs2_sb_info. It means we need an extra
argument je32_to_cpu() et al., but that isn't particularly evil.

-- 
dwmw2

Re: Mounting big endian jffs2 images on mtdram on a x86

[Hans-Christian Egtvedt]

On Tue, 2007-05-15 at 10:50 +0300, Artem Bityutskiy wrote:
> On Tue, 2007-05-15 at 09:45 +0200, Hans-Christian Egtvedt wrote:
> > For development systems it would be a great feature, hence my original
> > email. But for an embedded system this should not be present at all.
> 
> Sorry, I did not find an explanation what for do you need different
> endianess? Why not just to live with the default one?

I have a x86 laptop which i use for building my images, and deploy them
to an AVR32 system. Little endian vs. big endian.

Sometimes I would like to mount my jffs2 images to do some minor
modifications, fetch lost files, or if I receive an image from somebody
else.

-- 
Mvh
Hans-Christian Egtvedt

Re: Mounting big endian jffs2 images on mtdram on a x86

[MikeW]

Hans-Christian Egtvedt <hcegtvedt <at> norway.atmel.com> writes:

> 
> Ah, thanks for this hint.
> 
> > The reason it's not a runtime option is because that would be quite
> > slow, and it's a very esoteric feature.
> 
> For development systems it would be a great feature, hence my original
> email. But for an embedded system this should not be present at all.
> 
> > I'm sorry. I should have just made it either big- or little-endian right
> > from the very beginning and never made the mistake of letting it be
> > host-endian.
> 
> What I would have liked was a possibility to choose which read/write
> operations should be used when using my developing machine, but for the
> kernel I boot my embedded target with I would like an optimized jffs2
> driver.
> 
> Use native endianess by default, but have a possibility to override at
> runtime.
> 
> </thoughts>
> 

(I guess you could have both be- and le- drivers present in your dev system
as long as they had different naming, so you could  mount -t jffs2.be / .le
as required.)

Since this is a development-only requirement, there is no need to make
a generic read-everything upgrade for JFFS2 which would then slug the
performance of the standard build. Keep this option as a nonstandard
recompile option, and let the native versions use their native byte ordering.

Regards,
MikeW

Re: Mounting big endian jffs2 images on mtdram on a x86

[Hans-Christian Egtvedt]

On Wed, 2007-05-16 at 07:45 +0000, MikeW wrote:
> Hans-Christian Egtvedt <hcegtvedt <at> norway.atmel.com> writes:

<cut thoughts about bi-endian JFFS2>

> (I guess you could have both be- and le- drivers present in your dev system
> as long as they had different naming, so you could  mount -t jffs2.be / .le
> as required.)

Yes, very nice solution for developers.

> Since this is a development-only requirement, there is no need to make
> a generic read-everything upgrade for JFFS2 which would then slug the
> performance of the standard build. Keep this option as a nonstandard
> recompile option, and let the native versions use their native byte ordering.

Agree, but I would like this to be an option when building the kernel.
So distributions can choose to have this feature or not. I for example
use Ubuntu, and would be thrilled if the upstream Ubuntu kernel was
shipped with jffs2, jffs2.le and jffs2.be modules.

Perhaps just a define in Kconfig which will build the two extra
endianess specific modules.

-- 
With kind regards,

Hans-Christian Egtvedt, siv.ing. (M.Sc.)
Applications Engineer - AVR32 System Solutions - Atmel Norway