From: Rutger Hofman <rutger@cs.vu.nl>
To: Jonathan Larmour <jifl@jifvik.org>
Cc: Ross Younger <wry@ecoscentric.com>,
eCos developers <ecos-devel@ecos.sourceware.org>
Subject: Re: NAND technical review
Date: Wed, 21 Oct 2009 12:15:00 -0000 [thread overview]
Message-ID: <4ADEFCFE.9060603@cs.vu.nl> (raw)
In-Reply-To: <4ADE679D.1050900@jifvik.org>
Jonathan Larmour wrote:
> Rutger Hofman wrote:
>> Jonathan Larmour wrote:
[How would different hardware, like OneNAND, fit into R's model?]
>>> Would that not require a significant reworking and relayering of
>>> code? It seems to me that controller drivers and the chip drivers
>>> used by controller drivers under this system will still want to be
>>> able to access the infrastructure support for BBTs, ECCs and spare
>>> layout. From what I can see, preserving that without large amounts of
>>> indirection (imposing further performance and size hits) would pose
>>> quite some challenge. The result would be something really quite
>>> different to what R is like today.
>>
>> The reworking would just be to replace the calls in the ANC of the
>> controller-common API with indirect calls, and supporting this
>> configurability in the CDL. OneNAND doesn't need ECC code because
>> things are handled in hardware (the datasheet recommends not even
>> checking the ECC status register for 2-bit failures because they are
>> so rare).
>
> As I mentioned when I brought up OneNAND, my concern was really more
> general: that the layer is at present only intended for a particular
> access model. OneNAND is only a current example of where this assumption
> breaks, there may be more in the future (or now).
>
>> Maybe BBT is necessary too for OneNAND; I didn't think that through yet,
>
> I would have thought so personally.
>
>> but I would hope the BBT implementation would support different
>> controllers without a lot of reworking - right now, accessing the chip
>> already goes through controller calls. The indirections would be few:
>> one for each top-level API call (unless the ANC must redistribute
>> application pages to chip pages, which is only in case of
>> heterogeneous chips).
>
> It's not just indirecting the functions, but checking what may need
> changing for anything which accesses the controller data, e.g. the
> contents of struct CYG_NAND_CTL.
OK, to answer this question, the level of detail will go up considerably.
Lots of CYG_NAND_CTL is pointers to higher layers (anc) and lower layers
(funs, priv, chip stuff). These would remain, although the function
dispatch table would be reused (or unused, I don't know about OneNAND
varieties). The ECC fields would remain too (if applicable, but nowadays
that is a CDL option) and likewise mutex. I would guess that any state
for the different class of controller/chip could be incorporated into priv.
So, (surprisingly to me because I didn't consider anything else than raw
NAND), CYG_NAND_CTL seems generic enough to incorporate other types of
NAND chip. I'd say the controller-common API must stay -- if it doesn't,
I would be doubtful to fit it into a NAND harness. Reminder to self: ANC
must call the controller over a function dispatcher.
CYG_NAND_CHIP would need to be split into a generic part that has page
size, block size, num blocks, and type-specific stuff like timing and
like the bucket-full of ONFI parameters.
Required code refactoring: a number of functions must just be lifted out
for common usage. For spare layout, my guess is that just the
scatter/gather functions from controller-common would be shared (small
though they are). If ECC is desired: the configurable part of it is
already separate; some more (cyg_nand_ctl_ecc_repair, debug stuff) can
be usefully factored out. One more thing that should be common is the
verification step; it had best move one level up, to ANC.
I think the rest of controller-common is tied to raw NAND, and would
have no place in a driver for non-raw NAND hardware.
> It's not clear how the stuff in src/chip/ would map onto a different
> controller model.
The interrogation parts would not fit at all, they would have no place
in a driver for different hardware. Interrogation is the majority of the
code. Common code would be BBT and bad-block queries.
If this all is going to happen, the code would be partitioned like:
top-level = anc (with verify and function dispatch)
controller = shared (ECC, spare), raw NAND, OneNAND, ...
chip = shared (BBT, bad-block query), raw NAND, OneNAND, ...
... and unmodified device-specific controller, platform stuff, ...
The CDL would piece together the desired components, like you suggested.
I think that both the public API and the interface to device-specific
drivers will remain intact, so clients won't really notice (except
possiby in their CDL).
I guess that this refactoring will take something like one or a few
days' work, including having ANC call the controller over a dispatch
table. I'll be glad to do it (ETA: somewhere in the next 1 to 1.5 months).
Personal note: I am glad with this kind of detailed feedback. Still, I
would have preferred to get it when I put up the NAND design for
discussion, about a year ago.
Rutger
next prev parent reply other threads:[~2009-10-21 12:15 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 [this message]
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
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=4ADEFCFE.9060603@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).