non cfi flash memory

non cfi flash memory

[Xavier DEBREUIL]

Sorry about those beginner questions...

Correct wrong statements :
In fact, as the intel flash 28F160x3 is not cfi, it is useless to use
do_map_probe("cfi") or something else as I tried to.
What should be written is the equivalent of amd_flash.c for the flash
family which include TE28Fxxxx3 from INTEL, M28Wxxx from ST and so on.
A good starting point is lart.c written by Abraham and amd_flash.c.

Xavier

Re: non cfi flash memory

[David Woodhouse]

xde@inventel.fr said:
> In fact, as the intel flash 28F160x3 is not cfi, it is useless to use
> do_map_probe("cfi") or something else as I tried to. What should be
> written is the equivalent of amd_flash.c for the flash family which
> include TE28Fxxxx3 from INTEL, M28Wxxx from ST and so on.

No. You don't need to write a whole driver for it. The existing
cfi_cmdset_0001 code can driver the chips just fine. All you need to do is
write a _probe_ routine which can pass control to the existing code, just
like the cfi_probe does.

There's already a hack in the cfi_probe code to find some non-CFI 
AMD-compatible chips and use the cfi_cmdset_0002 back end. You want 
something similar - but _don't_ add further hacks to the cfi_probe code, 
make it an entirely new probe routine like the AMD one should probably 
have been.

--
dwmw2

Re: non cfi flash memory

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Hi David!

> No. You don't need to write a whole driver for it. The existing
> cfi_cmdset_0001 code can driver the chips just fine. All you need to do is
> write a _probe_ routine which can pass control to the existing code, just
> like the cfi_probe does.
> 
> There's already a hack in the cfi_probe code to find some non-CFI 
> AMD-compatible chips and use the cfi_cmdset_0002 back end. You want 
> something similar - but _don't_ add further hacks to the cfi_probe code, 
> make it an entirely new probe routine like the AMD one should probably 
> have been.

I really think those cfi_cmdset_*.c chip driver modules should be renamed to
something else. It's really confusing since they're not only for CFI chips.

-- 

Regards
 Abraham

The study of non-linear physics is like the study of non-elephant biology.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: non cfi flash memory

[David Woodhouse]

abraham@2d3d.co.za said:
>  I really think those cfi_cmdset_*.c chip driver modules should be
> renamed to something else. It's really confusing since they're not
> only for CFI chips.

I agree. 

--
dwmw2

Re: non cfi flash memory

[Xavier DEBREUIL]

David Woodhouse a écrit :
> 
> abraham@2d3d.co.za said:
> >  I really think those cfi_cmdset_*.c chip driver modules should be
> > renamed to something else. It's really confusing since they're not
> > only for CFI chips.
> 
> I agree.
> 

I have 320C3 versions which seem to have cfi properties.
This is a debugged output from initialisation :

cfi_qry_mode, cfi->cfi_mode : 0x0
clep7211: Found 2 x16 devices at 0x0 in 32-bit mode
Number of erase regions: 2
  Erase Region #0: BlockSize 0x10000 bytes, 63 blocks
  Erase Region #1: BlockSize 0x2000 bytes, 8 blocks
Primary Vendor Command Set: 0003 (Intel/Sharp Standard)
Primary Algorithm Table at 0035
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
Vpp Minimum: b.4 V
Vpp Maximum: c.6 V
Typical byte/word write timeout: 32 µs
Maximum byte/word write timeout: 512 µs
Full buffer write not supported
Typical block erase timeout: 1024 µs
Maximum block erase timeout: 8192 µs
Chip erase not supported
Device size: 0x400000 bytes (4 MiB)
Flash Device Interface description: 0x0001
  - x16-only asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 2
check_cmd_set, type : 0x3
cfi_qry_mode, cfi->cfi_mode : 0x0
 Intel/Sharp Extended Query Table at 0x0035
  Feature/Command Support: 0066
     - Chip Erase:         unsupported
     - Suspend Erase:      supported
     - Suspend Program:    supported
     - Legacy Lock/Unlock: unsupported
     - Queued Erase:       unsupported
     - Instant block lock: supported
     - Protection Bits:    supported
     - Page-mode read:     unsupported
     - Synchronous read:   unsupported
  Supported functions after Suspend: 01
     - Program after Erase Suspend: supported
  Block Status Register Mask: 0003
     - Lock Bit Active:      yes
     - Valid Bit Active:     yes
  Vcc Logic Supply Optimum Program/Erase Voltage: 0.7 V
  Vpp Programming Supply Optimum Program/Erase Voltage: 0.0 V
JEDEC ID: 89 C4
number of CFI chips: 1
0: offset=0x0,size=0x20000,blocks=63
1: offset=0x7e0000,size=0x4000,blocks=8
Creating 2 MTD partitions on "clep7211":
0x00000000-0x00100000 : "boot partition"
mtd: Giving out device 0 to boot partition
0x00100000-0x00400000 : "cramfs partition"
mtd: Giving out device 1 to cramfs partition
clep7211 flash access initialized


Is the number of CFI chips: 1 correct since I have two x16 flash in
parallel to have a 32 bit bus ?
And when I try to eraseall /dev/mtd0, I have the following problem :
/dev # eraseall /dev/mtd0
MTD_open
MTD_ioctl
Erasing 128 KibMTD_ioctl
yte @ 0 --  0 % complete.
eraseall: /dev/mMTD_ioctl
td0: MTD Erase failure: Read-only file system
Erasing 128 Kibyte @ 20000 -- 12 % complete.
eraseall: /dev/mMTD_ioctl
td0: MTD Erase failure: Read-only file system
Erasing 128 Kibyte @ 40000 -- 25 %
complete.                                                                                                  
...

(777 for /dev/mtd0 access)

Xavier