* [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug.
@ 2010-10-19 14:24 Philippe De Muyter
2010-10-21 8:39 ` Artem Bityutskiy
0 siblings, 1 reply; 6+ messages in thread
From: Philippe De Muyter @ 2010-10-19 14:24 UTC (permalink / raw)
To: linux-mtd
Some flash chips have a small but annoying bug, documented in
"Numonyx Axcell P33/P30 256-Mbit Specification Update"
It states :
When customer uses [...] block unlock, the block lock status might
be altered inadvertently. Lock status might be set to either 01h
or 03h unexpectedly (00h as expected data), which leads to
program/erase failure on certain blocks.
A workaround is given, (summary : issue a "Read Lock Status" before
the "Lock" or "Unlock" command) which I have applied and tested
with success.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
---
drivers/mtd/chips/cfi_cmdset_0001.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 9e2b7e9..0d0ae41 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2047,6 +2047,7 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
{
struct cfi_private *cfi = map->fldrv_priv;
struct cfi_pri_intelext *extp = cfi->cmdset_priv;
+ int ofs_factor = cfi->interleave * cfi->device_type;
int udelay;
int ret;
@@ -2062,6 +2063,14 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
ENABLE_VPP(map);
xip_disable(map, chip, adr);
+ /*
+ * Issue a "Read Lock Status" before the "Lock" or "Unlock" :
+ * see errata "Numonyx Axcell P33/P30 Specification Update" :)
+ */
+ map_write(map, CMD(0x90), adr+(2*ofs_factor));
+ chip->state = FL_JEDEC_QUERY;
+ cfi_read_query(map, adr+(2*ofs_factor));
+
map_write(map, CMD(0x60), adr);
if (thunk == DO_XXLOCK_ONEBLOCK_LOCK) {
map_write(map, CMD(0x01), adr);
--
1.7.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug.
2010-10-19 14:24 [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug Philippe De Muyter
@ 2010-10-21 8:39 ` Artem Bityutskiy
2010-10-21 9:33 ` Philippe De Muyter
0 siblings, 1 reply; 6+ messages in thread
From: Artem Bityutskiy @ 2010-10-21 8:39 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Nicolas Pitre, linux-mtd
On Tue, 2010-10-19 at 16:24 +0200, Philippe De Muyter wrote:
> Some flash chips have a small but annoying bug, documented in
> "Numonyx Axcell P33/P30 256-Mbit Specification Update"
>
> It states :
> When customer uses [...] block unlock, the block lock status might
> be altered inadvertently. Lock status might be set to either 01h
> or 03h unexpectedly (00h as expected data), which leads to
> program/erase failure on certain blocks.
>
> A workaround is given, (summary : issue a "Read Lock Status" before
> the "Lock" or "Unlock" command) which I have applied and tested
> with success.
>
> Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Is this Numonyx-specific issue? Should there be some kind of "if
(numonyx)" statement?
May be Nicolas could validate the patch?
> ---
> drivers/mtd/chips/cfi_cmdset_0001.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
> index 9e2b7e9..0d0ae41 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -2047,6 +2047,7 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
> {
> struct cfi_private *cfi = map->fldrv_priv;
> struct cfi_pri_intelext *extp = cfi->cmdset_priv;
> + int ofs_factor = cfi->interleave * cfi->device_type;
> int udelay;
> int ret;
>
> @@ -2062,6 +2063,14 @@ static int __xipram do_xxlock_oneblock(struct map_info *map, struct flchip *chip
> ENABLE_VPP(map);
> xip_disable(map, chip, adr);
>
> + /*
> + * Issue a "Read Lock Status" before the "Lock" or "Unlock" :
> + * see errata "Numonyx Axcell P33/P30 Specification Update" :)
> + */
> + map_write(map, CMD(0x90), adr+(2*ofs_factor));
> + chip->state = FL_JEDEC_QUERY;
> + cfi_read_query(map, adr+(2*ofs_factor));
> +
> map_write(map, CMD(0x60), adr);
> if (thunk == DO_XXLOCK_ONEBLOCK_LOCK) {
> map_write(map, CMD(0x01), adr);
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug.
2010-10-21 8:39 ` Artem Bityutskiy
@ 2010-10-21 9:33 ` Philippe De Muyter
2010-10-21 10:29 ` Artem Bityutskiy
0 siblings, 1 reply; 6+ messages in thread
From: Philippe De Muyter @ 2010-10-21 9:33 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: Nicolas Pitre, linux-mtd
On Thu, Oct 21, 2010 at 11:39:58AM +0300, Artem Bityutskiy wrote:
> On Tue, 2010-10-19 at 16:24 +0200, Philippe De Muyter wrote:
> > Some flash chips have a small but annoying bug, documented in
> > "Numonyx Axcell P33/P30 256-Mbit Specification Update"
> >
> > It states :
> > When customer uses [...] block unlock, the block lock status might
> > be altered inadvertently. Lock status might be set to either 01h
> > or 03h unexpectedly (00h as expected data), which leads to
> > program/erase failure on certain blocks.
> >
> > A workaround is given, (summary : issue a "Read Lock Status" before
> > the "Lock" or "Unlock" command) which I have applied and tested
> > with success.
> >
> > Signed-off-by: Philippe De Muyter <phdm@macqel.be>
>
> Is this Numonyx-specific issue? Should there be some kind of "if
> (numonyx)" statement?
This is clearly a bug specific to some Numonyx flashes.
My chips have Manufacturer ID: 0x89, Device ID: 0x881B, but there are
other chips in the same family. The errata
http://www.numonyx.com/Documents/Specification%20Updates/509003_P3X_65nm_3V_256Mbit_Discrete.pdf does not list the ManufacturerIDs/DeviceIDs of the affected
chips.
Philippe
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug.
2010-10-21 9:33 ` Philippe De Muyter
@ 2010-10-21 10:29 ` Artem Bityutskiy
2010-10-21 16:32 ` Nicolas Pitre
0 siblings, 1 reply; 6+ messages in thread
From: Artem Bityutskiy @ 2010-10-21 10:29 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linux-mtd, Nicolas Pitre
On Thu, 2010-10-21 at 11:33 +0200, Philippe De Muyter wrote:
> On Thu, Oct 21, 2010 at 11:39:58AM +0300, Artem Bityutskiy wrote:
> > On Tue, 2010-10-19 at 16:24 +0200, Philippe De Muyter wrote:
> > > Some flash chips have a small but annoying bug, documented in
> > > "Numonyx Axcell P33/P30 256-Mbit Specification Update"
> > >
> > > It states :
> > > When customer uses [...] block unlock, the block lock status might
> > > be altered inadvertently. Lock status might be set to either 01h
> > > or 03h unexpectedly (00h as expected data), which leads to
> > > program/erase failure on certain blocks.
> > >
> > > A workaround is given, (summary : issue a "Read Lock Status" before
> > > the "Lock" or "Unlock" command) which I have applied and tested
> > > with success.
> > >
> > > Signed-off-by: Philippe De Muyter <phdm@macqel.be>
> >
> > Is this Numonyx-specific issue? Should there be some kind of "if
> > (numonyx)" statement?
>
> This is clearly a bug specific to some Numonyx flashes.
> My chips have Manufacturer ID: 0x89, Device ID: 0x881B, but there are
> other chips in the same family. The errata
> http://www.numonyx.com/Documents/Specification%20Updates/509003_P3X_65nm_3V_256Mbit_Discrete.pdf does not list the ManufacturerIDs/DeviceIDs of the affected
> chips.
CCed Nicolas correctly.
Anyway, if this affects only subset of chips, it make sense to make this
quirk conditional, because this might affect boot speed, e.g., if some
systems unlock all blocks on boot-up.
Nicolas, the original patch was here, would you validate it please?
http://lists.infradead.org/pipermail/linux-mtd/2010-October/032783.html
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug.
2010-10-21 10:29 ` Artem Bityutskiy
@ 2010-10-21 16:32 ` Nicolas Pitre
2010-10-21 19:34 ` Philippe De Muyter
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Pitre @ 2010-10-21 16:32 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-mtd
On Thu, 21 Oct 2010, Artem Bityutskiy wrote:
> On Thu, 2010-10-21 at 11:33 +0200, Philippe De Muyter wrote:
> > On Thu, Oct 21, 2010 at 11:39:58AM +0300, Artem Bityutskiy wrote:
> > > On Tue, 2010-10-19 at 16:24 +0200, Philippe De Muyter wrote:
> > > > Some flash chips have a small but annoying bug, documented in
> > > > "Numonyx Axcell P33/P30 256-Mbit Specification Update"
> > > >
> > > > It states :
> > > > When customer uses [...] block unlock, the block lock status might
> > > > be altered inadvertently. Lock status might be set to either 01h
> > > > or 03h unexpectedly (00h as expected data), which leads to
> > > > program/erase failure on certain blocks.
> > > >
> > > > A workaround is given, (summary : issue a "Read Lock Status" before
> > > > the "Lock" or "Unlock" command) which I have applied and tested
> > > > with success.
> > > >
> > > > Signed-off-by: Philippe De Muyter <phdm@macqel.be>
> > >
> > > Is this Numonyx-specific issue? Should there be some kind of "if
> > > (numonyx)" statement?
> >
> > This is clearly a bug specific to some Numonyx flashes.
> > My chips have Manufacturer ID: 0x89, Device ID: 0x881B, but there are
> > other chips in the same family. The errata
> > http://www.numonyx.com/Documents/Specification%20Updates/509003_P3X_65nm_3V_256Mbit_Discrete.pdf does not list the ManufacturerIDs/DeviceIDs of the affected
> > chips.
>
> CCed Nicolas correctly.
>
> Anyway, if this affects only subset of chips, it make sense to make this
> quirk conditional, because this might affect boot speed, e.g., if some
> systems unlock all blocks on boot-up.
That is probably quite unlikely to make a difference given that there is
no result delay involved.
However, does the erratum workaround imply that the status actually has
to be read? In other words, can you simply issue CMD 90 without calling
cfi_read_query()?
Nicolas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug.
2010-10-21 16:32 ` Nicolas Pitre
@ 2010-10-21 19:34 ` Philippe De Muyter
0 siblings, 0 replies; 6+ messages in thread
From: Philippe De Muyter @ 2010-10-21 19:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-mtd, Artem Bityutskiy
Hello Nicolas,
On Thu, Oct 21, 2010 at 12:32:02PM -0400, Nicolas Pitre wrote:
> On Thu, 21 Oct 2010, Artem Bityutskiy wrote:
>
> > On Thu, 2010-10-21 at 11:33 +0200, Philippe De Muyter wrote:
> > > On Thu, Oct 21, 2010 at 11:39:58AM +0300, Artem Bityutskiy wrote:
> > > > On Tue, 2010-10-19 at 16:24 +0200, Philippe De Muyter wrote:
> > > > > Some flash chips have a small but annoying bug, documented in
> > > > > "Numonyx Axcell P33/P30 256-Mbit Specification Update"
> > > > >
> > > > > It states :
> > > > > When customer uses [...] block unlock, the block lock status might
> > > > > be altered inadvertently. Lock status might be set to either 01h
> > > > > or 03h unexpectedly (00h as expected data), which leads to
> > > > > program/erase failure on certain blocks.
> > > > >
> > > > > A workaround is given, (summary : issue a "Read Lock Status" before
> > > > > the "Lock" or "Unlock" command) which I have applied and tested
> > > > > with success.
> > > > >
> > > > > Signed-off-by: Philippe De Muyter <phdm@macqel.be>
> > > >
> > > > Is this Numonyx-specific issue? Should there be some kind of "if
> > > > (numonyx)" statement?
> > >
> > > This is clearly a bug specific to some Numonyx flashes.
> > > My chips have Manufacturer ID: 0x89, Device ID: 0x881B, but there are
> > > other chips in the same family. The errata
> > > http://www.numonyx.com/Documents/Specification%20Updates/509003_P3X_65nm_3V_256Mbit_Discrete.pdf does not list the ManufacturerIDs/DeviceIDs of the affected
> > > chips.
> >
> > CCed Nicolas correctly.
> >
> > Anyway, if this affects only subset of chips, it make sense to make this
> > quirk conditional, because this might affect boot speed, e.g., if some
> > systems unlock all blocks on boot-up.
>
> That is probably quite unlikely to make a difference given that there is
> no result delay involved.
>
> However, does the erratum workaround imply that the status actually has
> to be read? In other words, can you simply issue CMD 90 without calling
> cfi_read_query()?
Here is the relevant excerpt of the errata :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20us, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
Data bus Address bus Remarks
Sequence
1 90h Block Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
3 60h Block Address
(2)(3) (1) Lock/Unlock/RCR Configuration
4 D0h/01h/03h Block Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20us.
Philippe
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-21 19:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-19 14:24 [PATCH] mtd: Apply Numonyx Axcell P33/P30 workaround for Lock/Unlock bug Philippe De Muyter
2010-10-21 8:39 ` Artem Bityutskiy
2010-10-21 9:33 ` Philippe De Muyter
2010-10-21 10:29 ` Artem Bityutskiy
2010-10-21 16:32 ` Nicolas Pitre
2010-10-21 19:34 ` Philippe De Muyter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).