AG-AND requested changes

[David A. Marlin]

Thomas:

I've been working on a couple of issues using the HN29V1G91T-30 (AG-AND) 
chips, and have a possible solution (patch attached).  The issues are:

1) if a block contains static data (not rewritten), but other blocks in 
the same 256 block group are rewritten many times, some of the bits in 
the static data may be flipped resulting in data loss.  I believe the 
wear leveling in JFFS2 will prevent this from occurring on the file 
system partition, but not for the Bad Block Table.

To address this, I have set up a 'mask' that will match other blocks in 
the same 256 block group as the Bad Block Table, and added code to 
rewrite the Bad Block Table when any of these blocks is erased.  This 
should ensure that the Bad Block Table is also rewritten periodically so 
as not to lose data.

2) according to the chip documentation, if power is suddenly removed 
during an erase operation, a 'device recovery' procedure must be 
performed when power is reapplied in order to ensure correct device 
operation.  This procedure involves applying a command sequence at a 
specific address.

To facilitate this, I have added some additional command definitions, 
and modified the nand_command_lp routine to use them.


Note: I have two additional comments regarding the proposed solutions.

1) The code changes use an array of bad block table addresses (one for 
each chip) in case the erase spans multiple chips and BBT per chip is 
used.  Based on my testing I don't think this ever occurs (at least for 
this device).  If we could assume that it would never occur, the code 
for this could be simplified (no array or loops required).

2) The command for 'device recovery' is a two cycle command, but the 
first command byte is 0x00 (same as for READ0).  Since the process 
requires that we can distinguish between a recovery and a read 
operation, I added a high order bit to the initial command (0x100) to 
make it unique and masked it off when actually sending the command. 
Please let me know if you have a more elegant (or acceptable) solution.


Thank you,

d.marlin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ag-and-02.patch
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20050112/0144dfc8/attachment.pl