2009-07-23 02:41:03     Flash driver Testing

Document created by Aaronwu Employee on Aug 16, 2013
Version 1Show Document
  • View in full screen mode

2009-07-23 02:41:03     Flash driver Testing

razia razia (INDIA)

Message: 77902   

 

Hi,

 

    I am using a CFI Compliant Parallel NOR Flash device for our ADSP BF527-0.2 custom board.

 

I have read the document given in,

  docs.blackfin.uclinux.org/doku.php?id=linux-kernel:mtd and found that the CFI code can be used for Flash Driver.

 

I have the following queries related to the Flash driver Testing,

 

1. From UserSpace, what are the API routines needed  for read,write and erase flash?

2. Is there any Test Application available to test  the Flash driver?

 

 

Please provide me your suggestions on this.

 

 

 

-Razia.

QuoteReplyEditDelete

 

 

2009-07-23 02:47:55     Re: Flash driver Testing

Mike Frysinger (UNITED STATES)

Message: 77903   

 

you didnt read enough of the page

 

  docs.blackfin.uclinux.org/doku.php?id=linux-kernel:mtd#userspace_usage

QuoteReplyEditDelete

 

 

2009-07-31 06:11:37     Re: Flash driver Testing

razia razia (INDIA)

Message: 78245   

 

Hi Mike,

 

Thanks for the info.

 

I have gone through the page,

 

https://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:mtd-utils

 

But I could not find the command for programming the flash...(Read, Write Command).

 

Please tell me, where I can find the APIs for programming the flash.  I am new to this Flash Driver, so please provide your suggestions on this.

QuoteReplyEditDelete

 

 

2009-07-31 09:54:28     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78258   

 

Razia:

 

I updated this page:

 

https://docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:mtd-utils

QuoteReplyEditDelete

 

 

2009-08-03 09:26:21     Re: Flash driver Testing

razia razia (INDIA)

Message: 78310   

 

Hi Robin,

 

Thank you, I am able to write and read the data from flash using the commands for read and write.

 

but

 

flash_eraseall is not working, when i issue this command, i am getting the following error.

 

"unable to get MTD device info"

 

I would like to develop a test application for this flash device with apis for write and read and test the flash device instead of these ( read and write ) commands.

 

is there any test application example syntax for creating this api.

 

Thank you.

QuoteReplyEditDelete

 

 

2009-08-03 09:33:39     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78311   

 

Razia:

 

What does /proc/mtd show?

QuoteReplyEditDelete

 

 

2009-08-04 00:32:47     Re: Flash driver Testing

razia razia (INDIA)

Message: 78330   

 

Hi Robin,

 

This is the message /proc/mtd is giving..

 

root:/> cat /proc/mtd

dev:    size   erasesize  name

mtd0: 00040000 00010000 "bootloader(nor)"

mtd1: 001c0000 00010000 "linux kernel(nor)"

mtd2: 00200000 00010000 "file system(nor)"

 

 

 

Thanks,

 

razia.

 

 

 

 

 

 

 

    

QuoteReplyEditDelete

 

 

2009-08-04 01:30:10     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78332   

 

Razia:

 

Is that information correct for your part? (64k block sizes? - everything is nor flash?)

QuoteReplyEditDelete

 

 

2009-08-04 01:45:29     Re: Flash driver Testing

razia razia (INDIA)

Message: 78333   

 

Hi Robin,

 

Yes, that information is correct for the Flash.

 

Block Size - 64K, NOR Flash.

 

I have enabled the default partitioning support in my kernel configuration.

 

Device Drivers  --->

  Memory Technology Devices (MTD)  --->

    <*> Memory Technology Device (MTD) support

    [*]   MTD partitioning support

 

QuoteReplyEditDelete

 

 

2009-08-04 02:02:08     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78335   

 

What version of things are you using?

QuoteReplyEditDelete

 

 

2009-08-04 02:21:11     Re: Flash driver Testing

razia razia (INDIA)

Message: 78336   

 

Robin:

 

I am using ADI BF527 EZ-Kit board -0.2.

 

Linux version -  2.6.28.7-ADI-2009R1-pre

 

uClinux Distribution - trunk-svn-7856 Distribution.

 

I am testing the 16-bit parallel flash memory on the BF527 EZ-KIT.

 

 

 

Thanks,

 

razia.

QuoteReplyEditDelete

 

 

2009-08-05 08:16:33     Re: Flash driver Testing

razia razia (INDIA)

Message: 78400   

 

Hi ,

 

on Giving flinfo command it is displaying the following...

 

bfin> flinfo

Bank # 1: CFI conformant FLASH (16 x 16)  Size: 4 MB in 71 Sectors

Erase timeout 8192 ms, write timeout 1 ms, buffer write timeout 1 ms, buffer size 1

  Sector Start Addresses:

    20000000 (RO) 20002000 (RO) 20004000 (RO) 20006000 (RO) 20008000 (RO)

    2000A000 (RO) 2000C000 (RO) 2000E000 (RO) 20010000 (RO) 20020000 (RO)

    20030000 (RO) 20040000 (RO) 20050000 (RO) 20060000      20070000

    20080000      20090000      200A0000      200B0000      200C0000

    200D0000      200E0000      200F0000      20100000      20110000

    20120000      20130000      20140000      20150000      20160000

    20170000      20180000      20190000      201A0000      201B0000

    201C0000      201D0000      201E0000      201F0000      20200000

    20210000      20220000      20230000      20240000      20250000

    20260000      20270000      20280000      20290000      202A0000

    202B0000      202C0000      202D0000      202E0000      202F0000

    20300000      20310000      20320000      20330000      20340000

    20350000      20360000      20370000      20380000      20390000

    203A0000      203B0000      203C0000      203D0000      203E0000

    203F0000

 

I tried to write data to the address 0x20000000, after giving  "protect off" command .

 

Please tell me, Is there any API for making protection off to this memory region, instead of using command?

 

TIA.

QuoteReplyEditDelete

 

 

2009-08-05 09:52:01     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78402   

 

Razia:

 

Software protection in U-Boot has nothing to do with the kernel.

 

-Robin

QuoteReplyEditDelete

 

 

2009-08-06 03:36:41     Re: Flash driver Testing

razia razia (INDIA)

Message: 78416   

 

Hi Robin,

 

I was working with BF527 Ezkit previously for testing the flash driver in kernel.

 

now i am working with the custom board bf527. On power up and upon reset all the sectors in the flash are protected.

 

i need to un protect the sector before programming.

 

when i tried to write the data using the driver write function, the return value is negative. i need to un protect the sectors before writing.

 

i tried with protect off command in u-boot once the u-boot comes up before loading the kernel.

 

>protect off start address endaddress

 

>tftp 0x1000000 uImage;bootm

 

after this if iprogram the data it is properly writing into the flash.

 

i need to do the protection off in the uImage. how to do this.

 

Thank you.

QuoteReplyEditDelete

 

 

2009-08-06 08:22:20     Re: Flash driver Testing

razia razia (INDIA)

Message: 78422   

 

Hi Robin,

 

I  used the flash_unlock command to enable write to a mtdpartition as follows,

 

>flash_unlock  /dev/mtdblock1

 

On executing this command it is giving,

 

Could not unlock MTD device:

 

Please tell me , is this the command I need to give to make protection off to that partition?

 

Why it is not able to unlock the mtd partition?

 

Please help me on this issue.

 

Thank You.

QuoteReplyEditDelete

 

 

2009-08-07 03:15:04     Re: Flash driver Testing

razia razia (INDIA)

Message: 78478   

 

Hi Robin,

 

I tried with Character device access to the MTD device.

 

And I am able to do flash_unlock  and flash_eraseall , without giving the protect off command at u-boot.

 

Could you please tell me, why those commands failed for Block device access?

 

I would like to know, the advantages of the MTD Block Driver Model over the Char Driver Model.

 

Please tell me where can I find the relevant documents to get the details for this?

 

 

 

Thank You

QuoteReplyEditDelete

 

 

2009-08-07 10:02:30     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78509   

 

Razia:

 

I\'m trying to replicate - are you experiencing the problem on an EZkit - or not? (It seemed not). Which flash part are you using?

 

-Robin

QuoteReplyEditDelete

 

 

2009-08-10 03:12:07     Re: Flash driver Testing

razia razia (INDIA)

Message: 78542   

 

Hi Robin,

 

Yes, You are correct, that problem is not on EZ-kit. I am working with a custom board.

 

Flash Part number - M28W160EC - 16Mbit ( 1Mb x 16).

 

In the Features summary, you can find the details related to the Block Locking or Protected.

 

■ BLOCK LOCKING

– All blocks locked at Power Up

– Any combination of blocks can be locked

– WP for Block Lock-Down

 

\"\"

 

 

 

Thank You.

QuoteReplyEditDelete

 

 

2009-08-10 10:44:34     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 78568   

 

Razia:

 

Then you need to unlock all the blocks.

 

If flash_unlock doesn\'t work - then you need to check that the mtd driver for that part supports the MEMUNLOCK ioclt. (which is only supported on the char device, not the block device).

 

-Robin

QuoteReplyEditDelete

 

 

2009-08-11 02:35:34     Re: Flash driver Testing

razia razia (INDIA)

Message: 78594   

 

Hi Robin,

 

Thank You. I am able to do MEMUNLOCK using char device access.

 

Please tell me, Is there any advantage in preferring the char device model for the MTD device, rather than the block device model?

 

TIA

QuoteReplyEditDelete

 

 

2009-08-11 04:09:55     Re: Flash driver Testing

Yi Li (CHINA)

Message: 78601   

 

For this question, you may refer to MTD FAQ:

 

  www.linux-mtd.infradead.org/faq/general.html

 

-Yi

QuoteReplyEditDelete

 

 

2009-08-11 04:30:23     Re: Flash driver Testing

Mike Frysinger (UNITED STATES)

Message: 78602   

 

using `flash_unlock` on a mtdblock or mtdchar device makes no sense.  you must use it on the normal device node like /dev/mtd1.

QuoteReplyEditDelete

 

 

2009-08-12 07:03:08     Re: Flash driver Testing

razia razia (INDIA)

Message: 78727   

 

Hi Robin,

 

>>If flash_unlock doesn\'t work - then you need to check that the mtd driver for that part supports the MEMUNLOCK ioclt. (which is only supported on the char device, not the block device).

 

-- I want to use only the block device access for the MTD Device, so that I can mount a file system(jffs2) and do read/write.

 

In this case, Is there any other way to get flash_unlock support for this model?

 

 

 

Thank You,

QuoteReplyEditDelete

 

 

2009-08-13 03:00:02     Re: Flash driver Testing

razia razia (INDIA)

Message: 78800   

 

Hi,

 

Can I use the MEMUNLOCK ioctl for the MTD block device driver in the same way as the MTD char device?

 

Is there any other way to get this ioctl work for MTD Block Device driver?

 

Please help me on this issue.

 

Thank You.

QuoteReplyEditDelete

 

 

2009-08-13 03:07:16     Re: Flash driver Testing

Mike Frysinger (UNITED STATES)

Message: 78802   

 

probably

QuoteReplyEditDelete

 

 

2009-08-28 09:20:10     Re: Flash driver Testing

razia razia (INDIA)

Message: 79359   

 

Hi,

 

I am testing the performance of MTD Device using bonnie++,  on our ADSP-BF527-custom board, (2009R1-RC1 Distribution used).

 

I gave the commands as documented in

 

  docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:bonnie, as follows,

 

root:/> mount -t jffs2 /dev/mtdblock2 /mnt/                                   

root:/> bonnie++ -u root -d /mnt -n 0 -f

 

But I am getting the following error messages in the console,

 

 

Hardware Trace:

   0 Target : <0x00183b30> { _dump_stack + 0x0 }

     Source : <0x001ad630> { _oom_kill_process + 0xd8 } CALL pcrel

   1 Target : <0x001ad630> { _oom_kill_process + 0xd8 }

     Source : <0x0018e746> { _printk + 0x16 } RTS

   2 Target : <0x0018e742> { _printk + 0x12 }

     Source : <0x0018ef5e> { _vprintk + 0x132 } RTS

   3 Target : <0x0018ef52> { _vprintk + 0x126 }

     Source : <0xffa00b8c> { __common_int_entry + 0xcc } RTI

   4 Target : <0xffa00b2a> { __common_int_entry + 0x6a }

     Source : <0xffa00978> { _return_from_int + 0x58 } RTS

   5 Target : <0xffa00978> { _return_from_int + 0x58 }

     Source : <0xffa0094e> { _return_from_int + 0x2e } IF !CC JUMP

   6 Target : <0xffa00920> { _return_from_int + 0x0 }

     Source : <0xffa00b26> { __common_int_entry + 0x66 } CALL pcrel

   7 Target : <0xffa00b24> { __common_int_entry + 0x64 }

     Source : <0xffa002e2> { _asm_do_IRQ + 0x62 } RTS

   8 Target : <0xffa002da> { _asm_do_IRQ + 0x5a }

     Source : <0x00192490> { __local_bh_enable + 0x40 } RTS

   9 Target : <0x00192450> { __local_bh_enable + 0x0 }

     Source : <0x00192578> { ___do_softirq + 0x9c } JUMP.L

  10 Target : <0x00192570> { ___do_softirq + 0x94 }

     Source : <0x00192554> { ___do_softirq + 0x78 } IF !CC JUMP

  11 Target : <0x00192536> { ___do_softirq + 0x5a }

     Source : <0x00195606> { _run_timer_softirq + 0x82 } RTS

  12 Target : <0x00195598> { _run_timer_softirq + 0x14 }

     Source : <0x001a0772> { _hrtimer_run_pending + 0x82 } RTS

  13 Target : <0x001a0766> { _hrtimer_run_pending + 0x76 }

     Source : <0x001a0716> { _hrtimer_run_pending + 0x26 } IF !CC JUMP

  14 Target : <0x001a06f0> { _hrtimer_run_pending + 0x0 }

     Source : <0x00195594> { _run_timer_softirq + 0x10 } CALL pcrel

  15 Target : <0x00195584> { _run_timer_softirq + 0x0 }

     Source : <0x00192534> { ___do_softirq + 0x58 } CALL (P2)

Stack info:

SP: [0x07ea9b20] <0x07ea9b20> /* kernel dynamic memory */

FP: (0x07ea9c38)

Memory from 0x07ea9b20 to 07eaa000

07ea9b20:[00000064]<001ad634> 07e830a0  00000000  00000000  07e83288  001200d2  00000000

07ea9b40: 00000000  00336890  000000e4 <001ad7ba> 000000a0  002f98b8  07ea8000 <001ad958>

07ea9b60: 07e830a0  0033ed5c  00000124  0000000a  07e83940  000000a0  0033ed5c  00000001

07ea9b80: 07ea9ba0  00000048  0000000a  00000000  002f98b8  07ea9b7c  00000461  1d4410c2

07ea9ba0: 00000000  00000002 <001af978> 07e830a0  00352cec  00000000  00000000  001200d2

07ea9bc0: 00000000  00000042  001200d2  001200d2  00000000  00352cec  00000002  00000048

07ea9be0: 07ea8000  07ea8000  00000000  001200d2  07ea8000  00000010  00000000  00000000

07ea9c00: 00000000  00000000  07ea9cbc <001ab4c0> 00e4210c  00e42074  00e4210c  00000000

07ea9c20: 00000000  0000a8d7  ffffffff  07e8368c  003306a0  00e4210c (00000000)<001ee6c2>

07ea9c40: 07ea8000  0000a8d7  00000000  0a8d7000  00001000  07e830a0 <07e83660> 073884e0

07ea9c60: 07ea9c88 <002c0216> 073887e0  07e830a0  073884e0  00e42074  00d9ce00  00000000

07ea9c80: 07ea8000  07ea8000  07ea9cb8 <0018bb30> 07ea8000  00001000  00e4210c  04000000

07ea9ca0: 00000000  0a8d6000  00001000  03b70000  0a8d6000  00001000  07ea9cd8  070a5ca0

07ea9cc0:<001ab954> 07ea8000  00001000  00e4210c  00000000  00000000  0a8d7000  00001000

07ea9ce0: 00000000  0000001f  0a8d7000  00000000  00001000  00000000  07ea9d34  07ea9d30

07ea9d00: 00000000  00e4210c  002c8784  00e42074  00000000  00000000  002c8784  00001000

07ea9d20: 07ea9e9c  00000001  00001000  00001000  00000000  00d9ce00  00e4210c <001abeb8>

07ea9d40: 00e42074  00002000  070a5ca0  00000000  07ea9e9c  00000000  0a8d6000  07ea9e18

07ea9d60:<00192536> 003353e4  0a8d6000  00000000  07ea9e60  00002000  00000000 <001a98e4>

07ea9d80: 00342bbc  00000006  00e4c004  00000006  008c9910 <ffa002da> 00338a6c  00000004

07ea9da0: 00002000  00e4210c <001ac876> 07ea9e18  00e42074  070a5ca0  00e420e0  07ea9e9c

07ea9dc0: 00000000  0a8d6000  07ea9e18  07ea9e9c  00000001  07ea9e60 <001a24d8> 001bb560

07ea9de0: 008c9910 <001bae8c> 070a5ca0  07ea9ef0  00e4c004  07ea9e18  07ea9e9c  00002000

07ea9e00: 008c99dc  00000000  00c0c365  00000001  0a8d6000  00000000  000f4240  00000000

07ea9e20: 00000000  00000001  ffffffff  070a5ca0  00000000  00000000  00000000  00000000

07ea9e40: 07e830a0  00000000  00000000  00000001  07e830a0  0019dd2c  07ea9e58  07ea9e58

07ea9e60: 0a8d6000  00000000  008c990c <001a486a> 07ea9ea4 <00195598> 00002000  07ea8000

07ea9e80: 00335380  00000001  00000000  00000000  00002000  008c9910  00000000  00e4c004

07ea9ea0: 00002000 <001bb554> 070a5ca0  00000004  07ea9ef0  00e4c004  00e4c004  008c9924

07ea9ec0: 07ea9ef4  07ea9ef0  008c99dc <001bb8b4> 070a5ca0  00e4c004  00002000  00002000

07ea9ee0:<00192128> 00192110  00e4c004  07ea9ef0  0a8d6000  00000000  00000000 <ffa007ec>

07ea9f00: 001bb884  00000000  ffffe000  008c9a54  00e4c004  41d16614  00000000  008c99dc

07ea9f20: 00002000  0089174a  00008000  00000000  00000000  07eaa000  0089174a  0089174a

07ea9f40:<0088e468><ffa00e44> 02003025  00888ba9  008884c1  00888b74  008884b4  00000000

07ea9f60: 00000000  ffffd7bd  ffffffff  d4d0563b  ffffffff  00000000  00000000  00000000

07ea9f80: 00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000

07ea9fa0: 00000020  0000001e  00000000  00000001  00000020  008c9904  008c9910  008c9978

07ea9fc0: 008c9a54  00e4c004  008a6a40  008c9928  00000004  00000003  00e4c004  00002000

07ea9fe0: 008c99dc  00000000  00002000  00e4c004  00000003  00000003  00000004  00000006

07eaa000: 07ee1340

Return addresses in stack:

    address : <0x001ad634> { _oom_kill_process + 0xdc }

    address : <0x001ad7ba> { _badness + 0xb2 }

    address : <0x001ad958> { _out_of_memory + 0x128 }

    address : <0x001af978> { ___alloc_pages_internal + 0x234 }

    address : <0x001ab4c0> { _grab_cache_page_write_begin + 0x50 }

   frame  1 : <0x001ee6c2> { _jffs2_write_begin + 0x2a }

    address : <0x07e83660> /* kernel dynamic memory */

    address : <0x002c0216> { _schedule + 0x182 }

    address : <0x0018bb30> { ___cond_resched + 0x1c }

    address : <0x001ab954> { _generic_file_buffered_write + 0xdc }

    address : <0x001abeb8> { ___generic_file_aio_write_nolock + 0x1f0 }

    address : <0x00192536> { ___do_softirq + 0x5a }

    address : <0x001a98e4> { _handle_simple_irq + 0x74 }

    address : <0xffa002da> { _asm_do_IRQ + 0x5a }

    address : <0x001ac876> { _generic_file_aio_write + 0x56 }

    address : <0x001a24d8> { _do_gettimeofday + 0x10 }

    address : <0x001bae8c> { _do_sync_write + 0xac }

    address : <0x001a486a> { _tick_handle_periodic + 0xe }

    address : <0x00195598> { _run_timer_softirq + 0x14 }

    address : <0x001bb554> { _vfs_write + 0x6c }

    address : <0x001bb8b4> { _sys_write + 0x30 }

    address : <0x00192128> { _sys_gettimeofday + 0x18 }

    address : <0xffa007ec> { _system_call + 0x68 }

    address : <0x0088e468> [ bonnie++ + 0xe428 ]

    address : <0xffa00e44> { _evt_system_call + 0x64 }

Mem-Info:

DMA per-cpu:

CPU    0: hi:   42, btch:   7 usd:  34

Active_anon:0 active_file:14208 inactive_anon:0

inactive_file:14214 dirty:0 writeback:0 unstable:0

free:1031 slab:1211 mapped:0 pagetables:0 bounce:0

DMA free:4124kB min:4096kB low:5120kB high:6144kB active_anon:0kB inactive_anon:0kB active_file:56832kB inactive_file:56856kB

 

present:129028kB pages_scanned:142374 all_unreclaimable? no

lowmem_reserve[]: 0 0 0

DMA: 5*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB 0*8192kB 0*16384kB 0*32768kB =

 

4124kB

28422 total pagecache pages

32511 pages RAM

1137 pages reserved

0 pages shared

30290 pages non-shared

Out of memory: kill process 281 (sh) score 10 or a child

Killed process 293 (bonnie++)

Killed

 

Please help me to solve this problem.

 

TIA.

QuoteReplyEditDelete

 

 

2009-08-28 09:38:41     Re: Flash driver Testing

Robin Getz (UNITED STATES)

Message: 79360   

 

Razia:

 

Do you read things before you copy/paste them? What you pasted was a out of memory error.

 

you ran out of memory - free more up.

 

-Robin

QuoteReplyEditDelete

 

 

2009-08-28 10:19:39     Re: Flash driver Testing

Mike Frysinger (UNITED STATES)

Message: 79363   

 

you arent using the released versions of 2009R1.  download the actual releases and delete the old stuff.

QuoteReplyEditDelete

 

 

2009-08-31 05:42:29     Re: Flash driver Testing

razia razia (INDIA)

Message: 79390   

 

Hi Mike,

 

Is that the released version of 2009R1 means  "uClinux-dist-2009R1-RC6" distribution?

 

Should I use this distribution(uClinux-dist-2009R1-RC6) , to avoid this bonnie++ OOM problem?

 

Thanks

QuoteReplyEditDelete

 

 

2009-09-02 00:41:33     Re: Flash driver Testing

razia razia (INDIA)

Message: 79463   

 

Hi ,

 

I  am working with JFFS2 file system on a CFI compliant Parallel NOR Flash Chip, BF527-0.2 Custom Board.

 

I have made the partitions on the Flash Chip as given below,

 

root:/> cat /proc/partitions

major minor  #blocks  name

 

  31        0        256 mtdblock0

  31        1        640 mtdblock1

  31        2       8192 mtdblock2

  31        3       3072 mtdblock3

  31        4       4224 mtdblock4

 

I mounted jffs2 on mtdblock2 and tested file write of size 10 MB,

 

root:/> dd if=test_10M.bin of=/mnt/out1.bin bs=128k count=80

 

80+0 records in

80+0 records out

 

root:/> ls -lh mnt

-rw-r--r--    1 root     root        10.0M Jan  1 00:15 out1.bin

 

My partition size is only 8 MB, but file write of size 10MB is done.

 

I am new to this file system... Can you please tell me how this is working?

 

TIA

 

QuoteReplyEditDelete

 

 

2009-09-02 00:50:12     Re: Flash driver Testing

Mike Frysinger (UNITED STATES)

Message: 79464   

 

you really shouldnt keep dumping your unrelated issues into this thread

 

your output doesnt show that you've actually mounted anything anywhere.  read /proc/mounts to see what you've actually mounted.

QuoteReplyEditDelete

 

 

2009-09-02 01:07:50     Re: Flash driver Testing

razia razia (INDIA)

Message: 79467   

 

Hi Mike,

 

These are the steps I have followed for mounting jffs2,

 

root:/> flash_eraseall -j /dev/mtd2

Erasing 128 Kibyte @ 800000 -- 100 % complete.Cleanmarker written at 7e0000.

root:/> mount -t jffs2 /dev/mtdblock2 /mnt/

 

 

root:/> cat /proc/mounts

rootfs / rootfs rw 0 0

proc /proc proc rw,nosuid,nodev,noexec 0 0

sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0

mdev /dev tmpfs rw,nosuid 0 0

devpts /dev/pts devpts rw,nosuid,noexec,mode=600 0 0

var /var ramfs rw 0 0

tmp /tmp tmpfs rw,nosuid,nodev 0 0

debugfs /sys/kernel/debug debugfs rw 0 0

/dev/mtdblock2 /mnt jffs2 rw 0 0

QuoteReplyEditDelete

 

 

2009-09-02 01:55:11     Re: Flash driver Testing

Mike Frysinger (UNITED STATES)

Message: 79470   

 

you didnt show your latest /proc/mtd or `df -h` output

 

might also want to try using `stat` to see what the actual block usage is

Attachments

    Outcomes