public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Josh Boyer <jwboyer@gmail.com>
Cc: tglx@linutronix.de, linux-mtd@lists.infradead.org
Subject: Re: [Yaffs] bit error rates --> a vendor speaks
Date: Mon, 27 Feb 2006 19:01:42 +0300	[thread overview]
Message-ID: <44032266.1040501@yandex.ru> (raw)
In-Reply-To: <625fc13d0602270527k39b18cabv5762c008bb1e2b73@mail.gmail.com>

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

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

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

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.

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

  reply	other threads:[~2006-02-27 16:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <43EB96DC.3030900@eptar.com>
     [not found] ` <35fb2e590602100558s2d868fa3o1752fbf3217439e4@mail.gmail.com>
     [not found]   ` <d97046180602151153g23064424x9e1ddf83a1d7ae4f@mail.gmail.com>
2006-02-16  1:32     ` [Yaffs] bit error rates --> a vendor speaks Charles Manning
2006-02-18  9:10       ` Thomas Gleixner
2006-02-18 16:31         ` Vitaly Wool
2006-02-19  8:22           ` Thomas Gleixner
2006-02-20 20:42             ` Charles Manning
2006-02-20 21:37               ` Thomas Gleixner
2006-02-20 22:40                 ` Charles Manning
2006-02-20 23:18                   ` Thomas Gleixner
2006-02-21  0:29                     ` Jon Masters
2006-02-21  8:26                       ` Thomas Gleixner
2006-02-21  9:35                         ` Jörn Engel
2006-02-21  1:08                     ` [Yaffs] bit error rates --> YAFFS for devices with no OOB Charles Manning
2006-02-21  2:12                       ` Jon Masters
2006-02-22  0:38                       ` Jamie Lokier
2006-02-21 12:14                   ` [Yaffs] bit error rates --> a vendor speaks Artem B. Bityutskiy
2006-02-21 13:50                     ` Josh Boyer
2006-02-21 14:36                       ` Artem B. Bityutskiy
2006-02-21 14:49                         ` Artem B. Bityutskiy
2006-02-21 11:59                 ` Artem B. Bityutskiy
2006-02-21 12:06                   ` Thomas Gleixner
2006-02-25 11:58                     ` Artem B. Bityutskiy
2006-02-27 13:27                       ` Josh Boyer
2006-02-27 16:01                         ` Artem B. Bityutskiy [this message]
2006-02-27 16:15                           ` Josh Boyer
2006-02-27 17:21                             ` Artem B. Bityutskiy
2006-02-27 17:40                               ` Josh Boyer
2006-02-18 18:11         ` Russ Dill
2006-02-19  0:29           ` Charles Manning
2006-02-19  5:08             ` Jon Masters
2006-02-19  8:29           ` Thomas Gleixner
2006-02-23  0:46             ` Russ Dill
2006-02-23  7:36               ` Thomas Gleixner
2006-02-23  8:31       ` Vitaly Wool
2006-02-24  9:51         ` Artem B. Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44032266.1040501@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=jwboyer@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox