why MTD model ?

why MTD model ?

[Studying MTD]

hi all,

i am curious why we need MTD model ?

Can we use ordinary linux driver model for memory
devices ?

Thank you for your help.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: why MTD model ?

[David Woodhouse]

studying_mtd@yahoo.com said:
>  i am curious why we need MTD model ?
> Can we use ordinary linux driver model for memory devices ?

To what 'ordinary Linux driver model' are you referring?

--
dwmw2

Re: why MTD model ?

[Studying MTD]

Can somehow we treat(emulate) memory device as a block
device and treat memory device like a hard disk ?

--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> studying_mtd@yahoo.com said:
> >  i am curious why we need MTD model ?
> > Can we use ordinary linux driver model for memory
> devices ?
> 
> To what 'ordinary Linux driver model' are you
> referring?
> 
> --
> dwmw2
> 
> 
> 
>
______________________________________________________
> Linux MTD discussion mailing list
>
http://lists.infradead.org/mailman/listinfo/linux-mtd/


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

RE: why MTD model ?

[Gregg C Levine]

Hello from Gregg C Levine
As I understand the whole notion behind the MTD collection, the Disk On
Chip devices, corresponds to what you are thinking of. However there is
a module which allows ordinary machine memory to be used for the same
purpose as another MTD array, for testing an application. Please note
that I have not tested any of these theories, nor actually seen a DOC in
action. (A board running, but booting from a DOC, as opposed to other
hardware.)
-------------------
Gregg C Levine hansolofalcon@worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org [mailto:linux-mtd-
> admin@lists.infradead.org] On Behalf Of Studying MTD
> Sent: Thursday, June 13, 2002 12:19 PM
> To: David Woodhouse
> Cc: linux-mtd
> Subject: Re: why MTD model ?
> 
> Can somehow we treat(emulate) memory device as a block
> device and treat memory device like a hard disk ?
> 
> --- David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > studying_mtd@yahoo.com said:
> > >  i am curious why we need MTD model ?
> > > Can we use ordinary linux driver model for memory
> > devices ?
> >
> > To what 'ordinary Linux driver model' are you
> > referring?
> >
> > --
> > dwmw2
> >
> >
> >
> >
> ______________________________________________________
> > Linux MTD discussion mailing list
> >
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Howto create a new jffs2

[Krypton]

I added my new 'test' MTD partition.
I'd like to add a new little home.jffs2
How can I mount a new little jffs2 partition when I have 
linux prompt ?
Thank you  

Creating 5 MTD partitions on "SA1100 flash":

0x00000000-0x00020000 : "firmware"

0x00020000-0x00040000 : "params"

0x00040000-0x00140000 : "kernel"

0x00140000-0x00fe0000 : "rootdisk"

0x00fe0000-0x01000000 : "test"

RE: Howto create a new jffs2

[Steve Tsai]

Try, mount -t jffs2 /dev/mtdblock4 <dir>

Steve Tsai

-----Original Message-----
From: linux-mtd-admin@lists.infradead.org
[mailto:linux-mtd-admin@lists.infradead.org] On Behalf Of Krypton
Sent: Friday, June 14, 2002 1:13 AM
To: linux-mtd@lists.infradead.org
Subject: Howto create a new jffs2


I added my new 'test' MTD partition.
I'd like to add a new little home.jffs2
How can I mount a new little jffs2 partition when I have 
linux prompt ?
Thank you  

Creating 5 MTD partitions on "SA1100 flash":

0x00000000-0x00020000 : "firmware"

0x00020000-0x00040000 : "params"

0x00040000-0x00140000 : "kernel"

0x00140000-0x00fe0000 : "rootdisk"

0x00fe0000-0x01000000 : "test"


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Problem putting JFFS on MTD

[Clifford Loo]

Hi all,

I'm developing a disk-less embedded Linux system on the Motorola MPC823e,
with 16MB RAM, 8MB (32-bit data width) flash for holding the
boot/kernel/ramdisk images, and 4MB (16-bit) flash for JFFS.

I'm following the instructions on "mtd-jffs-HOWTO.txt" to set up MTD and
JFFS.  The system boots up fine and can even detect the 4MB flash, but
gives error when I try to mount the mtdblock device, or when I try to copy
a JFFS image file (created using mkfs.jffs) to the mtd char device.

The errors are, respectively:
mount: /dev/mtdblock0 has wrong device number or fs type jffs not supported
and
cp: cannot create regular file `/dev/mtd0': No such device

The following is a transcript:

--------------------------------------------------------------------------
PPCBoot 1.1.0 (Jun 11 2002 - 14:14:36)

CPU:   PPC823EZTnnB2 at 50 MHz: 16 kB I-Cache 8 kB D-Cache
Board: E-BOOK By HKPC. Ver1
DRAM:  16 MB
FLASH:  8 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 02840000 ...
   Image Name:   2.4.4 for E-BOOK(HKPC) ALPS
   Created:      2002-06-13   2:58:35 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    524166 Bytes = 511 kB = 0 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02940000 ...
   Image Name:   Simple Ramdisk Image
   Created:      2002-06-13   1:57:49 UTC
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    2104177 Bytes = 2054 kB = 2 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 00dad000, end 00faeb71 ... OK
Linux version 2.4.4 (kfloo@cliffordux.hkpc.org) (gcc version 2.95.2
19991024 (release)) #26 Thu Jun 13 10:57:01 HKT 2002
MPC823 LCD memory at C016C000
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=: ip=::::::off
Decrementer Frequency: 3125000
Console: colour dummy device 640x480
Calibrating delay loop... 49.86 BogoMIPS
Memory: 11692k available (956k kernel code, 408k data, 64k init, 0k
highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
Console: switching to colour frame buffer device 80x30
fb0:  MPC823 LCD frame buffer device
CPM UART driver version 0.03
ttyS0 on SMC1 at 0x0280, BRG1
pty: 256 Unix98 ptys configured
spp succeeded
reloc, spi_rpbase=440
spp = ff002440
initialized the parameter ram
spi_init succeeded
Ebook(HKPC) TPANEL v.1.0 driver installed
Found 2x16bit 8MByte CFI flash device of type AMD/Fujitsu standard at
2800000
Registered flash device /dev/flasha (minor 0, 3 partitions)
block: queued sectors max/low 7648kB/2549kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 4194302k freed
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
[HKPC] init_mtd() called
[HKPC] create_proc_entry() returned 0xc0d93f20
physmap flash device: 400000 at 3800000
Physically mapped flash: Found a CFI device at 0x0 in 16 bit mode
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 16 5s
Maximum byte/word write timeout: 512 5s
Full buffer write not supported
Typical block erase timeout: 1024 5s
Maximum block erase timeout: 16384 5s
Chip erase not supported
Device size: 0x400000 bytes (4 Mb)
Flash Device Interface description: 0x0002
  - supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 2
  Erase Region #0: BlockSize 0x2000 bytes, 8 blocks
  Erase Region #1: BlockSize 0x10000 bytes, 63 blocks

 Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
mtd: Giving out device 0 to Physically mapped flash
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).

### Initial RAM disk starting interactive shell ###
bash# cp jffs.image /dev/mtd0
cp: cannot create regular file `/dev/mtd0': No such device
bash# mount -t jffs /dev/mtdblock0 /mnt/jffs
mount: /dev/mtdblock0 has wrong device number or fs type jffs not
supported
bash# ls -l
total 26
drwxr-xr-x   2 0        0            1024 Jun 11  2002 bin
drwxr-xr-x   2 0        0            9216 Jun 11  2002 dev
drwxr-xr-x   2 0        0            1024 Mar  5  2002 etc
drwxr-xr-x   2 0        0            1024 May 29  2002 home
-rw-r--r--   1 500      100          5480 Jun 13  2002 jffs.image
drwxr-xr-x   2 0        0            1024 Feb 18  2002 lib
-rwxr-xr-x   1 0        0             136 Jan 11  1999 linuxrc
drwxr-xr-x   3 0        0            1024 Jun 11  2002 mnt
drwxr-xr-x   4 0        0            1024 Mar  5  2002 mw
drwxr-xr-x   2 0        0            1024 Jan 18  2002 proc
drwxr-xr-x   2 0        0            1024 Jun 11  2002 sbin
drwxr-xr-x   2 0        0            1024 Feb 23  2002 tmp
drwxr-xr-x   4 0        0            1024 Feb 27  2002 usr
bash# ls -l /dev/mtd*
crw-r--r--   1 0        0         90,   0 Jun 11  2002 /dev/mtd0
crw-r--r--   1 0        0         90,   2 Jun 11  2002 /dev/mtd1
crw-r--r--   1 0        0         90,   4 Jun 11  2002 /dev/mtd2
crw-r--r--   1 0        0         90,   6 Jun 11  2002 /dev/mtd3
crw-r--r--   1 0        0         90,   8 Jun 11  2002 /dev/mtd4
crw-r--r--   1 0        0         90,  10 Jun 11  2002 /dev/mtd5
brw-r--r--   1 0        0         31,   1 Jun 11  2002 /dev/mtdblock1
brw-r--r--   1 0        0         31,   2 Jun 11  2002 /dev/mtdblock2
brw-r--r--   1 0        0         31,   3 Jun 11  2002 /dev/mtdblock3
brw-r--r--   1 0        0         31,   4 Jun 11  2002 /dev/mtdblock4
brw-r--r--   1 0        0         31,   5 Jun 11  2002 /dev/mtdblock5
brw-r--r--   1 0        0         31,   6 Jun 11  2002 /dev/mtdblock6
bash# ls -la /proc
total 2
drwxr-xr-x   2 0        0            1024 Jan 18  2002 .
drwxr-xr-x  13 0        0            1024 Jun 13  2002 ..
bash#
--------------------------------------------------------------------------

One peculiar thing I notice is that, even though the mtd device number (0)
has been assigned, the "/proc" directory remains empty---I'm not able to
see the registered chip(s) by looking at "/proc/mtd".  Could that be
indicative of the cause of the problem?  Any help/insights will be much
appreciated.

--
Clifford

Re: Problem putting JFFS on MTD

[David Woodhouse]

kfloo@hkpc.org said:
> mount: /dev/mtdblock0 has wrong device number or fs type jffs not
> supported and cp: cannot create regular file `/dev/mtd0': No such
> device 

I'd strongly recommend using JFFS2, not JFFS. Do you definitely have the 
/dev/mtd* device nodes and CONFIG_MTD_BLOCK and CONFIG_MTD_CHAR?

--
dwmw2

Re: Problem putting JFFS on MTD

[Clifford Loo]

On Fri, 14 Jun 2002, David Woodhouse wrote:
>
>kfloo@hkpc.org said:
>> mount: /dev/mtdblock0 has wrong device number or fs type jffs not
>> supported and cp: cannot create regular file `/dev/mtd0': No such
>> device
>
>I'd strongly recommend using JFFS2, not JFFS.

Yes, I was thinking of migrating to JFFS2 after successfully setting up
JFFS which, unlike JFFS2, comes with my distribution of Linux for PPC.

> Do you definitely have the
>/dev/mtd* device nodes and CONFIG_MTD_BLOCK and CONFIG_MTD_CHAR?

Thanks for pointing this out.  I had made the device nodes with MAKEDEV so
that was no problem; but the CONFIG_MTD_* flags were the missing link
(and they were not mentioned in the only documentation I find, the
"mtd-jffs-HOWTO.txt").

I can now mount an erased mtdblock device directly to "/mnt/jffs".  But
creating files or directories results in I/O errors:

----------------------------------------------------------------------------
bash# cp /linuxrc /mnt/jffs/testfile.txt
jffs_lookup(): dir: 0xc0ef0980, name: "testfile.txt"
lookup(): down biglock
jffs_find_child()
jffs_find_child(): Didn't find the file "testfile.txt".
jffs_lookup(): Couldn't find the file. f = 0x00000000, name =
"testfile.txt", d = 0xc0daef40, d->ino = 1
lookup(): up biglock
jffs_create(): dir: 0xc0ef0980, name: "testfile.txt"
create(): down biglock
jffs_write_node(): filename = "testfile.txt", ino = 5, total_size = 72
jffs_fmalloc(): fmc = 0xc0daeec0, size = 72, node = 0xc0da1810
Free size accounting screwed
free_chunk_size1 == 0x3fff4c, free_chunk_size2 == 0x0, fmc->free_size ==
0x3fff38jffs_fmalloc(): free_chunk_size1 = 4194124, free_chunk_size2 = 0
struct jffs_fmcontrol: 0xc0daeec0
{
        0x00000000, /* flash_start  */
        4194304, /* flash_size  */
        72, /* used_size  */
        180, /* dirty_size  */
        4194032, /* free_size  */
        131072, /* sector_size  */
        262144, /* min_free_size  */
        65536, /* max_chunk_size  */
        0xc0d91da0, /* mtd  */
        0xc0da0620, /* head  */    (head->offset = 0x00000000)
        0xc0da0540, /* tail  */    (tail->offset + tail->size =
0x000000fc)
        0x00000000, /* head_extra  */
        0x00000000, /* tail_extra  */
}
struct jffs_fm: 0xc0da0540
{
       0x000000b4, /* offset  */
       72, /* size  */
       0xc0da07e0, /* prev  */
       0x00000000, /* next  */
       0xc0da0aa0, /* nodes  */
}
, result: 0x00000000
, result: 0x000004ee
, result: 0x00000bd7
jffs_write_node(): About to write this raw inode to the flash at pos 0xb4:
jffs_raw_inode: inode number: 5
{
        0x34383931, /* magic  */
        0x00000005, /* ino  */
        0x00000001, /* pino  */
        0x00000001, /* version  */
        0x00008180, /* mode  */
        0x0000,     /* uid  */
        0x0000,     /* gid  */
        0xbfedf85a, /* atime  */
        0xbfedf85a, /* mtime  */
        0xbfedf85a, /* ctime  */
        0x00000000, /* offset  */
        0x00000000, /* dsize  */
        0x00000000, /* rsize  */
        0x0c,       /* nsize  */
        0x01,       /* nlink  */
        0x00,       /* spare  */
        0,          /* rename  */
        0,          /* deleted  */
        0xff,       /* accurate  */
        0x00000000, /* dchksum  */
        0x04ee,     /* nchksum  */
        0x0bd7,     /* chksum  */
}
Didn't write all bytes in flash_safe_write(). Returned -5
***jffs_fmfree_partly(): fm = 0xc0da0540, fm->nodes = 0xc0da0aa0,
fm->nodes->node->ino = 10, size = 12
JFFS: jffs_write_node: Failed to write raw_inode.
jffs_create(): jffs_write_node() failed.
create(): up biglock
cp: cannot create regular file `/mnt/jffs/testfile.txt': I/O error

----------------------------------------------------------------------------
bash# mkdir /mnt/jffs/testdir
jffs_lookup(): dir: 0xc0ef0980, name: "testdir"
lookup(): down biglock
jffs_find_child()
jffs_find_child(): Didn't find the file "testdir".
jffs_lookup(): Couldn't find the file. f = 0x00000000, name = "testdir", d
= 0xc0daef40, d->ino = 1
lookup(): up biglock
***jffs_mkdir(): dir = 0xc0ef0980, name = "testdir", len = 7, mode =
0x000001ff
mkdir(): down biglock
jffs_write_node(): filename = "testdir", ino = 6, total_size = 68
jffs_fmalloc(): fmc = 0xc0daeec0, size = 68, node = 0xc0da1810
Free size accounting screwed
free_chunk_size1 == 0x3fff10, free_chunk_size2 == 0x0, fmc->free_size ==
0x3ffef0jffs_fmalloc(): free_chunk_size1 = 4194064, free_chunk_size2 = 0
struct jffs_fmcontrol: 0xc0daeec0
{
        0x00000000, /* flash_start  */
        4194304, /* flash_size  */
        68, /* used_size  */
        240, /* dirty_size  */
        4193964, /* free_size  */
        131072, /* sector_size  */
        262144, /* min_free_size  */
        65536, /* max_chunk_size  */
        0xc0d91da0, /* mtd  */
        0xc0da0620, /* head  */    (head->offset = 0x00000000)
        0xc0da0aa0, /* tail  */    (tail->offset + tail->size =
0x00000134)
        0x00000000, /* head_extra  */
        0x00000000, /* tail_extra  */
}
struct jffs_fm: 0xc0da0aa0
{
       0x000000f0, /* offset  */
       68, /* size  */
       0xc0da0540, /* prev  */
       0x00000000, /* next  */
       0xc0da0ac0, /* nodes  */
}
, result: 0x00000000
, result: 0x000002ff
, result: 0x00000d14
jffs_write_node(): About to write this raw inode to the flash at pos 0xf0:
jffs_raw_inode: inode number: 6
{
        0x34383931, /* magic  */
        0x00000006, /* ino  */
        0x00000001, /* pino  */
        0x00000001, /* version  */
        0x000041ff, /* mode  */
        0x0000,     /* uid  */
        0x0000,     /* gid  */
        0xbfedf8ab, /* atime  */
        0xbfedf8ab, /* mtime  */
        0xbfedf8ab, /* ctime  */
        0x00000000, /* offset  */
        0x00000000, /* dsize  */
        0x00000000, /* rsize  */
        0x07,       /* nsize  */
        0x01,       /* nlink  */
        0x00,       /* spare  */
        0,          /* rename  */
        0,          /* deleted  */
        0xff,       /* accurate  */
        0x00000000, /* dchksum  */
        0x02ff,     /* nchksum  */
        0x0d14,     /* chksum  */
}
Didn't write all bytes in flash_safe_write(). Returned -5
***jffs_fmfree_partly(): fm = 0xc0da0aa0, fm->nodes = 0xc0da0ac0,
fm->nodes->node->ino = 10, size = 8
JFFS: jffs_write_node: Failed to write raw_inode.
jffs_mkdir(): jffs_write_node() failed.
mkdir(): up biglock
mkdir: cannot make directory `/mnt/jffs/testdir': I/O error

----------------------------------------------------------------------------
bash# cp /jffs.image /dev/mtd0
MTD_open
MTD_write
cp: /dev/mtd0: I/O error
MTD_close
sync
sync end

----------------------------------------------------------------------------
bash# ls -la /mnt/jffs
readdir(): down biglock
jffs_readdir(): inode: 0xc0ef0980, filp: 0xc0fa16c0
jffs_readdir(): "." 1
jffs_readdir(): ".." 1
readdir(): up biglock
readdir(): down biglock
jffs_readdir(): inode: 0xc0ef0980, filp: 0xc0fa16c0
readdir(): up biglock
total 1
drwxr-xr-x   1 0        0               0 Dec  9 17:54 .
drwxr-xr-x   3 0        0            1024 Jun 11  2002 ..
bash# ls -l /dev/mtd? /dev/mtdblock?
crw-r--r--   1 0        0         90,   0 Jun 11  2002 /dev/mtd0
crw-r--r--   1 0        0         90,   2 Jun 11  2002 /dev/mtd1
crw-r--r--   1 0        0         90,   4 Jun 11  2002 /dev/mtd2
crw-r--r--   1 0        0         90,   6 Jun 11  2002 /dev/mtd3
crw-r--r--   1 0        0         90,   8 Jun 11  2002 /dev/mtd4
crw-r--r--   1 0        0         90,  10 Jun 11  2002 /dev/mtd5
crw-r--r--   1 0        0         90,  12 Jun 11  2002 /dev/mtd6
crw-r--r--   1 0        0         90,  14 Jun 11  2002 /dev/mtd7
crw-r--r--   1 0        0         90,  16 Jun 11  2002 /dev/mtd8
crw-r--r--   1 0        0         90,  18 Jun 11  2002 /dev/mtd9
brw-r--r--   1 0        0         31,   0 Jun 11  2002 /dev/mtdblock0
brw-r--r--   1 0        0         31,   1 Jun 11  2002 /dev/mtdblock1
brw-r--r--   1 0        0         31,   2 Jun 11  2002 /dev/mtdblock2
brw-r--r--   1 0        0         31,   3 Jun 11  2002 /dev/mtdblock3
brw-r--r--   1 0        0         31,   4 Jun 11  2002 /dev/mtdblock4
brw-r--r--   1 0        0         31,   5 Jun 11  2002 /dev/mtdblock5
brw-r--r--   1 0        0         31,   6 Jun 11  2002 /dev/mtdblock6
brw-r--r--   1 0        0         31,   7 Jun 11  2002 /dev/mtdblock7
brw-r--r--   1 0        0         31,   8 Jun 11  2002 /dev/mtdblock8
brw-r--r--   1 0        0         31,   9 Jun 11  2002 /dev/mtdblock9
bash#

-- 
Clifford

Re: Problem putting JFFS on MTD

[David Woodhouse]

kfloo@hkpc.org said:
>  I can now mount an erased mtdblock device directly to "/mnt/jffs".
> But creating files or directories results in I/O errors: 

Hmmm. No message from the flash driver when this happens? They're not from 
JFFS, they're from the flash driver itself. 

--
dwmw2

Re: Problem putting JFFS on MTD

[Clifford Loo]

On Fri, 14 Jun 2002, David Woodhouse wrote:
>
>kfloo@hkpc.org said:
>>  I can now mount an erased mtdblock device directly to "/mnt/jffs".
>> But creating files or directories results in I/O errors:
>
>Hmmm. No message from the flash driver when this happens? They're not from
>JFFS, they're from the flash driver itself.

I'm not sure what's from the flash driver itself, but there's no "Flash
writer error" or anything like that.  In any case I've attached all the
log messages leading up to the "I/O error" in my previous post.  For the
mount command, here's an excerpt of the debug message:

bash# mount -t jffs /dev/mtdblock0 /mnt/jffs
mtdblock_open
ok
JFFS: Trying to mount device 1f:00.
jffs_build_fs()
jffs_create_control()
jffs_build_begin()
  fmc->flash_start = 0x00000000
  fmc->flash_size = 4194304 bytes
jffs_scan_flash(): start pos = 0x0, end = 0x400000
jffs_scan_flash(): 0xff at pos 0x0.
flash_safe_read(c0d91da0, 00000000, 00000000, c0e9b000)
jffs_scan_flash(): 0xff at pos 0x1000.
flash_safe_read(c0d91da0, 00000000, 00001000, c0e9b000)
jffs_scan_flash(): 0xff at pos 0x2000.
flash_safe_read(c0d91da0, 00000000, 00002000, c0e9b000)
jffs_scan_flash(): 0xff at pos 0x3000.
flash_safe_read(c0d91da0, 00000000, 00003000, c0e9b000)
jffs_scan_flash(): 0xff at pos 0x4000.
flash_safe_read(c0d91da0, 00000000, 00004000, c0e9b000)
[...]
jffs_scan_flash(): 0xff at pos 0x3fd000.
flash_safe_read(c0d91da0, 00000000, 003fd000, c0e9b000)
jffs_scan_flash(): 0xff at pos 0x3fe000.
flash_safe_read(c0d91da0, 00000000, 003fe000, c0e9b000)
jffs_scan_flash(): 0xff at pos 0x3ff000.
flash_safe_read(c0d91da0, 00000000, 003ff000, c0e9b000)
jffs_build_end()
struct jffs_fmcontrol: 0xc0daeec0
{
        0x00000000, /* flash_start  */
        4194304, /* flash_size  */
        0, /* used_size  */
        0, /* dirty_size  */
        4194304, /* free_size  */
        131072, /* sector_size  */
        262144, /* min_free_size  */
        65536, /* max_chunk_size  */
        0xc0d91da0, /* mtd  */
        0x00000000, /* head  */    (head->offset = 0x00000000)
        0x00000000, /* tail  */    (tail->offset + tail->size =
0x00000000)
        0x00000000, /* head_extra  */
        0x00000000, /* tail_extra  */
}
jffs_scan_flash(): Leaving...
jffs_find_file(): ino: 1
jffs_find_file(): Didn't find file with ino 1.
jffs_add_virtual_root(): Creating a virtual root directory.
jffs_insert_file_into_hash(): f->ino: 1
jffs_possibly_delete_file(): ino: 1
jffs_remove_redundant_nodes(): ino: 1, name: "", newest_type: 1
jffs_insert_file_into_tree(): name: ""
jffs_find_file(): ino: 0
jffs_find_file(): Didn't find file with ino 0.
jffs_build_file(): ino: 1, name: ""
jffs_update_file(): ino: 1, version: 0
JFFS: Dumping the file system's hash table...
*** c->hash[1]: "" (ino: 1, pino: 0)
/ (ino: 1, highest_version: 0, size: 0)
jffs_read_inode(): inode->i_ino == 1
read_inode(): down biglock
jffs_find_file(): ino: 1
jffs_find_file(): Found file with ino 1. (name: "")
read_inode(): up biglock
JFFS: GC thread pid=12.
JFFS: Successfully mounted device 1f:00.
jffs_garbage_collect_thread(): Starting infinite loop.
thread_should_wake(): free=4194304, dirty=0, blocksize=131072.
bash#



-- 
Clifford

Re: Problem putting JFFS on MTD

[David Woodhouse]

kfloo@hkpc.org said:
>  I'm not sure what's from the flash driver itself, but there's no
> "Flash writer error" or anything like that.  In any case I've attached
> all the log messages leading up to the "I/O error" in my previous
> post.  For the mount command, here's an excerpt of the debug message:

What flash hardware and driver? Sorry, you did tell me this once I think.
You sure you have Vpen enabled, etc.?

--
dwmw2

Re: Problem putting JFFS on MTD

[Clifford Loo]

On Fri, 14 Jun 2002, David Woodhouse wrote:
>
>kfloo@hkpc.org said:
>>  I'm not sure what's from the flash driver itself, but there's no
>> "Flash writer error" or anything like that.  In any case I've attached
>> all the log messages leading up to the "I/O error" in my previous
>> post.  For the mount command, here's an excerpt of the debug message:
>
>What flash hardware and driver? Sorry, you did tell me this once I think.

The flash part is a CFI-compatible MBM29DL32XBD by Fujitsu.  The flash
driver (drivers/char/flash.c and cfi_flash.c) is by DENX Software
Engineering (Wolfgang Denk, wd@denx.de).

>You sure you have Vpen enabled, etc.?

I'm not sure what Vpen is.  But if you mean anything like the Write Enable
pin of the flash part, it ought to be.  The hardware has been verified
'coz we used to run a different OS (OS9000) and flash filesystem (FTL) on
it, and the same flash could do read/write with no problem.

-- 
Clifford

Re: Howto create a new jffs2

[Krypton]

>> Creating 5 MTD partitions on "SA1100 flash":
>> 0x00000000-0x00020000 : "firmware"
>> 0x00020000-0x00040000 : "params"
>> 0x00040000-0x00140000 : "kernel"
>> 0x00140000-0x00fe0000 : "rootdisk"
>> 0x00fe0000-0x01000000 : "test"

> Try, mount -t jffs2 /dev/mtdblock4 <dir>

I already have tried this but unsuccesfully.
Error : "No such file or directory"

Other suggestions ?

Cheers

Re: Howto create a new jffs2

[Studying MTD]

--- Krypton <krypton8@inwind.it> wrote:
> >> Creating 5 MTD partitions on "SA1100 flash":
> >> 0x00000000-0x00020000 : "firmware"
> >> 0x00020000-0x00040000 : "params"
> >> 0x00040000-0x00140000 : "kernel"
> >> 0x00140000-0x00fe0000 : "rootdisk"
> >> 0x00fe0000-0x01000000 : "test"
> 
> > Try, mount -t jffs2 /dev/mtdblock4 <dir>
> 
> I already have tried this but unsuccesfully.
> Error : "No such file or directory"
> 
> Other suggestions ?

what is the output of "ls -l /dev/mtd*" ?



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: Howto create a new jffs2

[Krypton]

-----> > >> Creating 5 MTD partitions on "SA1100 flash":
> > >> 0x00000000-0x00020000 : "firmware"
> > >> 0x00020000-0x00040000 : "params"
> > >> 0x00040000-0x00140000 : "kernel"
> > >> 0x00140000-0x00fe0000 : "rootdisk"
> > >> 0x00fe0000-0x01000000 : "test"
> > 
> > > Try, mount -t jffs2 /dev/mtdblock4 <dir>
> > 
> > I already have tried this but unsuccesfully.
> > Error : "No such file or directory"
> > 
> > Other suggestions ?
> 
> what is the output of "ls -l /dev/mtd*" ?
> 

No such file or directory

Re: Howto create a new jffs2

[David Woodhouse]

krypton8@inwind.it said:
> > what is the output of "ls -l /dev/mtd*" ?
> 
> No such file or directory 

Run the MAKEDEV script from the util/ directory of CVS.

--
dwmw2

Re: Howto create a new jffs2

[Krypton]

> -----> > >> Creating 5 MTD partitions on "SA1100 flash":
> > > >> 0x00000000-0x00020000 : "firmware"
> > > >> 0x00020000-0x00040000 : "params"
> > > >> 0x00040000-0x00140000 : "kernel"
> > > >> 0x00140000-0x00fe0000 : "rootdisk"
> > > >> 0x00fe0000-0x01000000 : "test"
> > > 
> > > > Try, mount -t jffs2 /dev/mtdblock4 <dir>
> > > 
> > > I already have tried this but unsuccesfully.
> > > Error : "No such file or directory"
> > > 
> > > Other suggestions ?
> > 
> > what is the output of "ls -l /dev/mtd*" ?
> > 
> 
> No such file or directory
> 
> 
> Run the MAKEDEV script from the util/ directory of CVS.

Ok now I'm able to mount the partition using
mount -t jffs2 /dev/mtdblock4 <dir>

Thank you very much !

-----
krypton8-AT-inwind-DOT-it

Re: why MTD model ?

[David Woodhouse]

studying_mtd@yahoo.com said:
> Can somehow we treat(emulate) memory device as a block device and
> treat memory device like a hard disk ?

Not directly, no. There are drivers which do so -- and present a flash 
device as a block device using translation layers of various complexity, 
but that is not a true representation of the capabilities of the underlying 
device.

--
dwmw2

Re: why MTD model ?

[Studying MTD]

--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> studying_mtd@yahoo.com said:
> > Can somehow we treat(emulate) memory device as a
> block device and
> > treat memory device like a hard disk ?
> 
> Not directly, no. There are drivers which do so --
> and present a flash 
> device as a block device using translation layers of
> various complexity, 

you mean, it is possible.


> but that is not a true representation of the
> capabilities of the underlying 
> device.
> 

what you mean by "true representation of the
capabilities" ?

what i will miss, if i use memory flash device as
block device and merge memory flash device with other
block devices ?

what is the advantage of MTD model with respect to
block devices , why we use MTD ?

thanks for your help.

> --
> dwmw2
> 
> 
> 
>
______________________________________________________
> Linux MTD discussion mailing list
>
http://lists.infradead.org/mailman/listinfo/linux-mtd/


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: why MTD model ?

[David Woodhouse]

studying_mtd@yahoo.com said:
> you mean, it is possible.
> > but that is not a true representation of the
> > capabilities of the underlying 
> > device.
> 
> what you mean by "true representation of the capabilities" ?
> what i will miss, if i use memory flash device as block device and
> merge memory flash device with other block devices ?

Flash devices have large erase blocks. You cannot just treat them as a block
device with a sector size of 64KiB, etc. A flash device can have sectors
erased independently of write operations, can have write operations
performed independently of erases (e.g. JFFS2 does so just to clear one
extra 'valid' bit in existing nodes', can support writes to arbitrary byte
ranges, etc. The MTD API allows you to make use of those features.

The block device model does not offer a way to handle any of that. It only 
allows you to make atomic updates of fixed-size sectors, which is not 
something that flash devices are naturally capable of. To use flash as a 
block device, you have to have some kind of 'translation layer' hack.

The simplest we have is the 'mtdblock' one, which on receiving a write 
request simply reads the whole of the erase block which it landed in, 
erases that block, then writes it all back out again with the offending 
sector modified. That's obviously very unsafe, but it's OK for setting up 
file systems which are going to be read-only in production.

Others are more complicated and safe w.r.t. power failure, essentially a
complete journalling file system in themselves just to emulate a block
device with small sectors. On top of which people put 'normal' journalling 
file systems.

Having a journalling file system atop a journalling file system sucks. We 
do far better by exposing an API which represents the true functionality of 
the underlying devices and designing a file system to make use of that 
directly. 

--
dwmw2

Re: why MTD model ?

[Studying MTD]

--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> Flash devices have large erase blocks. You cannot
> just treat them as a block
> device with a sector size of 64KiB, etc. 

We can change the sector size on block devices.

> A flash device can have sectors
> erased independently of write operations, can have
> write operations
> performed independently of erases 

I think, this is not neccesary to keep erase
independent from writing, we can erase before we
write.

> (e.g. JFFS2 does so just to clear one
> extra 'valid' bit in existing nodes', can support
> writes to arbitrary byte
> ranges, etc. 

It is not neccesary that we use JFFS2, we can use any
filesystem on flash but at low level when we are
writing to flash, we can use wear levelling.

> The MTD API allows you to make use of those
features.

Are these are only feature provided by MTD ?

I am not able to understand what is special in MTD
model ?

Please help me.

thanks for your help.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: why MTD model ?

[David Woodhouse]

studying_mtd@yahoo.com said:
>  We can change the sector size on block devices. 

Even if Linux could cope with sectors larger than PAGE_SIZE, the amount of
space wasted by using 64KiB sectors would be prohibitive. Perhaps reiserfs 
with its tail-packing option could cope, but I doubt it very much.

>  I think, this is not neccesary to keep erase independent from
> writing, we can erase before we write.

Not if you want to be able to write fewer data than an entire eraseblock at 
a time, or if you care about limiting the number of erase cycles.

> It is not neccesary that we use JFFS2, we can use any filesystem on
> flash but at low level when we are writing to flash, we can use wear
> levelling. 

Indeed, this is as I said. You can use a 'normal' journalling file system on
top of another pseudo-filesystem which emulates a block device. Your
'normal' file system will write each block of data to the flash twice --
once to its 'journal' and then again to the actual file system structure, 
while your underlying pseudo-filesystem will faithfully log this activity.

If you are misguided enough to desire this behaviour, it is possible. The 
translation layer is a 'user' of an underlying MTD device driver which 
actually performs the fundamental read/write/erase operations on the flash 
chips. The MTD API represents those fundamental capabilities of the 
hardware.

>  Are these are only feature provided by MTD ? 

By the MTD API, yes. The sole purpose of the MTD API is to represent the
functionality of Memory Technology Devices, and therefore that is all it 
does.

The MTD code base contains drivers for various flash chips, real flash file
systems, and also some of these 'translation layers' which are used to 
emulate a block device. 

>  I am not able to understand what is special in MTD model ? 

There is nothing particularly special about it. It merely represents the
capabilities of the hardware in a way which makes it possible to use it
effectively.

--
dwmw2

Re: why MTD model ?

[Studying MTD]

Dear dwmw2,

Thanks for your help.

If some how i solve these issues :-
1. sector size
2. erase/write
3. wear levelling

Please let me know, which block device is closest to
Flash memory :-
1. Hard Disk
2. Floppy drive
3. PCMCIA memory card
4. Ramdisk
5. or some other block device ?

Thanks for your help.




__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: why MTD model ?

[David Woodhouse]

studying_mtd@yahoo.com said:
>  If some how i solve these issues :- 
> 1. sector size
> 2. erase/write
> 3. wear levelling

The core MTD API isn't there to solve those issues for you, only to
represent the raw hardware -- and we have existing drivers for many types of
raw hardware.

Those issues are solved by whatever _uses_ the MTD devices -- and there are 
a number of solutions already implemented in the MTD code base. The most
sensible way to put a file system on flash is to use a file system
especially designed for that purpose -- such as JFFS2. However, for legacy 
reasons we also have code which uses MTD devices to emulate hard drives, as 
for some strange and inexplicable reason you seem to want.

In the days of DOS, it was difficult to add a real file system, so instead 
people came up with a gross hack to make a flash device appear just like a 
normal BIOS-supported disk drive.

They designed a pseudo-filesystem which emulated a hard drive, and then
provided a BIOS extension which overrode the INT 13h (Disk BIOS) interrupt
handler. Then people would just use a FAT file system on it under DOS as if
it was a normal hard drive. 

When Windows started to gain its own 32-bit device drivers for hard drives, 
the pseudo-filesystems that emulated hard drives were rewritten to run 
under Windows, but people were so used to the idea of a pseudo-fs emulating 
a block device with a 'real' fs on top of that, that the opportunity wasn't 
taken to make the whole thing sane just by having a proper file system 
directly on the flash.

The only half-sane reason for using a translation layer to emulate a block 
device like this is on removable media -- if you need to be able to remove 
the flash device from your Linux box and read it in a DOS or Windows box. 

If your flash isn't going to be removable, then you really don't want to do 
it that way, for reasons which I've discussed at length quite recently.

You should be using a proper file system directly on the flash. This is not 
DOS, and you don't have to repeat DOS-based mistakes.

> Please let me know, which block device is closest to Flash memory :-
> 1. Hard Disk 2. Floppy drive 3. PCMCIA memory card 4. Ramdisk 5. or
> some other block device ? 

Your question is very ambiguous. You might as well ask which tropical fish 
is closest to flash memory. No block device is _similar_ to flash -- they are 
entirely different beasts.

I suppose the hard drive sitting on my desk with a pile of flash chips on 
top of it is 'closest to Flash memory' in one way, but I suspect that's not 
what you were asking.

If you mean which block device is most similar in performance and general 
operation to a system which uses flash to emulate a block device, then the 
answer would be PCMCIA-ATA or CompactFlash cards -- because they _are_ 
using precisely such a translation layer internally. The only difference is 
that they do it internally, in firmware (and generally quite unreliably).

If you mean which block device driver code is most similar to the code 
you'd have to write to implement yet another translation layer, then that 
would be something like the FTL or NFTL code -- they both use the 
underlying MTD drivers for the raw hardware, and perform their own magic 
to present a block device implementation to Linux.

--
dwmw2

RE: why MTD model ?

[Gregg C Levine]

Hello from Gregg C Levine
I agree David with you on all points, except one. Regarding the
reliability of PCMCIA-ATA drives. I have a bunch here right now, and
they are proving to be more reliable then the disk drives I keep buying
from the same shop. The fact that the manufacturer decided to
discontinue them because of size, is irrelevant. The fact that they came
with a FAT-12 file system, and a partition to match is also irrelevant.
-------------------
Gregg C Levine hansolofalcon@worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org [mailto:linux-mtd-
> admin@lists.infradead.org] On Behalf Of David Woodhouse
> Sent: Friday, June 14, 2002 8:22 AM
> To: Studying MTD
> Cc: linux-mtd
> Subject: Re: why MTD model ?
> 
> 
> studying_mtd@yahoo.com said:
> >  If some how i solve these issues :-
> > 1. sector size
> > 2. erase/write
> > 3. wear levelling
> 
> The core MTD API isn't there to solve those issues for you, only to
> represent the raw hardware -- and we have existing drivers for many
types of
> raw hardware.
> 
> Those issues are solved by whatever _uses_ the MTD devices -- and
there are
> a number of solutions already implemented in the MTD code base. The
most
> sensible way to put a file system on flash is to use a file system
> especially designed for that purpose -- such as JFFS2. However, for
legacy
> reasons we also have code which uses MTD devices to emulate hard
drives, as
> for some strange and inexplicable reason you seem to want.
> 
> In the days of DOS, it was difficult to add a real file system, so
instead
> people came up with a gross hack to make a flash device appear just
like a
> normal BIOS-supported disk drive.
> 
> They designed a pseudo-filesystem which emulated a hard drive, and
then
> provided a BIOS extension which overrode the INT 13h (Disk BIOS)
interrupt
> handler. Then people would just use a FAT file system on it under DOS
as if
> it was a normal hard drive.
> 
> When Windows started to gain its own 32-bit device drivers for hard
drives,
> the pseudo-filesystems that emulated hard drives were rewritten to run
> under Windows, but people were so used to the idea of a pseudo-fs
emulating
> a block device with a 'real' fs on top of that, that the opportunity
wasn't
> taken to make the whole thing sane just by having a proper file system
> directly on the flash.
> 
> The only half-sane reason for using a translation layer to emulate a
block
> device like this is on removable media -- if you need to be able to
remove
> the flash device from your Linux box and read it in a DOS or Windows
box.
> 
> If your flash isn't going to be removable, then you really don't want
to do
> it that way, for reasons which I've discussed at length quite
recently.
> 
> You should be using a proper file system directly on the flash. This
is not
> DOS, and you don't have to repeat DOS-based mistakes.
> 
> > Please let me know, which block device is closest to Flash memory :-
> > 1. Hard Disk 2. Floppy drive 3. PCMCIA memory card 4. Ramdisk 5. or
> > some other block device ?
> 
> Your question is very ambiguous. You might as well ask which tropical
fish
> is closest to flash memory. No block device is _similar_ to flash --
they are
> entirely different beasts.
> 
> I suppose the hard drive sitting on my desk with a pile of flash chips
on
> top of it is 'closest to Flash memory' in one way, but I suspect
that's not
> what you were asking.
> 
> If you mean which block device is most similar in performance and
general
> operation to a system which uses flash to emulate a block device, then
the
> answer would be PCMCIA-ATA or CompactFlash cards -- because they _are_
> using precisely such a translation layer internally. The only
difference is
> that they do it internally, in firmware (and generally quite
unreliably).
> 
> If you mean which block device driver code is most similar to the code
> you'd have to write to implement yet another translation layer, then
that
> would be something like the FTL or NFTL code -- they both use the
> underlying MTD drivers for the raw hardware, and perform their own
magic
> to present a block device implementation to Linux.
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: why MTD model ?

[Eric W. Biederman]

Studying MTD <studying_mtd@yahoo.com> writes:

> Please let me know, which block device is closest to
> Flash memory :-
> 1. Hard Disk
> 2. Floppy drive
> 3. PCMCIA memory card
> 4. Ramdisk
> 5. or some other block device ?

The closest are CD-RW disks....

I wonder if it would make sense to port them to the mtd layer?

Eric

RE: why MTD model ?

[Gregg C Levine]

Hello from Gregg C Levine
If by top posting you mean sending you mail, David, and then the other
name, and finally the list, then fine. This one is only to the list. And
I'm just stating a simple fact. Yes, I agree with you, the FAT partition
isn't necessary. The cards just came with it. And no the UMSDOS method
of creating a Linux distribution does not work in the 2.4.x series. I
don't know why. The folks at Slackware never told me. But I am curious
which patches need to be applied within the patch directory of your MTD
collection to the 2.2.17 kernel to make it work?
-------------------
Gregg C Levine hansolofalcon@worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@redhat.com] On Behalf Of David
> Woodhouse
> Sent: Friday, June 14, 2002 8:48 AM
> To: Gregg C Levine
> Cc: 'Studying MTD'
> Subject: Re: why MTD model ?
> 
> 
> No top-posting here please.
> 
> hansolofalcon@worldnet.att.net said:
> > I agree David with you on all points, except one. Regarding the
> > reliability of PCMCIA-ATA drives. I have a bunch here right now, and
> > they are proving to be more reliable then the disk drives I keep
> > buying from the same shop. The fact that the manufacturer decided to
> > discontinue them because of size, is irrelevant. The fact that they
> > came with a FAT-12 file system, and a partition to match is also
> > irrelevant.
> 
> Well, if you're comparing with the reliability of cheap IDE drives,...
:)
> 
> I haven't really dealt with CompactFlash or PCMCIA-ATA cards much, I'm
only
> repeating what others have reported.
> 
> But certainly you don't have to keep the partitioning and the FAT file
> system. You can blow it away and just put an ext2 or ext3 file system
on the
> whole device. Although as discussed, ext2 (just like FAT) isn't safe
w.r.t
> power loss and ext3 causes you to wear the flash out far quicker than
you
> need to.
> 
> I don't think anyone's insane enough to try to run a Linux box with a
FAT
> root file system any more -- does the UMSDOS hack even compile in
recent
> kernels? Without it you won't get device nodes, symlinks, permissions,
etc.
> 
> --
> dwmw2
> 

Re: why MTD model ?

[David Woodhouse]

hansolofalcon@worldnet.att.net said:
> If by top posting you mean sending you mail, David, and then the other
> name, and finally the list, then fine. This one is only to the list.

By top-posting I mean annoying practice of quoting the entire mail and just 
typing your own response at the top. It is normal to quote only those parts 
of the mail to which you're actually responding, and your response to those 
parts immediately below the quoted text.

> And I'm just stating a simple fact. Yes, I agree with you, the FAT
> partition isn't necessary. The cards just came with it. And no the
> UMSDOS method of creating a Linux distribution does not work in the
> 2.4.x series. I don't know why. The folks at Slackware never told me.

UMSDOS was always a bit of an evil hack. When all the core Linux file system
code was overhauled during the 2.3 series, nobody cared enough to update it,
and I believe the new saner core VFS code was more difficult to abuse in the
ways the UMSDOS needed to.

> But I am curious which patches need to be applied within the patch
> directory of your MTD collection to the 2.2.17 kernel to make it work?

Just the inter-module-xxx one, I think.

--
dwmw2