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

Artem B. Bityutskiy
2006-02-27T17:22:34Z

Josh, I believe you're only *partially* right

Please, switch to "architecture mode", leave this "low-level programmer"
mode. Forget about few bytes of DRAM for now, please! :-)

The bellow are different points which should help me to change your mind.

1. The region is an attribute of *flash chip*. The region is *not* an
attribute of MTD device. MTD device may describe the whole flash chip,
it may describe a part of flash chip (partitions), and it may describe
many flash chips (concatenation).

So, I state: the notion of region has nothing to do with the notion of
MTD device.

If you have a specific application, which works with a *flash chip* not
an *MTD device*, please, introduce another software object, sort of
"struct flash_chip". Let your applications to work with these "struct
flash_chip" objects.

Putting references to regions to the MTD device structure (struct
mtd_info) is *bad*.

2. Well, you're in ecstasy of the current approach (kidding :-) ). Then
explain me, why if, let's say JFFS3, opens an MTD device, it has access
to some weird "regions"? What's on earth is going on? This is definitely
error-prone. This is messy. This is bad design. JFFS3 does not want to
see regions.

3. Regions... How do you look at them?

We could look at them like this:
a). They are different entities, used for completely different purposes,
a rare program needs to use all of them simultaneously, they may have
different eraseblock size and other properties, they are just different.
Yes, it happened to be that they are on one single chip, but they are
still different.

Or we could look at them narrower:
b). A region is a kind of "appendix" to the flash chip, where the
bootcode or whatever may be put. There is not more then one (or really
few) regions per flash chip. There is only one big and main "data"
region, and one or few small auxiliary regions.

I reckon that the reality is more like b). And in this respect I see
your point. Indeed, what for should we spend more DRAM to describe this
unworthy "appendix" (aka region) by a distinct software object? Let's
push this all together!

I can agree with you *partially*, providing that chips like a). are
*not* going to appear. Partially means that I only agree that there *may
be* no reason to create a distinct MTD device for this poor appendix.

So I state: Ok, in b)-like chips, do not create a distinct MTD device.
Let's invent something different. But this must not be in struct
mtd_info anyway.

Do you see my points?

--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.