Patchwork Numonyx NOR and chip->mutex bug?

login
register
mail settings
Submitter Joakim Tjernlund
Date Feb. 11, 2011, 3:39 p.m.
Message ID <OF24342672.F4BEF9FA-ONC1257834.0055AEE1-C1257834.00560756@transmode.se>
Download mbox | patch
Permalink /patch/82774/
State New
Headers show

Comments

Joakim Tjernlund - Feb. 11, 2011, 3:39 p.m.
Michael Cashwell <mboards@prograde.net> wrote on 2011/02/11 16:05:54:
>
> On Feb 10, 2011, at 12:54 PM, Anders Grafström wrote:
>
> > On 2011-02-10 17:43, Michael Cashwell wrote:
> >> On Feb 10, 2011, at 10:59 AM, Michael Cashwell wrote:
> >> Troublesome 65nm parts:
> >> run 1:
> >> NOR Flash: block erase suspended and resumed 29 times.
> >> buffered write fails.
> >
> > Buffered write fails with SR[4] set?
>
> The error messages variously report block locked and Vpp errors but they are not legitimate. I changed them to actually print the status word and it's often 0xffff or other values with set bits in the upper byte. That tells me the chip is not properly in status-read mode at that point.
>
> So I think the answer to your question is no, not reliably with SR[4] set because it's reading array data instead of status.
>
> > Have you configured with CONFIG_MTD_UBI_DEBUG_PARANOID so that UBI does the all 0xff check after erase?
>
> I've used some of the debugging modes at the top of cfi_cmdset_0001.c but I had not used the config option. I will do that and report back.
>
> > I'm wondering if the blocks being written to are in a properly erased state.
>
> Yes, it's a possibility. However, I've never seen an erase report any error.

Mike, does this small patch change anything:

Possibly this u-boot add on would make it easier to test suspend/resume:

http://lists.infradead.org/pipermail/linux-mtd/2008-April/021280.html
Michael Cashwell - Feb. 14, 2011, 4:15 p.m.
On Feb 11, 2011, at 10:39 AM, Joakim Tjernlund wrote:

>>> I'm wondering if the blocks being written to are in a properly erased state.
>> 
>> Yes, it's a possibility. However, I've never seen an erase report any error.
> 
> Mike, does this small patch change anything:
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index 9772a62..bdcd8c1 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -808,7 +808,8 @@ static int chip_ready (struct map_info *map, struct flchip *chip, unsigned long
> 		     (mode == FL_WRITING && (cfip->SuspendCmdSupport & 1))))
> 			goto sleep;
> 
> -
> +		/* Numonyx Axcell chips needs a Read Status */
> +		map_write(map, CMD(0x70), adr);
> 		/* Erase suspend */
> 		map_write(map, CMD(0xB0), adr);

No, this doesn't change the failures I see.

-Mike

Patch

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 9772a62..bdcd8c1 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -808,7 +808,8 @@  static int chip_ready (struct map_info *map, struct flchip *chip, unsigned long
 		     (mode == FL_WRITING && (cfip->SuspendCmdSupport & 1))))
 			goto sleep;

-
+		/* Numonyx Axcell chips needs a Read Status */
+		map_write(map, CMD(0x70), adr);
 		/* Erase suspend */
 		map_write(map, CMD(0xB0), adr);