RE: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

RE: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[John Burch]

> > > Also, does the mtd driver for AMD CFI devices handle
> > > AMD's ability to support erasure of multiple sectors 
> simultaneously?
> > 
> > Probably not yet, but there's no reason why it shouldn't. 
> Criticism in 
> > 'diff -u' form is preferred :)
> > 
> 
> Is this chip-feature "probable"? We used to do simutaneous 
> erases in a bootloader, but after a while we started using 
> chips that couldn't do that so we had to change the behaviour 
> to be able to handle all sorts of chips. I'm not sure if CFI 
> covers that particular feature, but it would be great if it 
> did. It wouldn't be so great to have to check JEDEC IDs...
> 

As far as I know, the feature is unique to AMD though I don't know if it
is supported across their entire product line.  Also, it is not a CFI
specific feature.  For example, it's discussed in the 29LV008B (not a
CFI compliant device) data sheet under the "Sector Erase Command
Sequence" section.

Re: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[Jörn Engel]

On Wed, 21 May 2003 09:49:30 -0400, John Burch wrote:
> 
> As far as I know, the feature is unique to AMD though I don't know if it
> is supported across their entire product line.  Also, it is not a CFI
> specific feature.  For example, it's discussed in the 29LV008B (not a
> CFI compliant device) data sheet under the "Sector Erase Command
> Sequence" section.

Is there a way to know if a given chip supports this feature without
checking the chip id against a table?

Jörn

-- 
Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats.
-- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by
   Raph Levien, 1979

RE: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[John Burch]

> 
> On Wed, 21 May 2003 09:49:30 -0400, John Burch wrote:
> > 
> > As far as I know, the feature is unique to AMD though I 
> don't know if 
> > it is supported across their entire product line.  Also, it 
> is not a 
> > CFI specific feature.  For example, it's discussed in the 29LV008B 
> > (not a CFI compliant device) data sheet under the "Sector Erase 
> > Command Sequence" section.
> 
> Is there a way to know if a given chip supports this feature 
> without checking the chip id against a table?
> 

Not that I know of.  I think the best case scenario would be that all
AMD devices supported it - then only the manuf ID would have to be
checked.  However, that would have to be confirmed by AMD.

John

Re: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[Jörn Engel]

On Wed, 21 May 2003 10:36:14 -0400, John Burch wrote:
> > 
> > Is there a way to know if a given chip supports this feature 
> > without checking the chip id against a table?
> 
> Not that I know of.  I think the best case scenario would be that all
> AMD devices supported it - then only the manuf ID would have to be
> checked.  However, that would have to be confirmed by AMD.

Jonas Holmberg:
> Is this chip-feature "probable"? We used to do simutaneous erases in a
> bootloader, but after a while we started using chips that couldn't do
> that so we had to change the behaviour to be able to handle all sorts
> of chips. I'm not sure if CFI covers that particular feature, but it
> would be great if it did. It wouldn't be so great to have to check
> JEDEC IDs...

If I read this correctly, AMD won't confirm your assumption.

Might be another option to assume simultaneous erases work, try it,
catch the failure gracefully and turn that feature off from that point
on. Does anyone have the time and hardware to answer this question?

Jörn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra

RE: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[John Burch]

> > 
> > Not that I know of.  I think the best case scenario would 
> be that all 
> > AMD devices supported it - then only the manuf ID would have to be 
> > checked.  However, that would have to be confirmed by AMD.
> 
> 
> If I read this correctly, AMD won't confirm your assumption.
> 

AMD has confirmed that all of their flash devices support the multiple
sector erase capability as described in their datasheets under "Sector
Erase Command Sequence".  Note that it requires that any additional
erase commands be written within 50us of the previous erase command.

Re: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[jonas.holmberg]

> > Is this chip-feature "probable"? We used to do simutaneous 
> > erases in a bootloader, but after a while we started using 
> > chips that couldn't do that so we had to change the behaviour 
> > to be able to handle all sorts of chips. I'm not sure if CFI 
> > covers that particular feature, but it would be great if it 
> > did. It wouldn't be so great to have to check JEDEC IDs...
> > 
> 
> As far as I know, the feature is unique to AMD though I don't know if it
> is supported across their entire product line.  Also, it is not a CFI
> specific feature.  For example, it's discussed in the 29LV008B (not a
> CFI compliant device) data sheet under the "Sector Erase Command
> Sequence" section.

If it is AMD specific someone ought to do some performance tests
before working on a patch, because when we changed method
from simultaneous erase to erasing one block at a time it wasn't
slower (or at least not much slower iirc) erasing an entire 16Mbit
AMD device.

/Jonas (hoping that changing email-client will allow me to sneak
past Davids naughty header-checking filters).

Re: Mtd block access (jffs2 formatted) and mtd char access (unformatted) on different partitions of a single flash device

[David Woodhouse]

On Wed, 2003-05-21 at 10:05, Jörn Engel wrote:
> > I've adopted a system that uses a driver with its own flash support to
> > read/write raw (non-jffs2) portions of the flash, while application code
> > uses standard file I/O to read/write jffs2 partitions on the same
> > device.
> 
> What does "driver" mean? If you have two in-kernel drivers for the
> same flash chip, they will use different locks and things will break.
> If that is a user-space driver, using the /dev/mtdX devices, you are
> perfectly safe. Which one is it?

Hmmm. What he actually said was 'driver with its own flash support',
which sounds bad. As long as everything accessing the flash goes through
the MTD driver for the flash, using its read/write/erase functions
rather than banging on the hardware directly, it'll be fine. If your raw
driver is actually dealing with the flash driver directly, that's
broken.

-- 
dwmw2

RE: Mtd block access (jffs2 formatted) and mtd char access(unformatted) on different partitions of a single flashdevice

[John Burch]

> > 
> > What does "driver" mean? If you have two in-kernel drivers for the 
> > same flash chip, they will use different locks and things 
> will break. 
> > If that is a user-space driver, using the /dev/mtdX 
> devices, you are 
> > perfectly safe. Which one is it?
> 
> Hmmm. What he actually said was 'driver with its own flash 
> support', which sounds bad. As long as everything accessing 
> the flash goes through the MTD driver for the flash, using 
> its read/write/erase functions rather than banging on the 

When accessing "raw" flash via the char driver, how can I initiate a
sector erase?  Also, does the mtd driver for AMD CFI devices handle
AMD's ability to support erasure of multiple sectors simultaneously?

> hardware directly, it'll be fine. If your raw driver is 
> actually dealing with the flash driver directly, that's broken.
> 

David has it right.  The raw "in-kernel" driver deals with flash
directly on its own, not through mtd.