From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2242 invoked by alias); 13 Oct 2009 06:35:35 -0000 Received: (qmail 2233 invoked by uid 22791); 13 Oct 2009 06:35:34 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from ip2.televic.com (HELO lx-dmz.televic.com) (81.82.194.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 06:35:29 +0000 Received: (qmail 9804 invoked from network); 13 Oct 2009 06:35:20 -0000 Received: from srv-vs06.televic.com (10.0.0.46) by lx-dmz.televic.com with (RC4-MD5 encrypted) SMTP; 13 Oct 2009 06:35:20 -0000 Received: from [127.0.0.1] (10.0.56.4) by SRV-VS06.TELEVIC.COM (10.0.0.46) with Microsoft SMTP Server id 8.1.291.1; Tue, 13 Oct 2009 08:35:45 +0200 Message-ID: <4AD41FA6.2020600@televic.com> Date: Tue, 13 Oct 2009 06:35:00 -0000 From: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Larmour CC: Ross Younger , Rutger Hofman , eCos developers , Deroo Stijn Subject: Re: NAND technical review References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org> In-Reply-To: <4AD3E92E.5020301@jifvik.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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/msg00014.txt.bz2 Jonathan Larmour wrote: > Jürgen Lambrecht wrote: > >> Ross Younger wrote: >> >>> - 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. It is not thought >>> that more than a handful such changes will ever be required, and it >>> may be >>> possible to maintain backwards compatibility. (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.) >>> >> Therefore we prefer R's model. >> >> Is it possible that R's model follows better the "general" structure of >> drivers in eCos? >> I mean: (I follow our CVS, could maybe differ from the final commit of >> Rutger to eCos) >> 1. with the low-level chip-specific code in /devs >> (devs/flash/arm/at91/[board] and devs/flash/arm/at91/nfc, and >> devs/flash/micron/nand) >> 2. with the "middleware" in /io (io/flash_nand/current/src and there >> /anc, /chip, /controller) >> 3. with the high-level code in /fs >> > > I don't see E's model as being much different in that perspective. There > is stuff in devs/flash, io/nand and (presumably) fs as well. > > The difference is more the separation out of the controller functionality > into a different layer. > > >> Is it correct that R's abstraction makes it possible to add partitioning >> easily? >> (because that is an interesting feature of E's implementation) >> > > As Rutger said, it could be done - there's nothing in his design which > presents it. It's not there now though, so unless someone's working on it > it's probably not something to consider in the decision process. > Especially since it would be a big user API change. > > >> We also prefer R's model of course because we started with R's model and >> use it now. >> > > You haven't done any profiling by any luck have you? Or code size > analysis? Although I haven't got into the detail of R's version yet (since > I was starting with dissecting E's), both the footprint and the cumulative > function call and indirection time overhead are concerns of mine. > > No... >>> (b) Availability of drivers >>> > [snip] > >>> - 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?) >>> >>> >> - Two: also the Micron MT29F2G08AACWP-ET:D 256MB 3V3 NAND FLASH (2kB >> page size, x8) >> Because if this chip, Rutger adapted the hardware ECC controller code, >> because our chip uses more bits (for details, ask Stijn or Rutger). >> > > I'd be interested in what the issue was. From admittedly a quick look I > can't find anything about this in the code. > Maybe Rutger can better answer this. Else Stijn can look-up his mail on this issue. > >>> (d) Degree of testing >>> > [snip] > >> We have it very well tested, amongst others >> - an automatic (continual) nand-flash test in a clima chamber >> - stress tests: putting it full over and over again via FTP (both with >> af few big and many small files) and check the heap remaining: >> * Put 25 files with a filesize of 10.000.000 bytes on the filesystem >> * Put 2500 files with a filesize of 100.000 bytes on the filesystem >> * Put 7000 files with a filesize of 10.000 bytes on the filesystem >> Conclusion: storing smaller files needs more heap, but we still have >> plenty left with our 16MB >> * Write a bundle of files over and over again on the filesystem. We put >> everytime 1000 files of 100.000 bytes filesize on the flash drive. >> - used in the final mp3-player application >> > > That's extremely useful to know, thanks! But a couple of further questions > on this: (1) Did any bad blocks show up at any point? (2) Were you using a bad > block table? (3) Presumably there were factory-marked bad blocks on some? > (3) Yes, there are almost always factory-marked bad blocks. (2) yes (1)Yes, certainly! We have from time to time bad blocks, and they are handled correctly. Kind regards, Jürgen > Thanks, > > Jifl > -- > --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine > totally agree ;-)