From: Rutger Hofman <rutger@cs.vu.nl>
To: Jonathan Larmour <jifl@jifvik.org>
Cc: Ross Younger <wry@ecoscentric.com>, ecos-devel@ecos.sourceware.org
Subject: Re: NAND technical review
Date: Tue, 13 Oct 2009 13:35:00 -0000 [thread overview]
Message-ID: <4AD48367.8050807@cs.vu.nl> (raw)
In-Reply-To: <4AD3E412.80002@jifvik.org>
Jonathan Larmour wrote:
> Hmm, I guess the key thing here is that in E's implementation most of
> the complexity has been pushed into the lower layers; at least compared
> to R's. R's has a more consistent interface through the layers. Albeit
> at the expense of some rigidity and noticeable function overhead.
>
> It's not likely E's will be able to easily share controller code, given
> of course you don't know what chips, and so what chip driver APIs
> they'll be connected to. But OTOH, maybe this isn't a big deal since a
> lot of the controller-specific munging is likely to be platform-specific
> anyway due to characteristics of the attached NAND (e.g. timings etc.)
> and the only bits that would be sensibly shared would potentially happen
> in the processor HAL anyway at startup time. What's left may not be that
> much and isn't a problem in the platform HAL. However the likely
> exception to that is hardware-assisted ECC. A semi-formal API for that
> would be desirable.
This is the largest difference in design philosophy between E and R. Is
it OK if I expand?
NAND chips are all identical in their wire setup. They all have a data
'bus', and control lines to indicate whether what is on the bus is a
command, an address, or data.
NAND chips differ in how their command language works, but only so far.
What is on the market now is 'regular' large-page chips that all speak
the same command language, and small-page chips that have a somewhat
different command language. ONFI chips are large-page chips except in
interrogation at startup and in bad-block marking.
E.g. a page read for a large-page chip (my running example) looks like this:
. write a command 0x00 (READ_START)
. write address bytes of the page(+offset) to be read
. write a command 0x30 (READ_CONFIRM)
. read the data on the bus
. insofar as supported retrieve hw-calculated ECC
For small-page chips the sequence is different because a page's data is
read in multiple chunks, using READ_1_A (0x00), READ_1_B (0x01), and for
spare area READ_2 (0x05).
These 2 languages are all the variation there is for NAND chips (plus,
at another level, 2 timing values for read cycle and write cycle)! The
wide-ranging differences for devices for NAND are in the controllers.
How controllers work, is that they accept input like 'write a command of
value 0x..', 'write an address of value 0x.....', etc, and do their job
on the NAND chip's wires. They cannot really operate at a higher level,
if only because they must support both small-page and large-page chips
(and ONFI), and this is the level of common protocol for the chips.
So controller code has to bridge between API calls like page_read and
the interface of the controller as described above. R's implementation
presumes that a lot of the code to make this translation is generic: a
large-page read translates to the controller steps as given above in the
running example, in any controller implementation. Moreover, the generic
code handles spare layout: where in the spare is the application's spare
data folded, where is the ECC, where is the bad-block mark. OTOH, the
generic code has hooks for handling any ECC that the controller has
computed in hardware -- how ECC is supported in hardware varies across
controllers. But the way the ECC check is handled (case in point is
where a correctible bit error is flagged) is generic again.
So, lots of code can (and will) be shared across controller
implementations -- whether by code sharing or by code duplication.
Rutger
next prev parent reply other threads:[~2009-10-13 13:35 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 15:51 Jonathan Larmour
2009-10-06 13:51 ` Ross Younger
2009-10-07 3:12 ` Jonathan Larmour
2009-10-07 16:22 ` Rutger Hofman
2009-10-08 7:15 ` Jürgen Lambrecht
2009-10-15 3:53 ` Jonathan Larmour
2009-10-15 11:54 ` Jürgen Lambrecht
2009-10-15 3:49 ` Jonathan Larmour
2009-10-15 14:36 ` Rutger Hofman
2009-10-16 1:32 ` Jonathan Larmour
2009-10-19 9:56 ` Ross Younger
2009-10-19 14:21 ` Rutger Hofman
2009-10-20 3:21 ` Jonathan Larmour
2009-10-20 12:19 ` Rutger Hofman
2009-10-21 1:45 ` Jonathan Larmour
2009-10-21 12:15 ` Rutger Hofman
2009-10-23 14:06 ` Jonathan Larmour
2009-10-23 15:25 ` Rutger Hofman
2009-10-23 18:03 ` Rutger Hofman
2009-10-27 20:02 ` Rutger Hofman
2009-11-10 7:03 ` Jonathan Larmour
2010-12-11 19:18 ` John Dallaway
2010-12-22 14:54 ` Rutger Hofman
2009-10-15 15:43 ` Rutger Hofman
[not found] ` <4ACDF868.7050706@ecoscentric.com>
2009-10-09 8:27 ` Ross Younger
2009-10-13 2:21 ` Jonathan Larmour
2009-10-13 13:35 ` Rutger Hofman [this message]
2009-10-16 4:04 ` Jonathan Larmour
2009-10-19 14:51 ` Rutger Hofman
2009-10-20 4:28 ` Jonathan Larmour
2009-10-07 9:40 ` Jürgen Lambrecht
2009-10-07 16:27 ` Rutger Hofman
2009-10-13 2:44 ` Jonathan Larmour
2009-10-13 6:35 ` Jürgen Lambrecht
2009-10-15 3:55 ` Jonathan Larmour
2009-10-13 12:59 ` Rutger Hofman
2009-10-15 4:41 ` Jonathan Larmour
2009-10-15 14:55 ` Rutger Hofman
2009-10-16 1:45 ` Jonathan Larmour
2009-10-19 10:53 ` Ross Younger
2009-10-20 1:40 ` Jonathan Larmour
2009-10-20 10:17 ` Ross Younger
2009-10-21 2:06 ` Jonathan Larmour
2009-10-22 10:05 ` Ross Younger
2009-11-10 5:15 ` Jonathan Larmour
2009-11-10 10:38 ` Ross Younger
2009-11-10 11:28 ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2009-11-10 12:16 ` Chris Holgate
2009-11-12 18:32 ` NAND technical review Ross Younger
2009-10-13 14:19 ` Rutger Hofman
2009-10-13 19:58 ` Lambrecht Jürgen
2009-10-07 12:11 ` Rutger Hofman
2009-10-08 12:31 ` Ross Younger
2009-10-08 8:16 ` Jürgen Lambrecht
2009-10-12 1:13 ` Jonathan Larmour
2009-10-16 7:29 ` Simon Kallweit
2009-10-16 13:53 ` Jonathan Larmour
2009-10-19 15:02 ` Rutger Hofman
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=4AD48367.8050807@cs.vu.nl \
--to=rutger@cs.vu.nl \
--cc=ecos-devel@ecos.sourceware.org \
--cc=jifl@jifvik.org \
--cc=wry@ecoscentric.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).