JFFS2 with AM29LV256M
Eric W. Biederman
ebiederman at lnxi.com
Thu Aug 19 06:45:48 EDT 2004
David Woodhouse <dwmw2 at 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
More information about the linux-mtd
mailing list