[Yaffs] bit error rates --> a vendor speaks
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