From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8596 invoked by alias); 23 Oct 2009 14:06:39 -0000 Received: (qmail 8473 invoked by uid 22791); 23 Oct 2009 14:06:37 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Oct 2009 14:06:33 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id n9NE6U408826; Fri, 23 Oct 2009 15:06:30 +0100 (BST) Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 50F3F3FF4; Fri, 23 Oct 2009 15:06:29 +0100 (BST) Message-ID: <4AE1B864.1040409@jifvik.org> Date: Fri, 23 Oct 2009 14:06:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: Rutger Hofman Cc: Ross Younger , eCos developers Subject: Re: NAND technical review References: <4AC6218C.20407@jifvik.org> <4ACB4B58.2040804@ecoscentric.com> <4ACC0722.9020601@jifvik.org> <4ACCC13F.40009@cs.vu.nl> <4AD69BBE.6070103@jifvik.org> <4AD73386.4030300@cs.vu.nl> <4AD7CD29.1050701@jifvik.org> <4ADC777F.4020506@cs.vu.nl> <4ADD2CAB.4010000@jifvik.org> <4ADDAC7A.1070206@cs.vu.nl> <4ADE679D.1050900@jifvik.org> <4ADEFCFE.9060603@cs.vu.nl> In-Reply-To: <4ADEFCFE.9060603@cs.vu.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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/msg00046.txt.bz2 Rutger Hofman wrote: > Jonathan Larmour wrote: > >> Rutger Hofman wrote: >>> 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. Ok. And associated code updates of course. > 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. Although there are other ways to test code than requiring it to have an abstract API in order to access internals. Having the anc/controller/chip layers as self-contained APIs necessarily incurs some overheads. > 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. Also looking at all the source files there are quite a few parts which go straight to the chip layer. Again I'm not saying it can't be done, but it looks like it requires a lot of unpicking, and making sure the right bits end up in the most appropriate places. [snip] Thanks for the various outlines. > 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). I would be very surprised by a day! > 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. Obviously Andrew was able to advise on some aspects at the time. But also at that point in time, my own understanding of the requirements of a NAND layer wasn't as developed as it has now become so I wouldn't have been able to give you that level of feedback then anyway. Although I'm reluctant to do so, I think it would probably prove valuable to the decision process if I could do some size and timing measurements. I'll have to look at that, but as I'll need to adapt E's rwbenchmark.c to R, it'll take me a little time. Finally, are there any questions about E's layer that you think I should ask about which I haven't? Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine