mtd->erasesize

mtd->erasesize

[Abraham vd Merwe]

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

Hi!

I'm busy writing a driver for the 28Fxxxxx 3V Intel Fast Boot Block flash
devices (for now only a LART driver since I have no other boards to play
with).

The problem is that these chips have 8 4k blocks in the beginning and the
rest is 32k blocks, so effectively there is two erasesize's.

For now, I'm just skipping the first 8 4k blocks so you can't access that
with the MTD driver, but I believe this is a design flaw with the MTD
drivers. It should be able to handle multiple erasesize's for each device.

-- 

Regards
 Abraham

Somebody's terminal is dropping bits.  I found a pile of them over in the
corner.

__________________________________________________________
 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: mtd->erasesize

[David Woodhouse]

abraham@2d3d.co.za said:
>  I'm busy writing a driver for the 28Fxxxxx 3V Intel Fast Boot Block
> flash devices (for now only a LART driver since I have no other boards
> to play with).

You should be able to use the same actual chip driver as the CFI code -
cfi_cmdset_0001.c. You just need a piece of code to do the Intel-specific
probe and set up the appropriate structure for the chip driver to use, much
like the existing code for AMD/JEDEC probes which has been merged into
cfi_probe.c, except that it should actually be a separate probe function (as
should the AMD/JEDEC one).

> The problem is that these chips have 8 4k blocks in the beginning and
> the rest is 32k blocks, so effectively there is two erasesize's.

> For now, I'm just skipping the first 8 4k blocks so you can't access
> that with the MTD driver, but I believe this is a design flaw with the
> MTD drivers. It should be able to handle multiple erasesize's for each
> device. 

The driver for AMD chips (cfi_cmdset_0002.c) already supports this. 
Nobody's yet put similar support into the Intel driver. Feel free to do so 
:)

--
dwmw2

AW: mtd->erasesize

[Florian Schirmer / TayTron]

Hi!

>> For now, I'm just skipping the first 8 4k blocks so you can't access
>> that with the MTD driver, but I believe this is a design flaw with the
>> MTD drivers. It should be able to handle multiple erasesize's for each
>> device.

>The driver for AMD chips (cfi_cmdset_0002.c) already supports this.
>Nobody's yet put similar support into the Intel driver. Feel free to do so
>:)

The intel driver already has support for different erase regions. (Afaik!)
Someone commited it some time ago.


So far,
  Florian Schirmer


---------------------------+--------------------------------------------
TayTron Internet Solutions | Bei Fragen wenden Sie sich bitte an:
                           |
Webhosting     ab  29,- DM | http://www.velomedia.de - info@velomedia.de
Serverhousing  ab 199,- DM | Tel. 0800 / 80 70 900 - Fax 030 / 43671-040

Re: mtd->erasesize

[Nicolas Pitre]

On Mon, 4 Jun 2001, David Woodhouse wrote:

>
> abraham@2d3d.co.za said:
> >  I'm busy writing a driver for the 28Fxxxxx 3V Intel Fast Boot Block
> > flash devices (for now only a LART driver since I have no other boards
> > to play with).
>
> You should be able to use the same actual chip driver as the CFI code -
> cfi_cmdset_0001.c. You just need a piece of code to do the Intel-specific
> probe and set up the appropriate structure for the chip driver to use, much
> like the existing code for AMD/JEDEC probes which has been merged into
> cfi_probe.c, except that it should actually be a separate probe function (as
> should the AMD/JEDEC one).

Actually, I suggested on the LART list that the LART flash driver has its
own driver without trying to twist the LART funny address/data line routing.
A separate driver would eliminate the need for convoluted probing routines
altogether while keeping the overall code cleaner and simpler.


Nicolas