[Yaffs] bit error rates --> a vendor speaks

Josh Boyer jwboyer at gmail.com
Mon Feb 27 11:15:07 EST 2006

On 2/27/06, Artem B. Bityutskiy <dedekind at yandex.ru> wrote:
> Josh Boyer wrote:
> > Often times the eraseregions have no practical use for the software
> > involved.  Take the Intel P30 for example.  It has a few eraseblocks
> > at either the top or bottom of the chip that are different eraseblock
> > size.
> This explains why putting this all together in one mtd-> structure is
> bad  (they have different eraseblocks size).

The chip driver abstracts that away.  The users of the device
typically don't _know_ there are different eraseregions.

> > If you have different eraseregions show up as different MTD devices
> > (or partitions which are essentially the same thing in this
> > discussion),
> Err, actually partitions are better, because they are handeled by the
> same flash driver.

I meant that for all intents and purposes, partitions show up as
completely different MTD devices.  They aren't traditional partitions
as on a hard drive.  It's unrelated to this topic, so ignore that.

> > then you have to manually concatenate them back into a
> > single device.
> What for do you need to concatenate them back? Different erase regions
> are used for completely different purposes, right? So if you work with
> the small "boot" region, you don't normally need the rest of the flash
> and vice versa.

Different erase regions _can_ be used for completely different
purposes.  Often, they aren't used at all.  Which means that if the
show up as a separate device, you have to concatenate them back

> My point is that there should be a generalized flash model like this:
> 1. there are only 3 operations: read, write, erase;
> 2. erase is done in terms of eraseblocks, eraseblocks are all equivalent
> in size;
> 4. there is a minimal input/output unit exists;
> That's all. Erase regions and OOB is out of this simple flash model, do
> you see what I mean? Add your erase regions to this model and you'll end
> up with a mess. Organize these regions as different instances of the
> above generalized model, and you have a very nice picture.

A very nice picture that complicates things for end users and wastes
DRAM when there is no intention to use the eraseregions differently.

I can buy the OOB argument.  I think we'll have to agree to disagree
on the eraseregion stuff.


More information about the linux-mtd mailing list