From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12509 invoked by alias); 20 Oct 2009 12:19:47 -0000 Received: (qmail 12501 invoked by uid 22791); 20 Oct 2009 12:19:46 -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-vbr6.xs4all.nl (HELO smtp-vbr6.xs4all.nl) (194.109.24.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Oct 2009 12:19:40 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9KCJR8p088524; Tue, 20 Oct 2009 14:19:34 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4ADDAC7A.1070206@cs.vu.nl> Date: Tue, 20 Oct 2009 12:19: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> <4ADC777F.4020506@cs.vu.nl> <4ADD2CAB.4010000@jifvik.org> In-Reply-To: <4ADD2CAB.4010000@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/msg00041.txt.bz2 Jonathan Larmour wrote: > Rutger Hofman wrote: > 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. This represents the fourth byte of the 'regular' read_ID response. (First is manufacturer, second is device type, third is often 0, but may be defined to give further architectural details.) The specx for this layout byte: bit meaning description 0..1 1KB, 2KB, 4KB, 8KB page size 2 8, 16 spare bytes per 512 data bytes 4..5 64KB, 128KB, 256KB, block size (without spare) 6 x8, x16 bus width The other bits differ across manufacturers. Reading and parsing this byte is still insufficient to fully access the chip: its total size is unknown. It can be in the third byte, in which case the chip table needn't wouldn't need an entry for this chip because it is sufficiently self-descriptive. >>>> 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. Hot-swapping is necessary to pull this tric. It would be doable in my current svn version (which is coming up one of these days). It would imply crossing through all layers though, and it would indeed be horribly risky. >> 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. [snip] >>> 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. If this is so (I am not conversant enough yet with Linux internals) then it is a very useful addition. Using multiple YAFFS devices is straightforward right now (I did this and met no problems). >>> [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. The reworking would just be to replace the calls in the ANC of the controller-common API with indirect calls, and supporting this configurability in the CDL. OneNAND doesn't need ECC code because things are handled in hardware (the datasheet recommends not even checking the ECC status register for 2-bit failures because they are so rare). Maybe BBT is necessary too for OneNAND; I didn't think that through yet, 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). In conclusion: a driver in R for a different class of chip than 'raw NAND' would indeed replace R's controller-common, any controller-device-specific, and any chip, because these are all code for raw NAND. I would hope that linker magic remove the code as unused from the binary. A driver for OneNAND would still need to be written obviously, and it would share no or little code with controller-common and raw chip. My guess is that would hold for E too - although I don't really know because I have had no time to review E's code. Rutger