From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12211 invoked by alias); 16 Oct 2009 01:32:35 -0000 Received: (qmail 12201 invoked by uid 22791); 16 Oct 2009 01:32:34 -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, 16 Oct 2009 01:32:30 +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 n9G1WQ421862; Fri, 16 Oct 2009 02:32:26 +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 0EAB83FEB; Fri, 16 Oct 2009 02:32:26 +0100 (BST) Message-ID: <4AD7CD29.1050701@jifvik.org> Date: Fri, 16 Oct 2009 01:32: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> In-Reply-To: <4AD73386.4030300@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/msg00027.txt.bz2 Rutger Hofman wrote: > Jonathan Larmour wrote: >> Rutger Hofman wrote: >>> Jonathan Larmour wrote: >>> >>>> Does your implementation _require_ a BBT in its current >>>> implementation? For simpler NAND usage, it may be overkill e.g. an >>>> application where the number of rewrites is very small, so the >>>> factory bad markers may be considered sufficient. > > > I had forgotten: there is a configuration option to bypass BBT and only > use factory-bad markers (and caveat emptor). Ah. Your documentation includes: "Before the second initialization stage, some properties of the NAND system can be configured. These are en/disabling of ECC generation and en/disabling of a Bad Block Table (BBT). By default, ECC and BBT are enabled." I hadn't noticed that these are not in fact CDL configuration options. They ought to be really. >>> This is a bit hairy in my opinion, and one reason is that there is no >>> Standard Layout for the spare areas. One case where a BBT is forced: >>> my BlackFin NFC can be used to boot from NAND, but it enforces a >>> spare layout that is incompatible with MTD or anybody. It is even >>> incompatible with most chips' specification that the first byte of >>> spare in the first page of the block is the Bad Block Marker. >>> BlackFin's boot layout uses this first byte in a way that suits it, >>> and it may be 0 -- which would otherwise mean Bad Block. >> >> >> I infer that your layer can cope with that? I didn't see the handling >> for that in io_nand_chip_bad_block.c. > > No (not yet). If it doesn't sound too silly, how were you able to test your layer on the bfin then? > To use the NAND controller in this way, a different spare > layout must be used for the chip. Although there are no obstacles to > selecting different spare layouts, there is no support for that yet. It > would require one extra parameter in the chip device struct > 'constructor' (e.g. with NULL for 'choose default = MTD compatible'). You mean CYG_NAND_DRIVER_CHIP()? Presumably some way to pass a different layout? I was wondering about the extensibility of the spare layouts given how much stuff is sort of hard coded - sure it may fit plenty of existing chips but more can come along. In the chip ID table in io_nand_chip.c I haven't worked out what the layout field is for - I can't find where it is used. I also can't see how a driver in a new port can add a new chip with a new layout. There's talk in read_id() of being able to do a custom chip device (does that mean also you can do a custom spare layout?), but it's not clear to me how a new port can add that to the table since read_id() only searches the table. Obviously it's not sensible to have to keep changing io/nand, and may be inappropriate for custom spare layouts. NB the chip ID table can be const can't it? > For the record: MDT/Blackfin/u-boot has support for this different > layout, but it is build-static. MDT cannot hot-swap layouts (at the > moment). That's reasonable given it's associated with the controller. >> Is your BBT compatible with Linux MTD? Including your use of a mirror? > > > Yes, I read MTD, and tried to copy their BBT handling as faithfully as > possible without actually copying code. It is on my stack to check if > the BBTs are indeed identical; as you may have noticed elsethread, my > eCos application wants to share a YAFFS 'disk' with u-boot which has MTD. Okay. Obviously compatibility is very important, especially for those using eCos/RedBoot just to load Linux. But also, since R does not have partitioning, won't that potentially interfere with compatibility with MTD? A Linux booted image may not be using the whole chip as a single FS. [memory use] >> If you know what it's going to be (at most), it could just be >> allocated statically and just used directly surely? That's got the >> lowest overheads. >> >> E's implementation had a good idea of a CDL variable for the maximum >> supported block size. Then individual HALs or driver packages can use >> a CDL 'requires' to ensure it's >= the block size of the chips really >> in use. > > I can follow Ross's example here. Together with a switch to constructor > and a cleanup of printfs, that will take some days. If it matters in the > decision, I will schedule this to be finished within one month. I'll make a note about it - again I don't want you to be adjusting things before the decision has been made - I for one certainly haven't made up my mind either way. But thanks very much for your willingness to do so! I doubt either implementation will be checked in with zero further changes anyway. [OneNAND (and things like it) fitting into R's model] > I will take a better look at the OneNAND datasheet. You are right, it is > software-wise as different from NOR as from 'raw' NAND. My guarded guess > now is that integration into R would imply a replacement of the Common > Controller code (by configuration or by 'object-oriented' indirect calls > over a device struct). I will report on this later. Thanks. Although of course adding more indirection may have its own disadvantages. Ross, if you're reading, I would be interested to know whether something with a different access model, like OneNAND, would work with E's layer, in your opinion. While I think the answer is yes, I had better check. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine