mtd devices & jffs

mtd devices & jffs

[Juan Gonzo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 3020 bytes --]

Compiled the MTD code into a Linux 2.2.14 kernel and
loaded it onto our system (ARM processor and Intel Strataflash).

The system boots up.  Here is the MTD related messages:

=======================================

NORA: Found a coupled pair of CFI devices at location 0 in 16 bit mode
Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
Primary Algorithm Table at 0031
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: 128 µs
Maximum byte/word write timeout: 2048 µs
Typical full buffer write timeout: 128 µs
Maximum full buffer write timeout: 2048 µs
Typical block erase timeout: 1024 µs
Maximum block erase timeout: 16384 µs
Chip erase not supported
Device size: 0x1000000 bytes (16 Mb)
Flash Device Interface description: 0x0002
  - supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x20
Number of Erase Block Regions: 1
  Erase Region #0: BlockSize 0x20000 bytes, 128 blocks
 
 Intel/Sharp Extended Query Table at 0x0031
number of CFI chips: 1

=======================================

Everything looks ok.  I can't get the MAKEDEV script to
run on our system, so I try to do a couple manually.  I
enter 'mknod /dev/mtd0 c 90 0' and then 
'mknod /dev/mtdblock0 b 31 0'.  Both work and the devices
are present in the /dev dir.  However when I try to mount
JFFS using 'mount -t jfss /dev/mtdblock0 /mnt', I get the
following:

=======================================

[root@Linux /dev]$mount -t jffs /dev/mtdblock0 /mnt
JFFS: Trying to mount device 1f:00.
jffs_scan_flash(): start pos = 0x0, end = 0x16777216
jffs_scan_flash(): 0xff at pos 0x0.
jffs_scan_flash(): 0xff ended at pos 0x1097152.
jffs_scan_flash(): 0x00 at pos 0x1097152.
jffs_scan_flash(): 0x00 ended at pos 0x1098176.
*************** Dirty flash memory or bad inode: hexdump(pos =
0x1098176, len =
128):
1098176: 0018 0000 0018 0000 3d00 0000 ac05 0000  ........=.......
1098192: 8f16 0000 0100 0000 0000 0000 0000 0000  ................
1098208: 0020 0000 0020 0000 0018 0000 8618 5d39  ..............]9
1098224: ea18 5d39 0100 1400 53ef 0100 0100 0000  ..]9....S.......
1098240: 8518 5d39 004e ed00 0000 0000 0100 0000  ..]9.N..........
1098256: 0000 0000 0b00 0000 8000 0000 0000 0000  ................
1098272: 0200 0000 0100 0000 d285 611c 3947 4857  ..........a.9GHW
1098288: a6c2 3cee 5e93 efb7 0000 0000 0000 0000  ..<.^...........
Didn't read all bytes in flash_read_u32()
Didn't read all bytes in flash_read_u32()
Didn't read [etc, this line goes on for many many screens]

=======================================

Do I need to 'mknod' all the devices that MAKEDEV does?
To me, this seems like a problem beyond that.

Any suggestions as to what is going on?  Is it my flash?

Thanks,
   -- kelly



_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[Rogelio M. Serrano Jr.]

The same happens to me and im using a DOC2000. The second time i mount
jffs fails to build the tree.

Juan Gonzo wrote:

> Compiled the MTD code into a Linux 2.2.14 kernel and
> loaded it onto our system (ARM processor and Intel Strataflash).
>
> The system boots up.  Here is the MTD related messages:
>
> =======================================
>
> NORA: Found a coupled pair of CFI devices at location 0 in 16 bit mode
> Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
> Primary Algorithm Table at 0031
> 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: 128 µs
> Maximum byte/word write timeout: 2048 µs
> Typical full buffer write timeout: 128 µs
> Maximum full buffer write timeout: 2048 µs
> Typical block erase timeout: 1024 µs
> Maximum block erase timeout: 16384 µs
> Chip erase not supported
> Device size: 0x1000000 bytes (16 Mb)
> Flash Device Interface description: 0x0002
>   - supports x8 and x16 via BYTE# with asynchronous interface
> Max. bytes in buffer write: 0x20
> Number of Erase Block Regions: 1
>   Erase Region #0: BlockSize 0x20000 bytes, 128 blocks
>
>  Intel/Sharp Extended Query Table at 0x0031
> number of CFI chips: 1
>
> =======================================
>
> Everything looks ok.  I can't get the MAKEDEV script to
> run on our system, so I try to do a couple manually.  I
> enter 'mknod /dev/mtd0 c 90 0' and then
> 'mknod /dev/mtdblock0 b 31 0'.  Both work and the devices
> are present in the /dev dir.  However when I try to mount
> JFFS using 'mount -t jfss /dev/mtdblock0 /mnt', I get the
> following:
>
> =======================================
>
> [root@Linux /dev]$mount -t jffs /dev/mtdblock0 /mnt
> JFFS: Trying to mount device 1f:00.
> jffs_scan_flash(): start pos = 0x0, end = 0x16777216
> jffs_scan_flash(): 0xff at pos 0x0.
> jffs_scan_flash(): 0xff ended at pos 0x1097152.
> jffs_scan_flash(): 0x00 at pos 0x1097152.
> jffs_scan_flash(): 0x00 ended at pos 0x1098176.
> *************** Dirty flash memory or bad inode: hexdump(pos =
> 0x1098176, len =
> 128):
> 1098176: 0018 0000 0018 0000 3d00 0000 ac05 0000  ........=.......
> 1098192: 8f16 0000 0100 0000 0000 0000 0000 0000  ................
> 1098208: 0020 0000 0020 0000 0018 0000 8618 5d39  ..............]9
> 1098224: ea18 5d39 0100 1400 53ef 0100 0100 0000  ..]9....S.......
> 1098240: 8518 5d39 004e ed00 0000 0000 0100 0000  ..]9.N..........
> 1098256: 0000 0000 0b00 0000 8000 0000 0000 0000  ................
> 1098272: 0200 0000 0100 0000 d285 611c 3947 4857  ..........a.9GHW
> 1098288: a6c2 3cee 5e93 efb7 0000 0000 0000 0000  ..<.^...........
> Didn't read all bytes in flash_read_u32()
> Didn't read all bytes in flash_read_u32()
> Didn't read [etc, this line goes on for many many screens]
>
> =======================================
>
> Do I need to 'mknod' all the devices that MAKEDEV does?
> To me, this seems like a problem beyond that.
>
> Any suggestions as to what is going on?  Is it my flash?
>
> Thanks,
>    -- kelly
>
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[David Woodhouse]

kayemmess@yahoo.ca said:
> Dirty flash memory or bad inode: hexdump(pos = 0x1098176, len = 128):

Looks like there were data on the flash chips before you started. Erase 
them first. There's no utility to erase whole devices, but the 'erase' 
program in the util/ directory will erase a single erase block at a time.

 for a in `seq 0 131072 16777216` ; do mtd/util/erase /dev/mtd0 $a ; done

...or put a loop into the erase program. The MTDGETINFO ioctl should return 
the size of the device.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[Juan Gonzo]

I guess the problem I am going to run into is that I don't
want to erase all of the flash, nor do I want JFFS to use
all of the flash.  Part of the flash will have a kernel
image burned into, and another part is being used for config
data etc.  And then the filesystem is supposed to have its
chunk of flash to use.

Is this possible?  Looking through the JFFS code, they hardcode
the start address for their scan at 0x0 and get the end addr
based on the size of the total flash.  Is there a way to tell
JFFS "start at this addr and only use this much space" without
changing this code?

Thanks,
   -- kelly


--- David Woodhouse <dwmw2@infradead.org> wrote:
> 
> kayemmess@yahoo.ca said:
> > Dirty flash memory or bad inode: hexdump(pos = 0x1098176, len =
> 128):
> 
> Looks like there were data on the flash chips before you started.
> Erase 
> them first. There's no utility to erase whole devices, but the
> 'erase' 
> program in the util/ directory will erase a single erase block at a
> time.
> 
>  for a in `seq 0 131072 16777216` ; do mtd/util/erase /dev/mtd0 $a ;
> done
> 
> ....or put a loop into the erase program. The MTDGETINFO ioctl should
> return 
> the size of the device.
> 
> 
> --
> dwmw2
> 
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org


_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[Rogelio M. Serrano Jr.]

The same happens to me and im using a DOC2000. The second time i mount
jffs fails to build the tree.

Juan Gonzo wrote:

> Compiled the MTD code into a Linux 2.2.14 kernel and
> loaded it onto our system (ARM processor and Intel Strataflash).
>
> The system boots up.  Here is the MTD related messages:
>
> =======================================
>
> NORA: Found a coupled pair of CFI devices at location 0 in 16 bit mode
> Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
> Primary Algorithm Table at 0031
> 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: 128 µs
> Maximum byte/word write timeout: 2048 µs
> Typical full buffer write timeout: 128 µs
> Maximum full buffer write timeout: 2048 µs
> Typical block erase timeout: 1024 µs
> Maximum block erase timeout: 16384 µs
> Chip erase not supported
> Device size: 0x1000000 bytes (16 Mb)
> Flash Device Interface description: 0x0002
>   - supports x8 and x16 via BYTE# with asynchronous interface
> Max. bytes in buffer write: 0x20
> Number of Erase Block Regions: 1
>   Erase Region #0: BlockSize 0x20000 bytes, 128 blocks
>
>  Intel/Sharp Extended Query Table at 0x0031
> number of CFI chips: 1
>
> =======================================
>
> Everything looks ok.  I can't get the MAKEDEV script to
> run on our system, so I try to do a couple manually.  I
> enter 'mknod /dev/mtd0 c 90 0' and then
> 'mknod /dev/mtdblock0 b 31 0'.  Both work and the devices
> are present in the /dev dir.  However when I try to mount
> JFFS using 'mount -t jfss /dev/mtdblock0 /mnt', I get the
> following:
>
> =======================================
>
> [root@Linux /dev]$mount -t jffs /dev/mtdblock0 /mnt
> JFFS: Trying to mount device 1f:00.
> jffs_scan_flash(): start pos = 0x0, end = 0x16777216
> jffs_scan_flash(): 0xff at pos 0x0.
> jffs_scan_flash(): 0xff ended at pos 0x1097152.
> jffs_scan_flash(): 0x00 at pos 0x1097152.
> jffs_scan_flash(): 0x00 ended at pos 0x1098176.
> *************** Dirty flash memory or bad inode: hexdump(pos =
> 0x1098176, len =
> 128):
> 1098176: 0018 0000 0018 0000 3d00 0000 ac05 0000  ........=.......
> 1098192: 8f16 0000 0100 0000 0000 0000 0000 0000  ................
> 1098208: 0020 0000 0020 0000 0018 0000 8618 5d39  ..............]9
> 1098224: ea18 5d39 0100 1400 53ef 0100 0100 0000  ..]9....S.......
> 1098240: 8518 5d39 004e ed00 0000 0000 0100 0000  ..]9.N..........
> 1098256: 0000 0000 0b00 0000 8000 0000 0000 0000  ................
> 1098272: 0200 0000 0100 0000 d285 611c 3947 4857  ..........a.9GHW
> 1098288: a6c2 3cee 5e93 efb7 0000 0000 0000 0000  ..<.^...........
> Didn't read all bytes in flash_read_u32()
> Didn't read all bytes in flash_read_u32()
> Didn't read [etc, this line goes on for many many screens]
>
> =======================================
>
> Do I need to 'mknod' all the devices that MAKEDEV does?
> To me, this seems like a problem beyond that.
>
> Any suggestions as to what is going on?  Is it my flash?
>
> Thanks,
>    -- kelly
>
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[David Woodhouse]

kayemmess@yahoo.ca said:
> Is this possible?  Looking through the JFFS code, they hardcode the
> start address for their scan at 0x0 and get the end addr based on the
> size of the total flash.  Is there a way to tell JFFS "start at this
> addr and only use this much space" without changing this code? 

Give it an MTD device which points at only the range you want it to use.
See how nora.c splits up the flash chips into four 'partitions'.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[David Woodhouse]

rogelio@evoserve.com said:
> The same happens to me and im using a DOC2000. The second time i mount
> jffs fails to build the tree. 

Doc2000 doesn't currently support writes which aren't 512 bytes long, which 
isn't particularly useful for JFFS. S'fairly trivial to fix. Just that 
nobody's done it yet. You don't need to know anything about the DiskOnChip 
to do it - just read the datasheet for the flash chips it's using.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtd devices & jffs

[David Woodhouse]

dwmw2@infradead.org said:
> > Is there a way to tell JFFS "start at this
> > addr and only use this much space" without changing this code? 

> Give it an MTD device which points at only the range you want it to
> use. See how nora.c splits up the flash chips into four 'partitions'. 

I just committed 'pnc2000.c' which should be clearer. Look at that instead.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Config.in

[Sébastien Côté]

Running make xconfig on 2.2.15, I get the following
drivers/mtd/Config.in: 14: unknown command

However, make menuconfig doesn't generate any error.  I'm not a kernel
config specialist so I don't know if define_tristate was introduced in
2.3 or why in doesn't work only with xconfig, but this is definitly a
bug of some sort.


-- 
Sébastien Côté


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Config.in

[David Woodhouse]

Hmmm. Talk to David and Michael.

scote1@matrox.com said:
> Running make xconfig on 2.2.15, I get the following
> drivers/mtd/Config.in: 14: unknown command

> However, make menuconfig doesn't generate any error.  I'm not a kernel
> config specialist so I don't know if define_tristate was introduced in
> 2.3 or why in doesn't work only with xconfig, but this is definitly a
> bug of some sort. 



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Config.in

[Sébastien Côté]

David Woodhouse wrote:
> 
> Hmmm. Talk to David and Michael.
> 
> scote1@matrox.com said:
> > Running make xconfig on 2.2.15, I get the following
> > drivers/mtd/Config.in: 14: unknown command
> 
> > However, make menuconfig doesn't generate any error.  I'm not a kernel
> > config specialist so I don't know if define_tristate was introduced in
> > 2.3 or why in doesn't work only with xconfig, but this is definitly a
> > bug of some sort.

Another thing I just noticed is that the links in linux/modules are
wrong for MTD.  They point to linux/Lost/mtd*.  But the link for jffs.o
is correct! I didn't notice this before because I linked all my JFFS and
MTD stuff directly in /lib/modules/...  I didn't use the patch to
install MTD so maybe I did something wrong but where does the kernel
look to make these links ?

-- 
Sébastien Côté


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org