MTD newbie

MTD newbie

[Cristiano Paris]

Hi everyone.

I have a question about the Linux MTD layer. I'm mainly interested in the
JFFS2 development and, as a private user, I cannot count on enterprise
level resources.

I own a iPAQ but I don't want to waste write operations to the Flash so
I'm looking for a way to mount and operate JFFS2 filesystems without a
flash.

I'm wondering if something like /dev/loop or /dev/ram can be used. At
first I decided to write an MTD interface to a virtual MTD device, but I
don't want to re-invent the wheel. Is anything like this out there ?

If not, I can write a new module.

Thanks

Cristiano

Re: MTD newbie

[David Woodhouse]

c.paris@libero.it said:
>  I'm wondering if something like /dev/loop or /dev/ram can be used. At
> first I decided to write an MTD interface to a virtual MTD device, but
> I don't want to re-invent the wheel. Is anything like this out there ?
> 

CONFIG_MTD_MTDRAM

--
dwmw2

Re: MTD newbie

[kira brown]

On Mon, 1 Oct 2001, Cristiano Paris wrote:

> I'm wondering if something like /dev/loop or /dev/ram can be used. At
> first I decided to write an MTD interface to a virtual MTD device, but I
> don't want to re-invent the wheel. Is anything like this out there ?

Yes.

There's an MTD driver that works from a block of RAM.

It's in the standard sources.

kira.

Re: MTD newbie

[Cristiano Paris]

Many thanks to all.

At the moment the jffs2 is unusable for me. I'm using linux-2.4.9-ac10 on
a Pentium166MMX notebook. I've tried to mount the task-familiar
distribution on /dev/mtdblock0. The mount works fine but when I try to
touch a file in the filesystem (say "touch /mnt/silly") the system just
hangs and a kernel oops appears.

touch seems to stop after perfoming a utime system call (open and close
worked fine) and the kernel provides the following backtrace :

- system_call
- sys_close
- filp_close
- sys_utime
- notify_change (setattr)
- jffs2_setattr
- jffs2_complete_reservation
- jffs2_garbage_collect_trigger
- <UNKNOWN>

The error is "Invald parameter 00000"; I'm trying to get the full OOPS
from a serial-line-attached console, so be patient. In addition I'm trying
to debug the error myself.

Maybe I'm using the wrong version of Linux or a more recent snapshot would
sove the problem.

Please, let me know. Thanks in advance, as usual.

Cristiano

MTD newbie

[Larry Doolittle]

Cristiano -

> At the moment the jffs2 is unusable for me. I'm using linux-2.4.9-ac10 on

The MTD/JFFS2 in that version dates back to about June 2001.
There have been big changes since then.  I'm at about the same
level of testing as you, but using the current CVS things seem
to basically work.  Dropping in the code from CVS takes a little
thought, but it only took me a couple of tries to get on the air.

Another approach is to apply a patch from Russell King, like
  ftp://ftp.arm.linux.org.uk/pub/linux/arm/source/kernel-patches/v2.4/patch-2.4.9-ac10-rmk2.gz

That one in particular looks like it takes you up to an early
September CVS snapshot of the MTD subsystem.

        - Larry

Re: MTD newbie

[David Woodhouse]

c.paris@libero.it said:
>  Maybe I'm using the wrong version of Linux or a more recent snapshot
> would sove the problem. 

Please see if you can reproduce in 2.4.10-ac3

--
dwmw2

Re: MTD newbie

[Cristiano Paris]

I've just finished compiling 2.4.10-ac3 and I've tried to mount the jffs2
volume as usual.

I've tried :

modprobe mtdcore
modprobe mtdram total_size=16384 erase_size=8
modprobe mtdblock
modprobe jffs2

mount -t jffs2 /task-familiar-etc /mnt

After that the system just hangs (no kernel ooops shown). David, have you
tried yourself with the mtdram fake device ?

Thanks

Cristiano

On Mon, 1 Oct 2001, David Woodhouse wrote:

>
> c.paris@libero.it said:
> >  Maybe I'm using the wrong version of Linux or a more recent snapshot
> > would sove the problem.
>
> Please see if you can reproduce in 2.4.10-ac3
>
> --
> dwmw2
>
>

Re: MTD newbie

[David Woodhouse]

c.paris@libero.it said:
> modprobe mtdcore 
> modprobe mtdram total_size=16384 erase_size=8
> modprobe mtdblock
> modprobe jffs2

> mount -t jffs2 /task-familiar-etc /mnt 

What is /task-familiar-etc? Did you mean:
 dd if=/task-familiar-etc of=/dev/mtdblock0
 mount -t jffs2 /dev/mtdblock0 /mnt

c.paris@libero.it said:
> After that the system just hangs (no kernel ooops shown). David, have
> you tried yourself with the mtdram fake device ? 

Yes, I've tested both JFFS and JFFS2 on the mtdram device with 2.4.10-ac1 
and the patch which Alan included into 2.4.10-ac3. Please could you compile 
with CONFIG_JFFS2_FS_DEBUG=1, set the loglevel to 9 by running the command
"echo 9 > /proc/sys/kernel/printk" and show me what it says?

--
dwmw2

Re: MTD newbie

[Cristiano Paris]

On Tue, 2 Oct 2001, David Woodhouse wrote:

> What is /task-familiar-etc? Did you mean:

task-familiar is a jffs2 image that can be dowload from
familiar.handhelds.org and contains a complete filesystem for the iPAQ
handhelds.

>  dd if=/task-familiar-etc of=/dev/mtdblock0

Why are you doing that ? I'm using 'cp' over /dev/mtd0 as said in the
mtd-jffs-HOWTO :

----QUOTE
cp  /tmp/jffs.image /dev/mtd0,1,2
----QUOTE

Actually 'dd' is a more flexible 'cp'. Anyway I tried both ways.

>  mount -t jffs2 /dev/mtdblock0 /mnt

Here's where I was wrong. The mount works but the system freezes for about
30 seconds (YUP) so I thought the system was hung. Anyway, issuing a
"touch /mnt/silly" crashes the system, giving me the same kernel oops. I
increased the debugging level of printk, as you adviced in your previous
post but I cannot post neither the debug messages nor the kernel oops
itself : tomorrow I will buy a NULL modem cable and I'll try to catch the
messages through the serial port.

Taking a look to the stack trace is giving me the impression that my last
backtrace was correct and the reason why this happens is always the same
"invalid operand".

Cristiano

Re: MTD newbie

[David Woodhouse]

c.paris@libero.it said:
>  The mount works but the system freezes for about 30 seconds (YUP) so
> I thought the system was hung. 

Yeah - checkpointing is on the TODO list along with some other ideas for 
speeding up mounts. Unfortunately I haven't yet found the time to do it, 
and nobody's yet talked nicely enough to the salespeople who control my
destiny that I've been given real time to do it :)

> Anyway, issuing a "touch /mnt/silly"
> crashes the system, giving me the same kernel oops.

Hmmm. Please get it fed through ksymoops and let me have a copy, along with 
the last few debugging messages before it died.

--
dwmw2

Re: MTD newbie

[Cristiano Paris]

Finally I got the debug message through the use of the netconsole kernel
module.

I must say that using erase_size=256 (same as my iPAQ's) works fine with
linux-2.4.10-ac3 : I can touch and modify any file in my jffs2 volume. The
following output comes after using erase_size=8, just before the command :

touch /mnt/pippo

is issued. Happy debugging :-)

Thanks David.

Cristiano

-------

netconsole: network logging started up successfully!
jffs2_lookup()
jffs2_create()
jffs2_reserve_space(): Requested 0x44 bytes
jffs2_reserve_space(): alloc sem got
jffs2_do_reserve_space(): Giving 0xfffffffc bytes at 0x206004
jffs2_create(): reserved 0xfffffffc bytes
jffs2_new_inode(): dir_i 1, mode 0x81a4
Allocated inocache at c0031ae0
jffs2_new_inode(): Assigned ino# 781
jffs2_add_ino_cache: Add c0031ae0 (ino #781)
ram_read(pos:2121732, len:16)
ARGH. About to write node to 0x00206004 on flash, but there's data already there:
0x00206004: 85 19 01 e0 33 00 00 00 96 11 8b e8 6b 02 00 00
ram_write(pos:2121732, len:68)
ram_write(pos:2121800, len:0)
jffs2_add_physical_node_ref(): Node at 0x206004, size 0x44
argh. node added in wrong place
jffs2_write_dnode wrote node at 0x00206004 with dsize 0x0, csize 0x0, node_crc 0xa20c9ed5, data_crc 0x00000000, totlen 0x00000044
jffs2_create created file with mode 0x81a4
jffs2_write_dirent(ino #1, name at *0xc24e779c "pippo"->ino #781, name_crc 0x193f3529)
ram_read(pos:2121800, len:16)
ARGH. About to write node to 0x00206048 on flash, but there's data already there:
0x00206048: 78 5e 94 53 3d 4b c4 40 10 1d 3f f1 03 f4 fc 16
ram_write(pos:2121800, len:40)
ram_write(pos:2121840, len:5)
jffs2_add_physical_node_ref(): Node at 0x206048, size 0x30
argh. node added in wrong place
jffs2_complete_reservation()
thread_should_wake(): nr_free_blocks 1399, nr_erasing_blocks 0, dirty_size 0xa2e50
jffs2_add_fd_to_list( c1497bc0, c366f188 (->c4f7dfc0))
Dirent "bin" (hash 0x0023605a, ino #211
Dirent "dev" (hash 0x0023ee05, ino #257
Dirent "etc" (hash 0x0024a603, ino #442
Dirent "lib" (hash 0x002697fa, ino #619
Dirent "mnt" (hash 0x00271d65, ino #612
Dirent "tmp" (hash 0x00295e98, ino #618
Dirent "var" (hash 0x0029ab98, ino #617
Dirent "usr" (hash 0x0029e101, ino #2
Dirent "home" (hash 0x019cc780, ino #609
Dirent "proc" (hash 0x01baa5b4, ino #610
Dirent "sbin" (hash 0x01c000e1, ino #399
Dirent "root" (hash 0x01c0d8cc, ino #615
Dirent "pippo" (hash 0x12e5c1b9, ino #781
Dirent "linuxrc" (hash 0xa2e02467, ino #611
Dirent ".ramfs.tar.gz" (hash 0xee261af5, ino #616
jffs2_create: Created ino #781 with mode 100644, nlink 1(1). nrpages 0
jffs2_setattr(): ino #781
jffs2_reserve_space(): Requested 0x44 bytes
jffs2_reserve_space(): alloc sem got
jffs2_do_reserve_space(): Giving 0xfffffffc bytes at 0x206004
ram_read(pos:2121732, len:16)
ARGH. About to write node to 0x00206004 on flash, but there's data already there:
0x00206004: 85 19 02 e0 44 00 00 00 1d fb f7 98 0d 03 00 00
ram_write(pos:2121732, len:68)
ram_write(pos:2121800, len:0)
jffs2_add_physical_node_ref(): Node at 0x206004, size 0x44
argh. node added in wrong place
jffs2_write_dnode wrote node at 0x00206004 with dsize 0x0, csize 0x0, node_crc 0xdc74d673, data_crc 0x00000000, totlen 0x00000044
jffs2_complete_reservation()
thread_should_wake(): nr_free_blocks 1399, nr_erasing_blocks 0, dirty_size 0xa2e50
Calculated used size 0000212c != stored used size 000020e8
invalid operand: 0000
CPU:    0
EIP:    0010:[<c693f2f0>]    Not tainted
EFLAGS: 00010286
eax: 0000003e   ebx: c12c2878   ecx: 00000001   edx: 00000001
esi: c30804e8   edi: c02d4ce8   ebp: c393b580   esp: c38b7edc
ds: 0018   es: 0018   ss: 0018
Process touch (pid: 251, stackpage=c38b7000)
Stack: c6947560 0000212c 000020e8 c0378100 c0022790 c35383c0 c0022780 c02d4ce8
       c30804e8 c693f175 c30804e8 c69475a0 c693d0a0 c30804e8 c393b580 c38b7fa4
       c35383c0 c38b7f7c 00000070 00000044 00000000 00000000 c30804e8 c35384e8
Call Trace: [<c6947560>] [<c693f175>] [<c69475a0>] [<c693d0a0>] [<c013e2a0>]
   [<c012af13>] [<c012baac>] [<c012baf7>] [<c0106d83>]

Code: 0f 0b 83 c4 3b 5e 78 75 8b 43 0c 50 68 40 77 94 c6 eb
 <0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

Re: MTD newbie

[David Woodhouse]

> netconsole: network logging started up successfully!
> jffs2_lookup()
> jffs2_create()
> jffs2_reserve_space(): Requested 0x44 bytes
> jffs2_reserve_space(): alloc sem got
> jffs2_do_reserve_space(): Giving 0xfffffffc bytes at 0x206004

It's already broken by this point. The free space in this block is -4 bytes. 
Can you start the console logging before mounting the filesystem?

--
dwmw2