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

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

[John Burch]

Is there a preferred way to access different mtd partitions of a single
flash device when certain accesses will be (1) block oriented via
standard file I/O of a jffs2 file system mounted on a /dev/mtdblockN
device and other accesses will be (2) character oriented via 'dd' (or
some other mechanism?) of unformatted/raw flash using /dev/mtdN?  Are
there any possibly bad interactions between mtd char and block device
access to the same device?

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.  I'm concerned that these accesses may clash and possibly result
in corrupted flash, crashed kernel, etc.  Is this a legitimate concern
or does the mtd driver check flash status prior to any operations?


Thanks,
John

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

[Charles Manning]

On Wednesday 21 May 2003 08:53, John Burch wrote:
> Is there a preferred way to access different mtd partitions of a single
> flash device when certain accesses will be (1) block oriented via
> standard file I/O of a jffs2 file system mounted on a /dev/mtdblockN
> device and other accesses will be (2) character oriented via 'dd' (or
> some other mechanism?) of unformatted/raw flash using /dev/mtdN?  Are
> there any possibly bad interactions between mtd char and block device
> access to the same device?

This should not be a problem.
>
> 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.  I'm concerned that these accesses may clash and possibly result
> in corrupted flash, crashed kernel, etc.  Is this a legitimate concern
> or does the mtd driver check flash status prior to any operations?

It is mtd's job to handle this sort of thing.

-- CHarles

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

[Jörn Engel]

On Tue, 20 May 2003 16:53:30 -0400, John Burch wrote:
> 
> Is there a preferred way to access different mtd partitions of a single
> flash device when certain accesses will be (1) block oriented via
> standard file I/O of a jffs2 file system mounted on a /dev/mtdblockN
> device and other accesses will be (2) character oriented via 'dd' (or
> some other mechanism?) of unformatted/raw flash using /dev/mtdN?  Are
> there any possibly bad interactions between mtd char and block device
> access to the same device?

Usually not. It would be a bug.

> 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.  I'm concerned that these accesses may clash and possibly result
> in corrupted flash, crashed kernel, etc.  Is this a legitimate concern
> or does the mtd driver check flash status prior to any operations?

The physical flash device can only have one driver accessing it at any
time. The low level chip drivers have locking for this, so you should
be safe.

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?

Jörn

-- 
Courage is not the absence of fear, but rather the judgement that
something else is more important than fear.
-- Ambrose Redmoon

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.

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 13:33, John Burch wrote:
> When accessing "raw" flash via the char driver, how can I initiate a
> sector erase?  
See how it's done in util/erase.c: ioctl(...MEMERASE...)

> 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 :)

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

Then you lose :) If you have sane code which handles multiple concurrent
erases, we'd be happy to merge it so that you can use the mtd driver
without losing out on that feature ;)

-- 
dwmw2

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).