MTD support for Intel E28F016S3 ?

MTD support for Intel E28F016S3 ?

[Robert Kaiser]

Hi,

I am trying to implement JFFS/MTD support for the SSV DNPC module.
This module has an Intel E28F016S3 which does not appear to be CFI
compliant. Which chip driver should I use for this one (is there any) ?

Rob

----------------------------------------------------------------
Robert Kaiser                          email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10

Re: MTD support for Intel E28F016S3 ?

[David Woodhouse]

rob@sysgo.de said:
> I am trying to implement JFFS/MTD support for the SSV DNPC module.
> This module has an Intel E28F016S3 which does not appear to be CFI
> compliant. Which chip driver should I use for this one (is there any)
> ? 

The latest version of the jedec_probe code should support these chips.

CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_CFI_INTELEXT=y



--
dwmw2

MTD support for Intel E28F016S3 ?

[Larry Doolittle]

The 28F016S3 is not listed in jedec_probe.c, so it won't work 
"out of the box".  The data sheet for the 28FxxxS3 family says
it's backward compatible with the 28F008SA, and Russell King put
that chip on the JEDEC list, so it should be safe to simply add
the new entries based on the device codes:
   I28F004S3:  0x00a7
   I28F008S3:  0x00a6
   I28F016S3:  0x00aa

 [ The following is a draft of an Intel.README file that I think
   belongs somewhere in the mtd tree.  Would someone please check,
   edit, and commit it. ]

Intel's Flash chips have slightly unusual numbering, they
repeatedly fool people into leaving off the most important
part.  Let's break one down:

   TE28F320B3BA110

TE  - Package
         E, TE - TSOP
         GT, GE, RC - BGA

28F - Product line designator - common to all Intel Flash products

320 - Device Density, with a flag for data bus width.
         004 -  4 Mbit, 8 bit bus     400 -   4 Mbit, 16 bit bus
         008 -  8 Mbit, 8 bit bus     800 -   8 Mbit, 16 bit bus
         016 - 16 Mbit, 8 bit bus     160 -  16 Mbit, 16 bit bus
                                      320 -  32 Mbit, 16 bit bus
                                      640 -  64 Mbit, 16 bit bus
                                      128 - 128 Mbit, 16 bit bus
      (all parts with 16 bit bus hardware can also function in an
      8 bit bus mode; the 8 bit bus parts only have 8 data pins)

B3  - Product Family, one of
         SA - 5 Volt FlashFile (not CFI compliant)
         S3 - 3 Volt FlashFile (not CFI compliant)
         B3 - 3 Volt Advanced Boot Block (not CFI compliant)
         C3 - 3 Volt Advanced+ Boot Block (CFI compliant)
         J5 - 5 Volt StrataFlash (CFI compliant?)
         J3 - 3 Volt StrataFlash (CFI compliant)
***THE PRODUCT FAMILY IS THE CRUCIAL PIECE FOR SOFTWARE SUPPORT***

B   - B3 and C3 product families have a B or T suffix to tell whether
      the small erase blocks are at the Bottom or Top of the address
      space.  Other families don't have a letter here.

A110 - Lithography code and access speed.  An issue for the hardware
       designer, but should not affect the software at all.

Within a Product Family, the parts are software and hardware compatible.
If you leave off the "B3" (or J3, etc.), however, people won't know what
you're talking about, both from a hardware and software perspective.

To see which non-CFI Intel chips are supposed to work with MTD, see
chips/jedec_probe.c.  If you run into an Intel chip not in that table,
you need to add its device identifier to the table, and verify that
it responds to the Intel Standard command set coded in cfi_cmdset_0001.c.

All CFI compliant chips (Intel or otherwise) should be detected by
cfi_probe.c, and work using cfi_cmdset_*.c.

One weird effect showed up using the 28F320B3B on a nanoEngine, where
the CFI detect code "found" the chip, although it is truly not CFI
compliant.  This is apparently a chip bug, and the workaround is to
use the JEDEC probe first, followed by the CFI detect code.  This
order is backwards from the official Intel policy on detection logic.

 [ end readme submission ]

"find drivers/mtd -type f | xargs grep -i 28f" points out several places
where Intel part numbers should be clarified:
  cfi_cmdset_0001.c
  devices/lart.c
  maps/dbox2-flash.c
  maps/elan-104nc.c
  maps/sbc_gxx.c

Hope this helps!

        - Larry

RE: MTD support for Intel E28F016S3 ?

[Kremer, Alex]

| -----Original Message-----
| From: Larry Doolittle [mailto:ldoolitt@recycle.lbl.gov]
| Sent: Mon, October 22, 2001 6:45 PM
| To: linux-mtd@lists.infradead.org
| Subject: MTD support for Intel E28F016S3 ?
| 
| One weird effect showed up using the 28F320B3B on a nanoEngine, where
| the CFI detect code "found" the chip, although it is truly not CFI
| compliant.  This is apparently a chip bug, and the workaround is to
| use the JEDEC probe first, followed by the CFI detect code.  This
| order is backwards from the official Intel policy on detection logic.
| 

This is strange, I have TE28F320B3B mapped over dc21285 and the cfi_probe
first,
jedec_probe after works fine...

Kreso

Re: MTD support for Intel E28F016S3 ?

[Larry Doolittle]

On Tue, Oct 23, 2001 at 10:03:06AM +0200, Kremer, Alex wrote:
> | From: Larry Doolittle [mailto:ldoolitt@recycle.lbl.gov]
> | 
> | One weird effect showed up using the 28F320B3B on a nanoEngine, where
> | the CFI detect code "found" the chip, [ chop ]
> 
> This is strange, I have TE28F320B3B mapped over dc21285 and the cfi_probe
> first, jedec_probe after works fine...

All I know is, I saw the "QRY" probe respond loud and clear from this
chip, but the CFI data structure that the mtd code then picked up was
garbage.  The package is marked
   TE28F320
   B3BA110
   U9360221A
   (U)(C)1998

I got a private e-mail from a Mr. Conley at Intel which said there is
"a problem with some of the B3s that the CFI command comes back with
information that is an invalid C3 information block."  He hoped to
get more information and pass it on.

    - Larry