JFFS2 on Lite5200

JFFS2 on Lite5200

[Andrea Galbusera]

Hello.

I'm currently using linux-2.6.16 from denx on a Lite5200 V2.0. I need to
access a JFFS2 filesystem on the onboard flash ( 16MB Am29L652D ).

I see the flash using physmap driver and cmdline partitions.
I experience a problem when creating files on JFFS2 with filename longer
than a few characters. They appear to be created correctly with the
content I want, but, after unmounting and remounting the filesystem they
result unreadable and ls complains with "no such file or
directory" (short-named files are ok).

I can deterministically reproduce the problem this way:

$ eraseall /dev/mtd1	(start with a fresh MTD partition)
$ mount -t jffs2 /dev/mtdblock1 /mnt/flash
$ date > /mnt/flash/short
$ date > /mnt/flash/timestamp
$ ls /mnt/flash/
short  timestamp
$ umount /dev/mtdblock1
$ mount -t jffs2 /dev/mtdblock1 /mnt/flash
$ ls /mnt/flash
ls: /mnt/flash/time: No such file or directory
short

...than I cannot access /mnt/flash/timestamp anymore,
while /mnt/flash/short is ok!

These are the kernel relevant settings:

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=0
CONFIG_MTD_CFI_UTIL=y

#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0xff000000
CONFIG_MTD_PHYSMAP_LEN=0x01000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=1

#
# Miscellaneous filesystems
#
CONFIG_JFFS_FS=y
CONFIG_JFFS_FS_VERBOSE=0
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=2
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y


I enabled both MTD and JFFS2 maximum verbosity debug messages. If
relevant, I can post them for any of the commands in the sequence. Btw I
have the same problem with crafted filesystem images built with
mkfs.jffs2 (they fail at first mount).

Trying to exclude MTD issues I tested the same with JFFS and I don't
have any problem, but JFFS is not suitable for my needs :-(

By digging the net, I can't find any reference to this problem. Hope
anybody out there is using this setup (lite5200_defconfig as MTD
disabled) and can help. TIA.

Regards,
Andrea

Re: JFFS2 on Lite5200

[Andrey Volkov]

Hello Andrea,

Andrea Galbusera wrote:
> Hello.
> 
> I'm currently using linux-2.6.16 from denx on a Lite5200 V2.0. I need to
> access a JFFS2 filesystem on the onboard flash ( 16MB Am29L652D ).
> 
> I see the flash using physmap driver and cmdline partitions.
> I experience a problem when creating files on JFFS2 with filename longer
> than a few characters. They appear to be created correctly with the
> content I want, but, after unmounting and remounting the filesystem they
> result unreadable and ls complains with "no such file or
> directory" (short-named files are ok).
--snip--

OMG, again same question,

Andrea, check ml archive, I already sent patch half-year ago
(http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022566.html)
Problem is in alignment/memcpy: JFFS2 code assumed that memory at
unaligned addresses could be touched, but access to an external MMIO
on MPC5200 _must_ be aligned (i.e. you could not read u32 from odd address).

P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
how about to fix scan.c?

--
Regards
Andrey

Re: JFFS2 on Lite5200

[Artem Bityutskiy]

On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
> how about to fix scan.c?

Andrey,

I am not JFFS2 maintainer, David Woodhouse is.

Just looked into your patch. I agree that it may make sense to teach
JFFS2 to use only aligned addresses, but your patch changes
include/asm-ppc/io.h which is probably not MTD's business. It probably
makes sense to submit these changes to a PPC maintainer separately.

A question - does this mean that one can write only 4-byte chunks to
this NOR (?) flash?

--=20
Best regards,
Artem Bityutskiy (=D0=91=D0=B8=D1=82=D1=8E=D1=86=D0=BA=D0=B8=D0=B9 =D0=90=
=D1=80=D1=82=D1=91=D0=BC)

Re: JFFS2 on Lite5200

[Andrey Volkov]

Artem Bityutskiy wrote:
> On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
>> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
>> how about to fix scan.c?
> 
> Andrey,
> 
> I am not JFFS2 maintainer, David Woodhouse is.
Ok, I'll keep it in mind.

> 
> Just looked into your patch. I agree that it may make sense to teach
> JFFS2 to use only aligned addresses, but your patch changes
> include/asm-ppc/io.h which is probably not MTD's business. 
> It probably
> makes sense to submit these changes to a PPC maintainer separately.
> 
> A question - does this mean that one can write only 4-byte chunks to
> this NOR (?) flash?
> 
No, MPC5200 could write any size chunks, but it must be aligned (same
restrictions as in SH4), and this restriction applied only to LPB, but
not SDRAM.

Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
functions which MTD drivers exported, but jffs2_scan_dirent_node and
friends - doesn't.

Andrey

Re: JFFS2 on Lite5200

[David Woodhouse]

On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
> No, MPC5200 could write any size chunks, but it must be aligned (same
> restrictions as in SH4), and this restriction applied only to LPB, but
> not SDRAM.
> 
> Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
> functions which MTD drivers exported, but jffs2_scan_dirent_node and
> friends - doesn't.

There are two modes of operation for JFFS2 scan. Either it can use the
MTD device's read() function to read from the flash into memory and scan
from there, or -- IF the flash can be accessed as if it were normal
memory -- it can use the point() method and skip the read() call by
using a pointer directly into the flash.

In your case, the flash cannot be accessed directly as if it were normal
memory. So your map driver probably shouldn't be allowing point() to
succeed.

Having said that, I'm not entirely sure we have the code set up so that
'simple' map drivers _can_ prevent point(). We may need to fix that.

-- 
dwmw2

Re: JFFS2 on Lite5200

[Andrey Volkov]

David Woodhouse wrote:
> On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
>> No, MPC5200 could write any size chunks, but it must be aligned (same
>> restrictions as in SH4), and this restriction applied only to LPB, but
>> not SDRAM.
>>
>> Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
>> functions which MTD drivers exported, but jffs2_scan_dirent_node and
>> friends - doesn't.
> 
> There are two modes of operation for JFFS2 scan. Either it can use the
> MTD device's read() function to read from the flash into memory and scan
> from there, or -- IF the flash can be accessed as if it were normal
> memory -- it can use the point() method and skip the read() call by
> using a pointer directly into the flash.
> 
> In your case, the flash cannot be accessed directly as if it were normal
> memory. So your map driver probably shouldn't be allowing point() to
> succeed.
> 
> Having said that, I'm not entirely sure we have the code set up so that
> 'simple' map drivers _can_ prevent point(). We may need to fix that.
David, thanks for an explanations (Artem already pointed me to this
jffs2 behavior).

--
Regards
Andrey

Re: JFFS2 on Lite5200

[Artem Bityutskiy]

On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> Andrea, check ml archive, I already sent patch half-year ago
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022566.html)
> Problem is in alignment/memcpy: JFFS2 code assumed that memory at
> unaligned addresses could be touched, but access to an external MMIO
> on MPC5200 _must_ be aligned (i.e. you could not read u32 from odd addres=
s).
>=20
> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
> how about to fix scan.c?

Just talked to David. Please, find the result of our discussion in my
edition below.

Strictly speaking, JFFS2 *does not* do anything wrong, so it should not
be fixed. Indeed, JFFS2 does have full right to use memcpy() for that.

The question is: does memcpy() make sense for flash adresses at your
board? Is it a valid operation for flash addresses at your board?

If the answer is yes - then please fix memcpy() for your platform.

If no - then please, do not pretend that your flash may be treated as
memory and fix your platform MTD driver. Namely, set point()/unpoint()
to NULL in your mapping driver - JFFS2 should work then.

--=20
Best regards,
Artem Bityutskiy (=D0=91=D0=B8=D1=82=D1=8E=D1=86=D0=BA=D0=B8=D0=B9 =D0=90=
=D1=80=D1=82=D1=91=D0=BC)

Re: JFFS2 on Lite5200

[Wolfgang Denk]

In message <1161081183.22948.58.camel@localhost.localdomain> you wrote:
> 
> I'm currently using linux-2.6.16 from denx on a Lite5200 V2.0. I need to
> access a JFFS2 filesystem on the onboard flash ( 16MB Am29L652D ).

We do NOT support the MPC5200 in the context of this kernel tree yet.

For the MPC5200, we still recommend  to  use  the  linuxppc_2_4_devel
tree.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The whole problem with the world is  that  fools  and  fanatics  are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell