From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4039 invoked by alias); 19 Oct 2009 14:21:37 -0000 Received: (qmail 4023 invoked by uid 22791); 19 Oct 2009 14:21:36 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr16.xs4all.nl (HELO smtp-vbr16.xs4all.nl) (194.109.24.36) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 14:21:30 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr16.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9JELKam025624; Mon, 19 Oct 2009 16:21:26 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4ADC777F.4020506@cs.vu.nl> Date: Mon, 19 Oct 2009 14:21:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jonathan Larmour 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> In-Reply-To: <4AD7CD29.1050701@jifvik.org> Content-Type: text/plain; charset=windows-1252; 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/msg00034.txt.bz2 Jonathan Larmour wrote: > Rutger Hofman wrote: >> Jonathan Larmour wrote: >>> Rutger Hofman wrote: >>>> Jonathan Larmour wrote: > 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. OK. I'd say no-ECC is a property of the application/ANC and no-BBT is a property of a chip. I'll move these to CDL. When I am done with this and a number of other small changes, I'll put up a new revision. >>>> 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? Well, this mode is *only* for booting a BlackFin from NAND, and for writing the boot blocks into NAND. For all other usage, one still uses the standard MTD spare layout. >> 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. OK, a custom spare layout now is a parameter to CYG_NAND_DRIVER_CHIP(). The layout is used in the common controller code, see calls to function spare_scatter_fill() and spare_scatter_extract(). These serve ECC and application spare slots in the same fashion. > NB the chip ID table can be const can't it? Thanks, fixed. >> 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. Well, not completely. The layout is only associated with the *boot mode*. For other use, there is no prescription of the layout, so it's typical to use the MTD layout - then one can share with Linux or u-boot. Rotten consequence: if one wants to program a new boot image into the first block(s) of the NAND, the boot-compatible layout must be used. OTOH, if anything else of the NAND is going to be used, the MTD layout is required. So hot-swapping is highly desirable > 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. Linux has no fixed approach to partitioning, as I learned during the discussions on this list. > [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. That guarded guess was correct. OneNAND is no raw NAND chip so R's common controller code won't fit. The thing to do is make a driver that comes in place of the common controller, as suggested above. Once ANC supports a pluggable controller (which I will do if it makes a difference), adding a OneNAND will take the same amount of effort as for E's implementation. Rutger