DEBUG_LOCK_BITS fix for Intel NOR flash

DEBUG_LOCK_BITS fix for Intel NOR flash

[Todd Poynor]

This patch seems to correctly access block lock status bits for at least
one Intel StrataFlash model.  Without at least half of this patch (the
chip->start adjustment), DEBUG_LOCK_BITS won't work well with
multi-partition flash, at the least.

I also needed to change the code to follow the flowchart given in a
recent StrataFlash datasheet: write command 0x90 followed by the block
address + 2, then read block address + 2.  The old code writes command
0x90 followed by hardcoded address 0x55, then reads block address + 2.

Can anybody verify whether Intel flash models exist that require the
0x55 address for block lock query?  If so, know of any way to
distinguish the two cases?

Absent any dissent this patch will go into CVS.  (Why all the concern
over a debug feature?  Because I want to also write code to query lock
status for other reasons.)  Thanks -- Todd

Index: linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c
===================================================================
--- linux-mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-22 19:15:05.000000000 +0000
+++ linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-22 19:39:12.000000000 +0000
@@ -1823,8 +1823,9 @@
 	struct cfi_private *cfi = map->fldrv_priv;
 	int status, ofs_factor = cfi->interleave * cfi->device_type;
 
+	adr += chip->start;
 	xip_disable(map, chip, adr+(2*ofs_factor));
-	cfi_send_gen_cmd(0x90, 0x55, 0, map, cfi, cfi->device_type, NULL);
+	map_write(map, CMD(0x90), adr+(2*ofs_factor));
 	chip->state = FL_JEDEC_QUERY;
 	status = cfi_read_query(map, adr+(2*ofs_factor));
 	xip_enable(map, chip, 0);

Re: DEBUG_LOCK_BITS fix for Intel NOR flash

[Jared Hulbert]

On 4/22/05, Todd Poynor <tpoynor@mvista.com> wrote:
> This patch seems to correctly access block lock status bits for at least
> one Intel StrataFlash model.  Without at least half of this patch (the
> chip->start adjustment), DEBUG_LOCK_BITS won't work well with
> multi-partition flash, at the least.
> 
> I also needed to change the code to follow the flowchart given in a
> recent StrataFlash datasheet: write command 0x90 followed by the block
> address + 2, then read block address + 2.  The old code writes command
> 0x90 followed by hardcoded address 0x55, then reads block address + 2.
> 
> Can anybody verify whether Intel flash models exist that require the
> 0x55 address for block lock query?  If so, know of any way to
> distinguish the two cases?
> 
> Absent any dissent this patch will go into CVS.  (Why all the concern
> over a debug feature?  Because I want to also write code to query lock
> status for other reasons.)  Thanks -- Todd
> 
> Index: linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c
> ===================================================================
> --- linux-mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c  2005-04-22 19:15:05.000000000 +0000
> +++ linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c       2005-04-22 19:39:12.000000000 +0000
> @@ -1823,8 +1823,9 @@
>         struct cfi_private *cfi = map->fldrv_priv;
>         int status, ofs_factor = cfi->interleave * cfi->device_type;
> 
> +       adr += chip->start;
>         xip_disable(map, chip, adr+(2*ofs_factor));
> -       cfi_send_gen_cmd(0x90, 0x55, 0, map, cfi, cfi->device_type, NULL);
> +       map_write(map, CMD(0x90), adr+(2*ofs_factor));
>         chip->state = FL_JEDEC_QUERY;
>         status = cfi_read_query(map, adr+(2*ofs_factor));
>         xip_enable(map, chip, 0);
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Not sure where the 0x55 came from.  This code looks generic enough to
work for multi and single partition Intel flash.