* why MTD model ? @ 2002-06-12 23:53 Studying MTD 2002-06-13 10:34 ` David Woodhouse 0 siblings, 1 reply; 29+ messages in thread From: Studying MTD @ 2002-06-12 23:53 UTC (permalink / raw) To: linux-mtd; +Cc: David Woodhouse 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-12 23:53 why MTD model ? Studying MTD @ 2002-06-13 10:34 ` David Woodhouse 2002-06-13 16:19 ` Studying MTD 0 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-13 10:34 UTC (permalink / raw) To: Studying MTD; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-13 10:34 ` David Woodhouse @ 2002-06-13 16:19 ` Studying MTD 2002-06-13 16:39 ` Gregg C Levine ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Studying MTD @ 2002-06-13 16:19 UTC (permalink / raw) To: David Woodhouse; +Cc: linux-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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: why MTD model ? 2002-06-13 16:19 ` Studying MTD @ 2002-06-13 16:39 ` Gregg C Levine 2002-06-13 17:13 ` Howto create a new jffs2 Krypton 2002-06-13 21:34 ` why MTD model ? David Woodhouse 2 siblings, 0 replies; 29+ messages in thread From: Gregg C Levine @ 2002-06-13 16:39 UTC (permalink / raw) To: linux-mtd 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/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Howto create a new jffs2 2002-06-13 16:19 ` Studying MTD 2002-06-13 16:39 ` Gregg C Levine @ 2002-06-13 17:13 ` Krypton 2002-06-14 2:22 ` Steve Tsai 2002-06-13 21:34 ` why MTD model ? David Woodhouse 2 siblings, 1 reply; 29+ messages in thread From: Krypton @ 2002-06-13 17:13 UTC (permalink / raw) To: linux-mtd 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" ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: Howto create a new jffs2 2002-06-13 17:13 ` Howto create a new jffs2 Krypton @ 2002-06-14 2:22 ` Steve Tsai 2002-06-14 3:20 ` Problem putting JFFS on MTD Clifford Loo 2002-06-14 6:22 ` Howto create a new jffs2 Krypton 0 siblings, 2 replies; 29+ messages in thread From: Steve Tsai @ 2002-06-14 2:22 UTC (permalink / raw) To: 'Krypton'; +Cc: Linux MTD mailing list 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/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Problem putting JFFS on MTD 2002-06-14 2:22 ` Steve Tsai @ 2002-06-14 3:20 ` Clifford Loo 2002-06-14 7:33 ` David Woodhouse 2002-06-14 6:22 ` Howto create a new jffs2 Krypton 1 sibling, 1 reply; 29+ messages in thread From: Clifford Loo @ 2002-06-14 3:20 UTC (permalink / raw) To: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Problem putting JFFS on MTD 2002-06-14 3:20 ` Problem putting JFFS on MTD Clifford Loo @ 2002-06-14 7:33 ` David Woodhouse 2002-06-14 8:46 ` Clifford Loo 0 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 7:33 UTC (permalink / raw) To: Clifford Loo; +Cc: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Problem putting JFFS on MTD 2002-06-14 7:33 ` David Woodhouse @ 2002-06-14 8:46 ` Clifford Loo 2002-06-14 8:50 ` David Woodhouse 0 siblings, 1 reply; 29+ messages in thread From: Clifford Loo @ 2002-06-14 8:46 UTC (permalink / raw) To: David Woodhouse; +Cc: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Problem putting JFFS on MTD 2002-06-14 8:46 ` Clifford Loo @ 2002-06-14 8:50 ` David Woodhouse 2002-06-14 9:18 ` Clifford Loo 0 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 8:50 UTC (permalink / raw) To: Clifford Loo; +Cc: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Problem putting JFFS on MTD 2002-06-14 8:50 ` David Woodhouse @ 2002-06-14 9:18 ` Clifford Loo 2002-06-14 9:17 ` David Woodhouse 0 siblings, 1 reply; 29+ messages in thread From: Clifford Loo @ 2002-06-14 9:18 UTC (permalink / raw) To: David Woodhouse; +Cc: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Problem putting JFFS on MTD 2002-06-14 9:18 ` Clifford Loo @ 2002-06-14 9:17 ` David Woodhouse 2002-06-14 9:39 ` Clifford Loo 0 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 9:17 UTC (permalink / raw) To: Clifford Loo; +Cc: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Problem putting JFFS on MTD 2002-06-14 9:17 ` David Woodhouse @ 2002-06-14 9:39 ` Clifford Loo 0 siblings, 0 replies; 29+ messages in thread From: Clifford Loo @ 2002-06-14 9:39 UTC (permalink / raw) To: David Woodhouse; +Cc: Linux MTD mailing list 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Howto create a new jffs2 2002-06-14 2:22 ` Steve Tsai 2002-06-14 3:20 ` Problem putting JFFS on MTD Clifford Loo @ 2002-06-14 6:22 ` Krypton 2002-06-14 6:55 ` Studying MTD 1 sibling, 1 reply; 29+ messages in thread From: Krypton @ 2002-06-14 6:22 UTC (permalink / raw) To: linux-mtd >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Howto create a new jffs2 2002-06-14 6:22 ` Howto create a new jffs2 Krypton @ 2002-06-14 6:55 ` Studying MTD 2002-06-14 7:46 ` Krypton 2002-06-14 7:47 ` David Woodhouse 0 siblings, 2 replies; 29+ messages in thread From: Studying MTD @ 2002-06-14 6:55 UTC (permalink / raw) To: Krypton; +Cc: linux-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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Howto create a new jffs2 2002-06-14 6:55 ` Studying MTD @ 2002-06-14 7:46 ` Krypton 2002-06-14 7:47 ` David Woodhouse 1 sibling, 0 replies; 29+ messages in thread From: Krypton @ 2002-06-14 7:46 UTC (permalink / raw) To: linux-mtd -----> > >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Howto create a new jffs2 2002-06-14 6:55 ` Studying MTD 2002-06-14 7:46 ` Krypton @ 2002-06-14 7:47 ` David Woodhouse 2002-06-14 9:52 ` Krypton 1 sibling, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 7:47 UTC (permalink / raw) To: Krypton; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Howto create a new jffs2 2002-06-14 7:47 ` David Woodhouse @ 2002-06-14 9:52 ` Krypton 0 siblings, 0 replies; 29+ messages in thread From: Krypton @ 2002-06-14 9:52 UTC (permalink / raw) To: linux-mtd > -----> > >> 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-13 16:19 ` Studying MTD 2002-06-13 16:39 ` Gregg C Levine 2002-06-13 17:13 ` Howto create a new jffs2 Krypton @ 2002-06-13 21:34 ` David Woodhouse 2002-06-14 4:29 ` Studying MTD 2 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-13 21:34 UTC (permalink / raw) To: Studying MTD; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-13 21:34 ` why MTD model ? David Woodhouse @ 2002-06-14 4:29 ` Studying MTD 2002-06-14 7:54 ` David Woodhouse 0 siblings, 1 reply; 29+ messages in thread From: Studying MTD @ 2002-06-14 4:29 UTC (permalink / raw) To: David Woodhouse; +Cc: linux-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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 4:29 ` Studying MTD @ 2002-06-14 7:54 ` David Woodhouse 2002-06-14 9:01 ` Studying MTD 0 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 7:54 UTC (permalink / raw) To: Studying MTD; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 7:54 ` David Woodhouse @ 2002-06-14 9:01 ` Studying MTD 2002-06-14 9:23 ` David Woodhouse 0 siblings, 1 reply; 29+ messages in thread From: Studying MTD @ 2002-06-14 9:01 UTC (permalink / raw) To: David Woodhouse; +Cc: linux-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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 9:01 ` Studying MTD @ 2002-06-14 9:23 ` David Woodhouse 2002-06-14 9:59 ` Studying MTD 0 siblings, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 9:23 UTC (permalink / raw) To: Studying MTD; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 9:23 ` David Woodhouse @ 2002-06-14 9:59 ` Studying MTD 2002-06-14 12:21 ` David Woodhouse 2002-06-19 14:28 ` Eric W. Biederman 0 siblings, 2 replies; 29+ messages in thread From: Studying MTD @ 2002-06-14 9:59 UTC (permalink / raw) To: David Woodhouse; +Cc: linux-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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 9:59 ` Studying MTD @ 2002-06-14 12:21 ` David Woodhouse 2002-06-14 12:36 ` Gregg C Levine 2002-06-19 14:28 ` Eric W. Biederman 1 sibling, 1 reply; 29+ messages in thread From: David Woodhouse @ 2002-06-14 12:21 UTC (permalink / raw) To: Studying MTD; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* RE: why MTD model ? 2002-06-14 12:21 ` David Woodhouse @ 2002-06-14 12:36 ` Gregg C Levine 0 siblings, 0 replies; 29+ messages in thread From: Gregg C Levine @ 2002-06-14 12:36 UTC (permalink / raw) To: 'David Woodhouse'; +Cc: 'Studying MTD' 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/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 9:59 ` Studying MTD 2002-06-14 12:21 ` David Woodhouse @ 2002-06-19 14:28 ` Eric W. Biederman 1 sibling, 0 replies; 29+ messages in thread From: Eric W. Biederman @ 2002-06-19 14:28 UTC (permalink / raw) To: Studying MTD; +Cc: David Woodhouse, linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4611.1024058858@redhat.com>]
* RE: why MTD model ? [not found] <4611.1024058858@redhat.com> @ 2002-06-14 23:39 ` Gregg C Levine 2002-06-15 7:34 ` David Woodhouse 0 siblings, 1 reply; 29+ messages in thread From: Gregg C Levine @ 2002-06-14 23:39 UTC (permalink / raw) To: linux-mtd 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 > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: why MTD model ? 2002-06-14 23:39 ` Gregg C Levine @ 2002-06-15 7:34 ` David Woodhouse 0 siblings, 0 replies; 29+ messages in thread From: David Woodhouse @ 2002-06-15 7:34 UTC (permalink / raw) To: Gregg C Levine; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2002-06-19 14:28 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-12 23:53 why MTD model ? Studying MTD 2002-06-13 10:34 ` David Woodhouse 2002-06-13 16:19 ` Studying MTD 2002-06-13 16:39 ` Gregg C Levine 2002-06-13 17:13 ` Howto create a new jffs2 Krypton 2002-06-14 2:22 ` Steve Tsai 2002-06-14 3:20 ` Problem putting JFFS on MTD Clifford Loo 2002-06-14 7:33 ` David Woodhouse 2002-06-14 8:46 ` Clifford Loo 2002-06-14 8:50 ` David Woodhouse 2002-06-14 9:18 ` Clifford Loo 2002-06-14 9:17 ` David Woodhouse 2002-06-14 9:39 ` Clifford Loo 2002-06-14 6:22 ` Howto create a new jffs2 Krypton 2002-06-14 6:55 ` Studying MTD 2002-06-14 7:46 ` Krypton 2002-06-14 7:47 ` David Woodhouse 2002-06-14 9:52 ` Krypton 2002-06-13 21:34 ` why MTD model ? David Woodhouse 2002-06-14 4:29 ` Studying MTD 2002-06-14 7:54 ` David Woodhouse 2002-06-14 9:01 ` Studying MTD 2002-06-14 9:23 ` David Woodhouse 2002-06-14 9:59 ` Studying MTD 2002-06-14 12:21 ` David Woodhouse 2002-06-14 12:36 ` Gregg C Levine 2002-06-19 14:28 ` Eric W. Biederman [not found] <4611.1024058858@redhat.com> 2002-06-14 23:39 ` Gregg C Levine 2002-06-15 7:34 ` David Woodhouse
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.