From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13951 invoked by alias); 8 Oct 2009 07:15:50 -0000 Received: (qmail 13933 invoked by uid 22791); 8 Oct 2009 07:15:47 -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; Thu, 08 Oct 2009 07:15:34 +0000 Received: (qmail 23450 invoked from network); 8 Oct 2009 07:15:31 -0000 Received: from srv-vs06.televic.com (10.0.0.46) by lx-dmz.televic.com with (RC4-MD5 encrypted) SMTP; 8 Oct 2009 07:15:31 -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; Thu, 8 Oct 2009 09:15:51 +0200 Message-ID: <4ACD9191.60102@televic.com> Date: Thu, 08 Oct 2009 07:15:00 -0000 From: =?windows-1252?Q?J=FCrgen_Lambrecht?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Rutger Hofman CC: Jonathan Larmour , Ross Younger , eCos developers Subject: Re: Re: NAND technical review References: <4ACCC13F.40009@cs.vu.nl> In-Reply-To: <4ACCC13F.40009@cs.vu.nl> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit 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/msg00007.txt.bz2 Rutger Hofman wrote: >>> - R's model shares the command sequence logic amongst all chips, >>> differentiating only between small- and large-page devices. (I do not >>> know >>> whether this is correct for all current chips, though going forwards >>> seems >>> less likely to be an issue as fully-ONFI-compliant chips become the >>> norm.) >>> >> Hmm. Nevertheless, this is a concern for me with R's. I'm concerned it >> may be too prescriptive to be robustly future-proof. >> > > Well, there is no way I can see into the future, but I definitely think > that the wire command model for NAND chips is going to stay -- it is in > ONFI, after all. Besides, all except the 1 or 2 most pioneering museum > NAND chips use it too. There are chips that use a different interface, > like SSD or MMC or OneNand, but then these chips come with on-chip bad > block management, wear leveling of some kind, and are completely > different in the way they must be handled. I'd say E's and R's > implementations are concerned only with 'raw' NAND chips. > > Correct, only for raw NAND chips to be soldered on a board. The others have an embedded controller and are already packaged. >> One could say that makes it a more realistic emulation. But yes I can >> see disadvantages with a somewhat rigid world view. Thinking out loud, I >> wonder if Rutger's layer could work with something like Samsung OneNAND. >> > > See my comment above. The datasheet on e.g. KFM{2,4}G16Q2A says: > "MuxOneNAND™‚ is a monolithic integrated circuit with a NAND Flash array > using a NOR Flash interface." > > Indeed, a oneNAND is to be threated as a NOR flash, like a pseudoSRAM is a DRAM with SRAM interface. And SSD has a hard disk drive interface, just like MMC and SD card; they mostly have a FAT file system on them but also UFS ... Kind regards, Jürgen