RE: JFFS2 peoblems with K3 strata flash on Dalhart

RE: JFFS2 peoblems with K3 strata flash on Dalhart

[Yuan, Cain]

No,  but if we don't configure it as" burst" mode,  It will always fail with
write???
Thanks for your useful  information. 



-----Original Message-----
From: Gu Susan-w15879 [mailto:w15879@motorola.com]
To: 'David Woodhouse'; Yuan, Cain
Cc: linux-mtd@lists.infradead.org
Subject: RE: JFFS2 peoblems with K3 strata flash on Dalhart 


Does K3 (and Dalhart) be configured as "burst" read mode when system is
reset?

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

cain.yuan@intel.com said:
> No,  but if we don't configure it as" burst" mode,  It will always
> fail with write??? Thanks for your useful  information. 

It shouldn't, no -- and if it did I don't see why the flash driver wouldn't
return an _error_ instead of returning status zero but 'written bytes zero'.

--
dwmw2

RE: JFFS2 peoblems with K3 strata flash on Dalhart

[Yuan, Cain]

Dear David,
Please notice the fact:  
   at the first,  I burn JFFS2  into K3  flash, then load zImage It boot up
all ok, and   JFFS2 file system are all OK.
But after reset   and load zImage again  I can't create/del  files on JFFS2
file system.
SO I think   there is no much concern with the cfi_xxx_write function, maybe
the status is not  correctly set.
As to buffer writes, I  see  some  lines in  cfi_cmdset_001.c:

// debugging, turns off buffer write mode  #define      FORCE_WORD_WRITE
. . . . . . 
    mtd->read = cfi_intelext_read;
#ifndef FORCE_WORD_WRITE
    if ( cfi->cfiq->BufWriteTimeoutTyp ) {
        printk("Using buffer write method\n" );
        mtd->write = cfi_intelext_write_buffers;
    } else {
#else
    {
#endif
        printk("Using word write method\n" );
        mtd->write = cfi_intelext_write_words;
    }
 . . . . 

So I added #define      FORCE_WORD_WRITE     at hte begining of the file, so
I think   there is nothing concerned with   buffer write functions.
 



cain.yuan@intel.com said:
>  ---  Since using CFI  with Ks flash, I think  it is CFI driver and
> cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
>       Should I download  newest   code from CVS server and merge them
> into the   kernel src tree? 

Er, I don't think there have been significant changes since then. Updating 
to the latest code certainly can't hurt though.

The problem is that the chip write() call is returning zero (i.e. no error) 
but is setting the number of written bytes to zero. That doesn't make sense 
-- if it didn't write all the bytes we asked it to, then there must have 
been an error.

This chip supports buffer writes, doesn't it? Can you add some extra 
'printk' calls in cfi_intelext_write_buffers() to try to show what's 
happening to 'retlen' and when it returns.

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

cain.yuan@intel.com said:
> Please notice the fact:  
>    at the first,  I burn JFFS2  into K3  flash, then load zImage It
> boot up all ok, and   JFFS2 file system are all OK. 

OK... and you can write to it too? What if you reset the board between 
flashing the image and booting Linux?

> But after reset and load zImage again  I can't create/del  files on 
> JFFS2 file system.

Strange. I'm wondering if perhaps the map driver isn't correctly setting 
the Vpp line, but again you should get an _error_ for that, not a zero 
return status. So even if the underlying fault doesn't lie with the write 
routine, it seems to be doing _something_ wrong. 

--
dwmw2

RE: JFFS2 peoblems with K3 strata flash on Dalhart

[Gu Susan-w15879]

Does K3 (and Dalhart) be configured as "burst" read mode when system is reset?

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Wednesday, August 07, 2002 10:20 PM
To: Yuan, Cain
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 peoblems with K3 strata flash on Dalhart 



cain.yuan@intel.com said:
>  ---  Since using CFI  with Ks flash, I think  it is CFI driver and
> cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
>       Should I download  newest   code from CVS server and merge them
> into the   kernel src tree? 

Er, I don't think there have been significant changes since then. Updating 
to the latest code certainly can't hurt though.

The problem is that the chip write() call is returning zero (i.e. no error) 
but is setting the number of written bytes to zero. That doesn't make sense 
-- if it didn't write all the bytes we asked it to, then there must have 
been an error.

This chip supports buffer writes, doesn't it? Can you add some extra 
'printk' calls in cfi_intelext_write_buffers() to try to show what's 
happening to 'retlen' and when it returns.

--
dwmw2



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

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

w15879@motorola.com said:
> Does K3 (and Dalhart) be configured as "burst" read mode when system
> is reset?

Linux doesn't currently make use of burst reads from flash. To do so you'd 
need to either operate through the caches or use the 'read buffer' if you 
have an SA1110.

To use caches sanely, the best way is probably to implement the mechanism 
I've been planning for execute-in-place.

--
dwmw2

RE: JFFS2 peoblems with K3 strata flash on Dalhart

[Yuan, Cain]

cain.yuan@intel.com said:
> 	According to your email  I  rebuild a JFFS2 image with the   block
> size 0x10000,  same as the datasheet saids. but the problem still
> exist.  First bootup will success without any error message. but when
> I reset the board and boot it again, many errors occurs.

Looks like you should be using 0x20000. 0x10000 is fine but triggers 
harmless messages about 'Empty block at 0x.... '. I think you were using 
0x40000 before which would have caused problems.
~~~~~~~~~~  yes, I am using 0x40000 before.


The other problem still remains, and isn't related, though...

> Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
> Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero

The hardware driver seems broken -- it's returning success but not actually 
reporting that it's written any data. What driver, what version?

---  Since using CFI  with Ks flash, I think  it is CFI driver and
cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
      Should I download  newest   code from CVS server and merge them into
the   kernel src tree?


Thanks!!



--
dwmw2

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

cain.yuan@intel.com said:
>  ---  Since using CFI  with Ks flash, I think  it is CFI driver and
> cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
>       Should I download  newest   code from CVS server and merge them
> into the   kernel src tree? 

Er, I don't think there have been significant changes since then. Updating 
to the latest code certainly can't hurt though.

The problem is that the chip write() call is returning zero (i.e. no error) 
but is setting the number of written bytes to zero. That doesn't make sense 
-- if it didn't write all the bytes we asked it to, then there must have 
been an error.

This chip supports buffer writes, doesn't it? Can you add some extra 
'printk' calls in cfi_intelext_write_buffers() to try to show what's 
happening to 'retlen' and when it returns.

--
dwmw2

RE: JFFS2 peoblems with K3 strata flash on Dalhart

[Yuan, Cain]

Hi  David,
	According to your email  I  rebuild a JFFS2 image with the   block
size 0x10000,  same as the datasheet saids.
but the problem still exist.  First bootup will success without any error
message. but when I reset the board and boot it again, many errors occurs.

---------------------  first  time bootup
message-----------------------------
Creating 7 MTD partitions on "Lubbock flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00080000 : "RedBoot[backup]"
0x00080000-0x00180000 : "unallocated space"
0x00180000-0x00980000 : "JFFS2"
0x00980000-0x00fc0000 : "unallocated space"
0x00fc0000-0x00fc1000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't end on an erase block -- force
read-only
0x00fe0000-0x01000000 : "FIS directory"
Linux Kernel Card Services 3.1.22
  options:  [pm]
Intel PXA250/210 PCMCIA (CS release 3.1.22)
Unable to initialize kernel PCMCIA service.
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 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
ds: no socket drivers loaded!
FAT: bogus logical sector size 453
jffs2_scan_empty(): Empty block at 0x0000fffc ends at 0x00010000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0002ff58 ends at 0x00030000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0034fffc ends at 0x00350000 (with
0xe0021985)! Marking dirty
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 80K
INIT: version 2.74 booting
INIT: Entering runlevel: 3
Starting system logger:  syslogd
Starting INET services:  inetd
Starting pcmcia Starting PCMCIA services: module directory
/lib/modules/2.4.18-rmk6-pxa2/pcmcia not found.

Linux login:

After login.  create/del/ files are all OK.

---------------------  second   time bootup
message-----------------------------

cfi probe success.
Using RedBoot partition definition
Creating 7 MTD partitions on "Lubbock flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00080000 : "RedBoot[backup]"
0x00080000-0x00180000 : "unallocated space"
0x00180000-0x00980000 : "JFFS2"
0x00980000-0x00fc0000 : "unallocated space"
0x00fc0000-0x00fc1000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't end on an erase block -- force
read-only
0x00fe0000-0x01000000 : "FIS directory"
Linux Kernel Card Services 3.1.22
  options:  [pm]
Intel PXA250/210 PCMCIA (CS release 3.1.22)
Unable to initialize kernel PCMCIA service.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP

jffs2_scan_empty(): Empty block at 0x0030fffc ends at 0x00310000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0032fffc ends at 0x00330000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0034fffc ends at 0x00350000 (with
0xe0021985)! Marking dirty
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 80K
Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
INIT: version 2.74 booting
Write of 257 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
Write of 185 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero

Linux login:

After login.  create/del/ files will all fail.

[root@Linux /root]$touch test
Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
touch: Input/output error







-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
To: Yuan, Cain
Cc: 'nico@cam.org'; linux-mtd@lists.infradead.org
Subject: Re: JFFS2 peoblems with K3 strata flash on Dalhart 



cain.yuan@intel.com said:
> 	I am now test JFFS2 file system on Dalhart with Redboot as
> boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for
> dalhart.

What erase size did you create your JFFS2 image with?

--
dwmw2

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

cain.yuan@intel.com said:
> 	According to your email  I  rebuild a JFFS2 image with the   block
> size 0x10000,  same as the datasheet saids. but the problem still
> exist.  First bootup will success without any error message. but when
> I reset the board and boot it again, many errors occurs.

Looks like you should be using 0x20000. 0x10000 is fine but triggers 
harmless messages about 'Empty block at 0x.... '. I think you were using 
0x40000 before which would have caused problems.

The other problem still remains, and isn't related, though...

> Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
> Not marking the space at 0x0035e908 as dirty because the flash driver returned retlen zero

The hardware driver seems broken -- it's returning success but not actually 
reporting that it's written any data. What driver, what version?

--
dwmw2

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

cain.yuan@intel.com said:
>  First bootup will success without any error message. but when I reset
> the board and boot it again, many errors occurs. 

The error is -EROFS. Your chip might need unlocking each time it's reset. At 
least one map driver does this automatically at startup.

The reason the error isn't being reported properly is because I'm 
stupid...

--- writev.c	20 May 2002 14:56:39 -0000	1.2
+++ writev.c	8 Aug 2002 08:35:21 -0000	1.3
@@ -7,7 +7,7 @@
  *
  * For licensing information, see the file 'LICENCE' in this directory.
  *
- * $Id: writev.c,v 1.2 2002/05/20 14:56:39 dwmw2 Exp $
+ * $Id: writev.c,v 1.3 2002/08/08 08:35:21 dwmw2 Exp $
  *
  */
 
@@ -28,7 +28,7 @@ static inline int mtd_fake_writev(struct
 	for (i=0; i<count; i++) {
 		if (!vecs[i].iov_len)
 			continue;
-		mtd->write(mtd, to, vecs[i].iov_len, &thislen, vecs[i].iov_base);
+		ret = mtd->write(mtd, to, vecs[i].iov_len, &thislen, vecs[i].iov_base);
 		totlen += thislen;
 		if (ret || thislen != vecs[i].iov_len)
 			break;


--
dwmw2

RE: JFFS2 peoblems with K3 strata flash on Dalhart

[Yuan, Cain]

Does  this concerned with the fails of JFFS2?  If is, why I can use JFFS2
system   just after burn JFFS2 fs image into  flash with the help of
redboot?


-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
To: Yuan, Cain
Cc: 'nico@cam.org'; linux-mtd@lists.infradead.org
Subject: Re: JFFS2 peoblems with K3 strata flash on Dalhart 



cain.yuan@intel.com said:
> 	I am now test JFFS2 file system on Dalhart with Redboot as
> boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for
> dalhart.

What erase size did you create your JFFS2 image with?

--
dwmw2

JFFS2 peoblems with K3 strata flash on Dalhart

[Yuan, Cain]

Hi all,
	I am now test JFFS2 file system on Dalhart with Redboot as
boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for dalhart.

	When I first burned JFFS2 and linux image into k3 flash and load &
run linux it will report some  warnings but can boot successful.
later  I can   create/del files  on JFFS2 filesystem.  But when I reset the
board,   load linux na drun again, it will report  thousands of warnings.
after linux bootup,  create/del file will all  fail.   Here is the msg:

Probing Lubbock flash at physical address 0x00000000
In check_cmd_set() find CFI Intel Extend command sets.
 Intel/Sharp Extended Query Table at 0x0031
  Feature/Command Support: 01E6
     - Chip Erase:         unsupported
     - Suspend Erase:      supported
     - Suspend Program:    supported
     - Legacy Lock/Unlock: unsupported
     - Queued Erase:       unsupported
     - Instant block lock: supported
     - Protection Bits:    supported
     - Page-mode read:     supported
     - Synchronous read:   supported
  Supported functions after Suspend: 01
     - Program after Erase Suspend: supported
  Block Status Register Mask: 0007
     - Lock Bit Active:      yes
     - Valid Bit Active:     yes
     - Unknown Bit 2 Active: yes
  Vcc Logic Supply Optimum Program/Erase Voltage: 0.3 V
Using word write method
cfi probe success.
Using RedBoot partition definition
Creating 7 MTD partitions on "Lubbock flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00080000 : "RedBoot[backup]"
0x00080000-0x00180000 : "unallocated space"
0x00180000-0x00980000 : "JFFS2"
0x00980000-0x00fc0000 : "unallocated space"
0x00fc0000-0x00fc1000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't end on an erase block -- force
read-only
0x00fe0000-0x01000000 : "FIS directory"
Linux Kernel Card Services 3.1.22
  options:  [pm]
...
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000:
0xad74 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004:
0xef02 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020008:
0xcf75 instead
  ......  thousands of   such " Magic bitmask ox1985 not found.. "
errors.....................
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 80K
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 68 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
INIT: version 2.74 booting
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 293 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00

 thousands of   such  " ARGH: About to write node to 0x0022039c.."   errors.


Linux login: root
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
In function do_write_oneword(), will call cain_deump_state.
Current status is FL_READY.
Current status is FL_READY.
Current status is FL_UNKNOWN.
Current status is FL_UNKNOWN.
Current status is FL_UNKNOWN.
Current status is FL_STATUS.
Write of 299 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 333 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 70 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 70 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
login[41]: root login  on `ttyS0'

[root@Linux /root]$touch jj
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 68 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
touch: Input/output error
[root@Linux /root]$


Does somebody here counter this problem before?  Any advice?  TIA!!

Best regards.

Cain

Re: JFFS2 peoblems with K3 strata flash on Dalhart

[David Woodhouse]

cain.yuan@intel.com said:
> 	I am now test JFFS2 file system on Dalhart with Redboot as
> boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for
> dalhart.

What erase size did you create your JFFS2 image with?

--
dwmw2