From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12815 invoked by alias); 20 Oct 2009 03:21:26 -0000 Received: (qmail 12802 invoked by uid 22791); 20 Oct 2009 03:21:24 -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; Tue, 20 Oct 2009 03:21:20 +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 n9K3LH406149; Tue, 20 Oct 2009 04:21:17 +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 ABA8A3FEB; Tue, 20 Oct 2009 04:21:16 +0100 (BST) Message-ID: <4ADD2CAB.4010000@jifvik.org> Date: Tue, 20 Oct 2009 03:21: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> In-Reply-To: <4ADC777F.4020506@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/msg00038.txt.bz2 Rutger Hofman wrote: > Jonathan Larmour wrote: >> Rutger Hofman wrote: >>> Jonathan Larmour wrote: >>>> Rutger Hofman 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. Sure, thanks. I'm making a note that it will be done, so don't worry about getting it done. >>>>> 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. >>> [ R's layer can't do this 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. I understand that the bfin's boot loader oddities aren't really relevant in themselves (since we don't support bfin in the repository yet anyway :-)). >> 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(). Ok, that should help. > 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. I was referring to the "layout" field of cyg_nand_chip_id_t. Whereas spare_scatter_fill()/extract() use the spare_layout field of the cyg_nand_chip_info_t. I haven't yet found where the "layout" field of cyg_nand_chip_id_t is used. >>> 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. So I believe that means if you want to rewrite the boot program on Blackfin _and_ use a normal layout, you wouldn't be able to use R as it stands at the moment. Ack, OK. > OTOH, if anything else of the NAND is going to be used, the MTD layout > is required. So hot-swapping is highly desirable Hot swapping sounds like a risky thing to do, with potentially multiple subsystems wanting access to flash, not just the application. Anyway, I think I'm getting myself bogged down in detail. I don't believe E could support this bootloader either without a BBT (without modification). So I don't think there's anything to distinguish the two implementations when it comes to the oddities of the blackfin boot loader. >> 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. Yes, but that isn't the same as not supporting partitions. Just that they aren't fixed. They're specified on the kernel boot line, and so can be configured by the user arbitrarily.... it's just that you can't change them without rebooting. So I believe anyone who is using multiple partitions with MTD would have difficulties interoperating with R. >> [OneNAND (and things like it) fitting into R's model] >> >>> 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. Would that not require a significant reworking and relayering of code? It seems to me that controller drivers and the chip drivers used by controller drivers under this system will still want to be able to access the infrastructure support for BBTs, ECCs and spare layout. From what I can see, preserving that without large amounts of indirection (imposing further performance and size hits) would pose quite some challenge. The result would be something really quite different to what R is like today. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine