From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4661 invoked by alias); 7 Oct 2009 12:11:13 -0000 Received: (qmail 4649 invoked by uid 22791); 7 Oct 2009 12:11:12 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr1.xs4all.nl (HELO smtp-vbr1.xs4all.nl) (194.109.24.21) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Oct 2009 12:11:07 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id n97CAmAQ020336; Wed, 7 Oct 2009 14:10:49 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4ACC8640.6080605@cs.vu.nl> Date: Wed, 07 Oct 2009 12:11:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ross Younger CC: Jonathan Larmour , eCos developers Subject: Re: NAND technical review References: <4AC6218C.20407@jifvik.org> <4ACB4B58.2040804@ecoscentric.com> In-Reply-To: <4ACB4B58.2040804@ecoscentric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00004.txt.bz2 Ross Younger wrote: [snip] > Getting data into and out of the chip involves a simple protocol sequence. > > Commands are single bytes; addresses are sequences of a few bytes depending > on the chip size and the operation invoked. > > For example, to read a page of data on the spec sheet I have to hand is: > * Write 0x00 into the command latch > * Write the four address bytes in turn into the address latch > * Write 0x30 into the command latch > * Chip signals Busy; wait for it to signal Ready > * Read out (up to) 2112 bytes of data. AFAIK, there are two kinds of chips on the market: Large-page chips (2K data pages) and Small-page chips (512B pages). These speak a different command language, but in their wiring they are the same. The large-page chips are (nearly) ONFI-compliant, the Small-page chip command language is different. Ancient chips aside, if a chip gives its Device Type Byte, NAND flash code can look up in its tables what the chip parameters are (page size, block size, number of blocks, 8 or 16 bit data bus, etc). Miracle: Device Type Bytes are shared across manufacturers, so the table is limited in size. I saw an annoucement of 4K-page chips, but the datasheets are confidential. Is there anybody who can comment on these? > However, not all chips are quite the same. The ONFI initiative is an attempt > to standardise chip protocols and most new chips should comply with it. A > number of chips on the market are _nearly_ ONFI-compliant: deviations > typically occur over the format of the ReadID response and that of an > address. I believe that older chips did their own thing entirely. [snip] > 3. Driver model -------------------------------------------------------- > > The major architectural difference between the two NAND layers is in their > driver models and the degree of abstraction enforced. > > In Rutger's layer, controllers and chips are both formally abstracted. The > application talks to the Abstract NAND Chip, which has (hard-coded) the > basic sequences of commands, addresses and data required to talk to a NAND > chip. This layer talks to a controller driver, which provides the nuts and > bolts of reading and writing to the device. The chip driver is also called > by the ANC layer, and provides the really chip-specific parts. > > The call flow looks something like this (best viewed in fixed-width font): > > Application --(H)-> ANC --(L)-> Controller driver > \ > \-(C)-> Chip driver The code attempts at both flexibility and code reuse. Its structure is as follows: Application --(H)-> ANC --(H2)-> Controller Common --(L)-> Controller device-specific --(L)-> Chip = ANC just wants to hide the presence of multiple controllers and multiple chips, in any degree of heterogeneity. = Controller Common implements the command languages for Large-page chips and Small-page chips, does ECC generation/checking/repair. Its API is much like the ANC's API: page_read, page_write, block_erase, but on a specific controller+chip. = Controller device-specific is (usually) the only part that must be ported for a new controller/board/setup. Its API is in terms of the commands described by Ross: push a command on the chip's bus, push/read data on the chip's bus etc. The sample GPIO driver that I bundled shows how little work can be involved in doing a port. I think that support for hardware ECC of some controllers may add more to the device-specific code than the command implementation! = Chip has support for ONFI, Large-page, and Small page. Only for chips that don't fit in these categories (and there will be museums that have them) require writing a chip driver. I realize that support for various chip and ECC types increases the code. It will be trivial to add a few #ifdef's to disable unneeded code for your configuration; the .cdl can specify what is needed (like: only large-page 'regular' chips, which means: no small-page, no ONFI interrogation). [snip] > - E's high-level driver interface makes it harder to add new functions > later, necessitating a change to that API (H2 above). R's does not; the > requisite logic would only need to be added to the ANC. 'ANC' should read: Controller Common code. > ... (As a case in point, support > for hardware ECC is currently work-in-progress within eCosCentric, and does > require such a change, but now is not the right time to discuss that.) Use of the hardware ECC support for R's BlackFin's on-board ECC was included in R from the start. The interface between Common Controller and device-specific controller code is designed to support this flexibly. > It would perhaps be interesting to compare the complexities of drivers for > the two models, but it's not readily apparent how we would do that fairly. > > Perhaps porting a driver from one NAND layer to the other would be a useful > exercise, and would also allow us to compare code sizes. Any suggestions or > (he says hopefully) volunteers? I've got a lot on my plate this month... Yes, this would definitely be interesting. Would there be benefits in R's attempts at ease-of-port and code reuse. > (b) Availability of drivers > > R provides support for: > - One board: BlackFin EZ-Kit BF548 (which is not in anoncvs?) > - One chip: the ST Micro 0xG chip (large page, x8 and x16 present but > presumably only tested on the x8 chip on the BlackFin board?) Correction: any 'regular' chip, of which the ST Micro is an example. I tested on my synth target with x8 and x16 chips, also different ones in one 'board'. I tested with various page sizes, also different ones on one 'board'. > - A synthetic controller/chip package > - A template for a GPIO-based controller (untested, intended as an example only) > > I seem to remember rumours of the existence of a driver for a further > chip+board combination, but I haven't seen it. See Jurgen Lambrecht's response. [snip] > 5. Works in progress ----------------------------------------------------- > > I can of course only comment on eCosCentric's plans, but the following work > is in the pipeline: > > * Expansion of the device interface to better allow efficient hardware ECC > support (in progress) > * Hardware ECC for the STM3210E board driver > * Performance tuning of software ECC and of NAND low-level drivers > * Partition addressing: make addressing relative to the start of the > partition, once and for all > * Simple raw NAND "filesystem" for use by RedBoot (see > http://ecos.sourceware.org/ml/ecos-devel/2009-07/msg00004.html et seq; those > are the latest public mails but not the latest version of my thinking, which > I will update in due course) > * More RedBoot NAND utility commands > * Support for booting Linux off NAND and for sharing a (YAFFS) NAND-resident > filesystem > * Part-page read support (would provide a big speed-up to parts of YAFFS2 > inbandTags mode as needed by small-page devices like that on the STM3210E) R is designed with support for hardware ECC in mind. R has part-read and part-write support. One thing that has always puzzled me is how this interacts with ECC. ECC often works on a complete subpage, like 256 bytes on a 2KB page chip; then I understand. But what if the read/write is not of such a subpage? Rutger