Re: JFFS2 with AM29LV256M

[ebiederman@lnxi.com (Eric W. Biederman)]

David Woodhouse <dwmw2@infradead.org> writes:

> On Thu, 2004-08-19 at 11:40 +0200, Manfred Gruber wrote:
> > Am Donnerstag, 19. August 2004 10:32 schrieben Sie:
> > 
> > > Our code which should handle suspending erases to allow programming is
> > > broken. So we disabled it -- you have to wait for erases to complete
> > > before the code will write data to the flash instead.
> > 
> > Then i have to change the do_write_oneword function to wait until erase is 
> > finshed ?
> 
> No, we did that already. And we put that printk in to remind us to fix
> it properly some time soon.

When you get to that please make certain the code is disabled for
chips coming from jedec_probe as by and large they don't support erase 
suspend.  I was wondering why there was a print statement in there with
no code connected to it. 

> > the difference is: cp rootfs.img /dev/mtd only uses:
> > 
> > MTD_write
> > MTD_do_write_buffer
> > and so on ...
> > 
> > and cp a file on the mounted image uses:
> > 
> > MTD do_write_buffer(): WRITE 0x0028641c(0xe0011985)
> > MTD do_write_oneword(): WRITE 0x0028641c(0xd5997a45)
> > MTD do_write_oneword(): software timeout
> 
> Hmmm ok, so it's do_write_oneword() which is broken.

Possibly it still could be the chip. do_write_oneword since it
is read the data back anyway confirms that the data read back is
what was written.  I don't believe the write_buffer code path
does any but the most rudimentary sanity checks.

Eric