Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.
On Tue, Aug 17, 2010 at 06:18:07PM +0200, Philippe De Muyter wrote: > On Tue, Aug 17, 2010 at 05:57:00PM +0200, Stefan Roese wrote: > > Hi Philippe, > > > > unfortunately your patch base64 encoded. :-( > > Are you sure ? It isn't so in my `sent' folder. > Thinking again about it, it must happen somewhere between my computer and yours, because of the `micro' character (here replaced by 'u') in the `20us' clause in the commit text. Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.
On Tuesday 17 August 2010 18:18:07 Philippe De Muyter wrote: > > unfortunately your patch base64 encoded. :-( > > Are you sure ? It isn't so in my `sent' folder. Here from the header in my inbox: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 > > > diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log > > > -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47) > > > +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19) > > > > You still have this "diff" stuff in the commit text. This results in the > > remaining stuff being dropped by git after applying. Please remove those > > diff lines. > > Sorry about that; I had tested with `patch', but of course it does not > need the commit text part :( > > > And please don't send base64 encoded mails. I strongly suggest using > > "git send-email". > > My experience with `git send-email' is not that good (none of the mails I > sent this way were answered), but I'll try again. Did you find them on the list via a mailing archive? Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.
On Tue, Aug 17, 2010 at 05:57:00PM +0200, Stefan Roese wrote: > Hi Philippe, > > unfortunately your patch base64 encoded. :-( Are you sure ? It isn't so in my `sent' folder. > > Even though git seems to be able to handle this, your commit text still has > some problems. Please see below: > > On Tuesday 17 August 2010 11:49:24 Philippe De Muyter wrote: > > I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30 > > 256-Mbit 65nm flash chips. > > > > After some time :( searching for bugs in our board or soft, we have > > discovered that those 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 working workaround is given, which I have applied and tested with success > > : > > > > Workaround: If the interval between 60h and its subsequent command > > can be guaranteed within 20μs, 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 90hBlock Address > >Read Lock Status > > 2 Read Block Address + 02h > > (2)(3) (1) > > 360h Block Address > > (2)(3) (1) Lock/Unlock/RCR > > Configuration 4 D0h/01h/03hBlock 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 20μs. > > > > And here is a log comparison of a simple (destructive) flash test without > > and with the workaround. > > > > diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log > > -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47) > > +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19) > > You still have this "diff" stuff in the commit text. This results in the > remaining stuff being dropped by git after applying. Please remove those diff > lines. Sorry about that; I had tested with `patch', but of course it does not need the commit text part :( > And please don't send base64 encoded mails. I strongly suggest using > "git send-email". My experience with `git send-email' is not that good (none of the mails I sent this way were answered), but I'll try again. Thanks 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.
I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.
After some time :( searching for bugs in our board or soft, we have
discovered that those 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 working workaround is given, which I have applied and tested with success :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20μs, 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 90hBlock Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
360h Block Address
(2)(3) (1) Lock/Unlock/RCR Configuration
4 D0h/01h/03hBlock 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 20μs.
And here is a log comparison of a simple (destructive) flash test without
and with the workaround.
diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
-U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
+U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
CPU: Freescale MCF5484
CPU CLK 200 MHz BUS CLK 100 MHz
Board: Macq Electronique ME2060
I2C: ready
DRAM: 64 MiB
FLASH: 32 MiB
In:serial
Out: serial
Err: serial
Net: FEC0, FEC1
-> flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 32 MB in 259 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
Sector Start Addresses:
FE00 RO FE008000 RO FE01 RO FE018000 RO FE02 RO
FE04 RO FE06 RO FE08 RO FE0A RO FE0C RO
...
FFF8 RO FFFA RO FFFC RO FFFE RO
-> protect off all
Un-Protect Flash Bank # 1
...
done
-> erase all
Erase Flash Bank # 1
...
done
-> cp.b 100 fe00 200
-Copy to Flash... Flash not Erased
+Copy to Flash... done
->
Signed-off-by: Philippe De Muyter
---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2d09caf..809ff0e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1348,15 +1350,32 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
- flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
- if (prot)
- flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_SET);
- else
+ /*
+* see errata called
+* "Numonyx Axcell P33/P30 Specification Update" :)
+*/
+ flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+ if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+ prot)) {
+ /*
+* cmd must come before FLASH_CMD_PROTECT + 20us
+* Disable interrupts which might cause a
timeout here.
+*/
+ int flag = disable_interrupts ();
+
