flash status after unlocking

flash status after unlocking

[Dmitry Krivoschokov]

    Hi all,

it appears that cfi flash unlocking routines always leaves a flash chip 
in status mode (if CONFIG_MTD_XIP is not set).
But in some cases it is desired that the chip remains in read array 
mode, for linear cramfs at least.
So I've added code to put a chip in read array mode after unlocking, see 
patch below (the patch against 2.4 kernel, sorry), tested on OMAP1610. 
The patch is for Intel's command set only,  though it is easy to add the 
fix to others.
If  no complaints for the fix I can test it with the latest kernel and 
submit a patch.

    Thanks,
       Dmitry

diff -upr linux-2.4.orig/drivers/mtd/chips/cfi_cmdset_0001.c 
linux-2.4/drivers/mtd/chips/cfi_cmdset_0001.c
--- linux-2.4.orig/drivers/mtd/chips/cfi_cmdset_0001.c  2005-04-06 
03:01:44.000000000 +0400
+++ linux-2.4/drivers/mtd/chips/cfi_cmdset_0001.c       2005-08-23 
15:31:31.000000000 +0400
@@ -1920,6 +1920,13 @@ static int __xipram do_xxlock_oneblock(s
        /* Done and happy. */
        chip->state = FL_STATUS;
        xip_enable(map, chip, adr);
+
+#ifndef CONFIG_MTD_XIP
+       if (chip->state != FL_POINT && chip->state != FL_READY) {
+               map_write(map, CMD(0xff), adr);
+               chip->state = FL_READY;
+       }
+#endif
        put_chip(map, chip, adr);
        spin_unlock(chip->mutex);
        return 0;

Re: flash status after unlocking

[Nicolas Pitre]

On Wed, 24 Aug 2005, Dmitry Krivoschokov wrote:

>    Hi all,
> 
> it appears that cfi flash unlocking routines always leaves a flash chip in
> status mode (if CONFIG_MTD_XIP is not set).
> But in some cases it is desired that the chip remains in read array mode, for
> linear cramfs at least.
> So I've added code to put a chip in read array mode after unlocking, see patch
> below (the patch against 2.4 kernel, sorry), tested on OMAP1610. The patch is
> for Intel's command set only,  though it is easy to add the fix to others.
> If  no complaints for the fix I can test it with the latest kernel and submit
> a patch.

Please don't do that.

The thing is that most MTD methods have the same issue like write for 
example.

If you're using the flash for linear cramfs without the MTD XIP support 
then you probably already know that you must pay special attention to 
how you use MTD in parallel with linear cramfs.  Therefore if you must 
unlock the flash for whatever reason that's certainly because you want 
to erase and/or write the flash which will have the same 
remain-in-status-mode issue.

In those cases the best line of action is to always read back a bit from 
the flash to manually force it back into array mode.  Something like:

	flash-unlock /dev/mtd2 && dd if=/dev/mtd2 of=/dev/null count=1

Sames goes for flash write, lock, erase, etc.

This way the driver doesn't need to be modified for this very particular 
usage case.


Nicolas