jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails

jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails

[Norbert van Bolhuis]

My board has a regular AMD/Spansion compatible flash device. It's a
Spansion S29AL016D (2MB) which supports 8/16 bit access.
We use it in 8 bit and top boot block mode.

I thought the linux kernel would have no problem recognizing/supporting this
(regular) flash device. I was wrong.

The S29AL016D/AM29LV160DT datasheet says the following:

                                   first     second    third     fourth (read)
                                   addr/data addr/data addr/data addr/data
Manufacturer ID, word             555/AA    2AA/55    555/90    X00/01
                  byte             AAA/AA    555/55    AAA/90    X00/01
Device ID (top boot block), word  555/AA    2AA/55    555/90    X01/22C4
                             byte  AAA/AA    555/55    AAA/90    X02/C4

Unfortunately the linux kernel does not recognize the chip.
The jedec_probe_chip function fails to recognize the chip, even though it's
present in the jedec_table[], the is the entry that represents the S29AL016D
(the S29AL016D is comptabile with AM29LV160DT):

                 .mfr_id         = MANUFACTURER_AMD,
                 .dev_id         = AM29LV160DT,
                 .name           = "AMD AM29LV160DT",
                 .uaddr          = {
                         [0] = MTD_UADDR_0x0AAA_0x0555,  /* x8 */
                         [1] = MTD_UADDR_0x0555_0x02AA   /* x16 */
                 },
                 .DevSize        = SIZE_2MiB,
                 .CmdSet         = P_ID_AMD_STD,
                 .NumEraseRegions= 4,
                 .regions        = {
                         ERASEINFO(0x10000,31),
                         ERASEINFO(0x08000,1),
                         ERASEINFO(0x02000,2),
                         ERASEINFO(0x04000,1)
                 }

The above jedec_table entry seems to be correct and it should be the one to
find/match.

The problem when probing if "cfi->interleave=1 and cfi->device_type=2 (x16)" is
that the device is not put into autoselect mode properly.
This is because the unlock addresses are multiplied with the cfi->device_type
(this is done by cfi_build_cmd_addr) and thus the autoselect mode
(for MTD_UADDR_0x0AAA_0x0555,  /* x8 */) is entered by writing:
address=0x1554, data=0xaa
address=0x0aaa, data=0x55
address=0x1554, data=0x90

This fails to put the chip into autoselect mode.
Here's the kernel corresponding kernel console output:
reset unlock called aaa 555
Search for id:(0a 00) interleave(1) type(2)
Note that 0a 00 is ordinary data.

Other unlock addresses (2aa 555 and 555 aaa) do get the device in autoselect mode,
but now there are two other problems which make jedec_match fail:
-1- the following code from jedec_match makes matching always fail for any x16
     device in x8 mode ?
         if ( cfi->mfr != mfr) || cfi->id != id ) {
                 goto match_done;
         }
id is 16 bit (0x22c4), so it won't match 0xc4.

-2- the unlock address is wrong. Here's the corresponding kernel console output:
reset unlock called 555 2aa
Search for id:(01 c4) interleave(1) type(2)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x02aa
MTD jedec_match(): 0x0aaa 0x0555 did not match 0x0555 0x02aa
reset unlock called 555 aaa
Search for id:(01 c4) interleave(1) type(2)
MTD jedec_match(): Check fit 0x00000000 + 0x00200000 = 0x00200000
MTD jedec_match(): check unlock addrs 0x0555 0x0aaa
MTD jedec_match(): 0x0aaa 0x0555 did not match 0x0555 0x0aaa

It wants to match with unlock address 0x0aaa 0x0555 (because this is the one
listed in the jedec_table[] entry for cfi->device_type=2=x16) and both pair
of unlock addresses (which do get the chip in autoselect mode) do not match.


I'm not sure whether the kernel should recognize the chip as 8 or 16 bit, I
guess 16 bit. Let me anyway discuss the 8 bit case also.

The problem when probing if "cfi->interleave=1 and cfi->device_type=1 (x8)" is
twofold:
-1- device id is not read correctly. After putting the device in "Autoselect Mode"
     the device id is read from address 1 (it should be 2). This makes the device id
     equal to the manufacture id. Here's the corresponding kernel console output:
reset unlock called aaa 555
Search for id:(01 01) interleave(1) type(1)

-2- even if the device id and manufacturer id would be read correctly the
     chip won't be recognized anyway since jedec_match has the following code:
                 /* bjd: it seems that if we do this, we can end up
                  * detecting 16bit flashes as an 8bit device, even though
                  * there aren't.
                  */
                 if (finfo->dev_id > 0xff) {
                         DEBUG( MTD_DEBUG_LEVEL3, "%s(): ID is not 8bit\n",
                                __func__);
                         goto match_done;

Because finfo->devid=AM29LV160DT=0x22C4 -> the ID is not 8 bit.


I'm sure I miss something. Our linux kernel is ancient (2.4.25) but more recent
linux kernel seem to have the same mtd/jedec code in this repect.

I anyone could help me pointing out what is wrong it would be great.

BR,
N. van Bolhuis.


Btw. is the linux mtd mailing list (linux-mtd@lists.infradead.org) still alive ?
      I couldn't reach the archives at http://lists.infradead.org/pipermail/linux-mtd/

-- 
This message has been scanned for viruses and is believed to be clean

Re: jedec probe for AMD/Spansion flash (16 bit) device in 8 bit mode fails

[N. van Bolhuis]

OK, so there's nothing wrong with the linux-mtd mailing
list. It's alive.
I guess the archives are moved to
www.infradead.org/pipermail/linux-mtd and many existing
pages still refer to list.infradead.org/pipermail/linux-mtd

To be complete and to provide an answer (to my own question)
I'll show what I did to make things work.

Btw. in my previous post I mentioned somewhere

"It wants to match with unlock address 0x0aaa 0x0555 (because this is the one
 listed in the jedec_table[] entry for cfi->device_type=2=X16) and both pair
 of unlock addresses (which do get the chip in autoselect mode) do not match."

This is incorrect.
"0x0aaa 0x0555" is not listed in the jedec_table[] entry for x16. It's selected
because of the finfo_uaddr function having this if statement:

 
if (uaddr != MTD_UADDR_NOT_SUPPORTED ) {
    uaddr = finfo->uaddr[0];
}

return uaddr;

So, in x16 always "0x0aaa 0x0555" (entry for x8) is considered to be the unlock
address.

But this doesn't hurt me since our 16 bit AMD/Spansion flash device needs to
be recognized in 8 bit mode anyway since (obviously) it is used in 8 bit mode.


Looking through the archives shows more developers have dealt with this problem.
The unlock_addr function is suspicious. There's even a patch for this function
to make things work, but dwmw2 rejected it because things are supposed to be shifted
automatically for different device modes (x8, x16, x32).
Somewhere in the archives it is mentioned the device id should be read from
address 2 (and not 1) (for an AM29LV800 in byte mode). I suffer from this problem too.
Also somewhere in the archives the finfo_uaddr function is blamed, in particular
the if statement I showed above.

Obviously the jedec_probe simply doesn't work for all possible flash device and
(embedded) board configurations. This is exactly what the comment
in jedec_probe.c (above the function jedec_match) suggests.

I added the following to jedec_probe.c to make things work:

#define AM29LV160DTBYTE 0x0001

        }, {
                .mfr_id         = MANUFACTURER_AMD,
                .dev_id         = AM29LV160DTBYTE,
                .name           = "S29AL016D TB (byte mode)",
                .uaddr          = {
                        [0] = MTD_UADDR_0x0AAA_0x0555 /* x8 */
                },
                .DevSize        = SIZE_2MiB,
                .CmdSet         = P_ID_AMD_STD,
                .NumEraseRegions= 4,
                .regions        = {
                        ERASEINFO(0x10000,31),
                        ERASEINFO(0x08000,1),
                        ERASEINFO(0x02000,2),
                        ERASEINFO(0x04000,1)
                }




Not wanting to break functionality for some native 8 bit flash devices we use
(which do read their device id on address 1) I added device id 0x0001 since
it is guaranteed to be the same as the manfacturer id and was still free.


BR, 
N. van Bolhuis. 

-- 
This message has been scanned for viruses and is believed to be clean