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

[Josh Boyer]

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

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

josh