diff mbox

[(mtd-www),02/13] nand-data: updates to S30ML-P devices

Message ID 1323173269-19931-2-git-send-email-angus.clark@st.com
State New, archived
Headers show

Commit Message

Angus CLARK Dec. 6, 2011, 12:07 p.m. UTC 
Updates to Spansion S30ML-P devices:
	- expand names to differentiate between x8 and x16 devices
	- fix ID 5th byte: 0x01 to 0x10 (checked with datasheet; seems regression
          introduced as part of commit 165cfaa9cdb1054bbafa98f24f179c6aa101fbe6
          "nand-data: remove asterisks")

Signed-off-by: Angus Clark <angus.clark@st.com>
---
 nand-data/nanddata.csv |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

Comments

Brian Norris Dec. 7, 2011, 6:49 p.m. UTC | #1 
On Tue, Dec 6, 2011 at 4:07 AM, Angus CLARK <angus.clark@st.com> wrote:
> Updates to Spansion S30ML-P devices:
>        - expand names to differentiate between x8 and x16 devices

Expanding the names is probably good, but I don't really like the
"-FI{00,50}" piece. There are a few places where I used a wildcard in
the table to represent "don't care" characters. I think a lower-case
`x' might make sense, for example:

S30ML512P30-FIx0
S30ML512P50-FIx1
S30ML256P30-FIx0
...

Or perhaps a hyphen, which I think the datasheet is already using as a
don't care marker:

S30ML512P30-FI-0
S30ML512P50-FI-1
S30ML256P30-FI-0
...

Whichever way we go (hyphen or `x') should be standardized across the
table from now on.

>        - fix ID 5th byte: 0x01 to 0x10 (checked with datasheet; seems regression
>          introduced as part of commit 165cfaa9cdb1054bbafa98f24f179c6aa101fbe6
>          "nand-data: remove asterisks")

Hmm, not exactly a regression, but I overlooked it when merging in
changes to my local table. In fact, I have a data sheet that lists the
ID with 0x01, but it may be out of date. It's hard to find a current
one from Spansion's website, although a random copy I found off a
third party site confirms your given string, I think. Then, there's a
posting from Gernot Hoyler last year that gives this sample string.
It's slightly different (at id_data[2]):

   id_data[0]=0x01
   id_data[1]=0x56
   id_data[2]=0x00
   id_data[3]=0x01
   id_data[4]=0x10
   id_data[5]=0x00
   id_data[6]=0x00
   id_data[7]=0x00

I'm thinking:

id_data[2] = 0x00 or 0x01, depending on model as stated in data sheet.
I just ignored the 0x00 option.
id_data[4] = 0x10

Anyway, it may be apparent by now that I don't actually have a sample
of this chip myself. I'll go with whoever has a current data sheet
and/or actual chip.

Brian
Angus CLARK Dec. 9, 2011, 8:35 a.m. UTC | #2 
Hi Brian,

On 12/07/2011 06:49 PM, Brian Norris wrote:
> On Tue, Dec 6, 2011 at 4:07 AM, Angus CLARK <angus.clark@st.com> wrote:
>> Updates to Spansion S30ML-P devices:
>>        - expand names to differentiate between x8 and x16 devices
> 
> Expanding the names is probably good, but I don't really like the
> "-FI{00,50}" piece. There are a few places where I used a wildcard in
> the table to represent "don't care" characters. I think a lower-case
> `x' might make sense, for example:
> 
> S30ML512P30-FIx0
> S30ML512P50-FIx1
> S30ML256P30-FIx0
> ...
> 

Yes, agreed.  Will update the patch (and see comments below).

> 
>>        - fix ID 5th byte: 0x01 to 0x10 (checked with datasheet; seems regression
>>          introduced as part of commit 165cfaa9cdb1054bbafa98f24f179c6aa101fbe6
>>          "nand-data: remove asterisks")
> 
> Hmm, not exactly a regression, but I overlooked it when merging in
> changes to my local table. In fact, I have a data sheet that lists the
> ID with 0x01, but it may be out of date. It's hard to find a current
> one from Spansion's website, although a random copy I found off a
> third party site confirms your given string, I think. Then, there's a
> posting from Gernot Hoyler last year that gives this sample string.
> It's slightly different (at id_data[2]):
> 
>    id_data[0]=0x01
>    id_data[1]=0x56
>    id_data[2]=0x00
>    id_data[3]=0x01
>    id_data[4]=0x10
>    id_data[5]=0x00
>    id_data[6]=0x00
>    id_data[7]=0x00
> 
> I'm thinking:
> 
> id_data[2] = 0x00 or 0x01, depending on model as stated in data sheet.
> I just ignored the 0x00 option.
> id_data[4] = 0x10
> 

The datasheet I have is Rev 3.0 (April 8, 2008).  According to the revision
history, id_data[4] was updated in Rev 2.0.  Would this fit your datasheet?

id_data[2] is 0x01 for the "ECC-free/0% bad blocks" device, and 0x00 for the
"ECC required/2% bad blocks" model.  This "Notes" column already mentions this.

> Anyway, it may be apparent by now that I don't actually have a sample
> of this chip myself. I'll go with whoever has a current data sheet
> and/or actual chip.
> 

I haven't tested one myself either - I will see if we have any samples lying
around, but I suspect not...

Cheers,

Angus
Brian Norris Dec. 9, 2011, 8:42 p.m. UTC | #3 
On Fri, Dec 9, 2011 at 12:35 AM, Angus CLARK <angus.clark@st.com> wrote:
> On 12/07/2011 06:49 PM, Brian Norris wrote:
>> On Tue, Dec 6, 2011 at 4:07 AM, Angus CLARK <angus.clark@st.com> wrote:
>> Expanding the names is probably good, but I don't really like the
>> "-FI{00,50}" piece. There are a few places where I used a wildcard in
>> the table to represent "don't care" characters. I think a lower-case
>> `x' might make sense, for example:
>>
>> S30ML512P30-FIx0
>> S30ML512P50-FIx1
>> S30ML256P30-FIx0
>> ...
>>
>
> Yes, agreed.  Will update the patch (and see comments below).

OK. I will recommend lowercase 'x', since I use that already, since
some datasheets use 'X' or 'x', and since it doesn't conflict with
other potential uses for '-' in the chip name.

> The datasheet I have is Rev 3.0 (April 8, 2008).  According to the revision
> history, id_data[4] was updated in Rev 2.0.  Would this fit your datasheet?

Yes, my sheet is Rev 01 (Dec 14, 2006), so it's probably out of date.
I'll Ack the 'id_data[4] = 0x10'

> id_data[2] is 0x01 for the "ECC-free/0% bad blocks" device, and 0x00 for the
> "ECC required/2% bad blocks" model.  This "Notes" column already mentions this.
>
>> Anyway, it may be apparent by now that I don't actually have a sample
>> of this chip myself. I'll go with whoever has a current data sheet
>> and/or actual chip.
>
> I haven't tested one myself either - I will see if we have any samples lying
> around, but I suspect not...

No problem. We do have the actual ID string from Gernot which confirms
your change.

Brian
diff mbox

Patch

diff --git a/nand-data/nanddata.csv b/nand-data/nanddata.csv
index 92bee24..07505f7 100644
--- a/nand-data/nanddata.csv
+++ b/nand-data/nanddata.csv
@@ -65,12 +65,12 @@ 
 "Samsung","K9GAG08U0D","0xEC","0xD5","0xECD594293441",2048,4096,218,"512 KB","x8","N/A","Last page (1st byte in OOB = non FFh)",FALSE,TRUE,FALSE,TRUE,FALSE,"8-bit/512-byte (correction)",2,6,"Extended ID decode (Samsung)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,
 "Samsung","K9LBG08U1D","0xEC","0xD5","0xECD594293441",4096,4096,218,"512 KB","x8","N/A","Last page (1st byte in OOB = non FFh)",FALSE,TRUE,FALSE,TRUE,FALSE,"8-bit/512-byte (correction)",2,6,"Extended ID decode (Samsung)",FALSE,FALSE,TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,"Contains 2 K9GAG08U0D"
 "Samsung","K9HCG08U5D","0xEC","0xD5","0xECD594293441",8192,4096,218,"512 KB","x8","N/A","Last page (1st byte in OOB = non FFh)",FALSE,TRUE,FALSE,TRUE,FALSE,"8-bit/512-byte (correction)",2,6,"Extended ID decode (Samsung)",FALSE,FALSE,TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,"Contains 4 K9GAG08U0D"
-"Spansion","S30ML512P","0x01","0x76","0x0176010101",64,512,16,"512 KB","x8","N/A","1st or 2nd page (6th byte in OOB = non FFh)",TRUE,FALSE,FALSE,FALSE,TRUE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
-"Spansion","S30ML512P","0x01","0x56","0x0156010101",64,512,16,"512 KB","x16","N/A","1st or 2nd page (1st word in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
-"Spansion","S30ML256P","0x01","0x75","0x0175010101",32,512,16,"512 KB","x8","N/A","1st or 2nd page (6th byte in OOB = non FFh)",TRUE,FALSE,FALSE,FALSE,TRUE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
-"Spansion","S30ML256P","0x01","0x55","0x0155010101",32,512,16,"512 KB","x16","N/A","1st or 2nd page (1st word in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
-"Spansion","S30ML128P","0x01","0x73","0x0173010101",16,512,16,"512 KB","x8","N/A","1st or 2nd page (6th byte in OOB = non FFh)",TRUE,FALSE,FALSE,FALSE,TRUE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
-"Spansion","S30ML128P","0x01","0x53","0x0153030101",16,512,16,"512 KB","x16","N/A","1st or 2nd page (1st word in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x04"
+"Spansion","S30ML512P30-FI{00,50}","0x01","0x76","0x0176010110",64,512,16,"512 KB","x8","N/A","1st or 2nd page (6th byte in OOB = non FFh)",TRUE,FALSE,FALSE,FALSE,TRUE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
+"Spansion","S30ML512P50-FI{01,51}","0x01","0x56","0x0156010110",64,512,16,"512 KB","x16","N/A","1st or 2nd page (1st word in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
+"Spansion","S30ML256P30-FI{00,50}","0x01","0x75","0x0175010110",32,512,16,"512 KB","x8","N/A","1st or 2nd page (6th byte in OOB = non FFh)",TRUE,FALSE,FALSE,FALSE,TRUE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
+"Spansion","S30ML256P50-FI{01,51}","0x01","0x55","0x0155010110",32,512,16,"512 KB","x16","N/A","1st or 2nd page (1st word in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
+"Spansion","S30ML128P30-FI{00,50}","0x01","0x73","0x0173010110",16,512,16,"512 KB","x8","N/A","1st or 2nd page (6th byte in OOB = non FFh)",TRUE,FALSE,FALSE,FALSE,TRUE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x00"
+"Spansion","S30ML128P50-FI{01,51}","0x01","0x53","0x0153030110",16,512,16,"512 KB","x16","N/A","1st or 2nd page (1st word in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte (correction)","ORNAND",5,"ID Table (ORNAND blocksize)",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"Each model has x8/x16 bus versions, 2%/0% bad blocks; 2% => ID byte 3 = 0x04"
 "Samsung","K9K8G08U0A","0xEC","0xD3","0xECD3519558",1024,2048,64,"128 KB","x8","N/A","1st or 2nd page (1st byte in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte",1,5,"Extended ID decode",TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,"remains in Read ID mode"
 "Samsung","K9WAG08U1A","0xEC","0xD3","0xECD3519558",2048,2048,64,"128 KB","x8","N/A","1st or 2nd page (1st byte in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte",1,5,"Extended ID decode",FALSE,FALSE,TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,"remains in Read ID mode"
 "Samsung","K9NBG08U5A","0xEC","0xD3","0xECD3519558",4096,2048,64,"128 KB","x8","N/A","1st or 2nd page (1st byte in OOB = non FFh)",TRUE,FALSE,FALSE,TRUE,FALSE,"1-bit/512-byte",1,5,"Extended ID decode",FALSE,FALSE,TRUE,FALSE,TRUE,TRUE,TRUE,TRUE,TRUE,"remains in Read ID mode"