From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14951 invoked by alias); 15 Oct 2009 11:54:27 -0000 Received: (qmail 14943 invoked by uid 22791); 15 Oct 2009 11:54:26 -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, 15 Oct 2009 11:54:21 +0000 Received: (qmail 19192 invoked from network); 15 Oct 2009 11:54:19 -0000 Received: from srv-vs06.televic.com (10.0.0.46) by lx-dmz.televic.com with (RC4-MD5 encrypted) SMTP; 15 Oct 2009 11:54:19 -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, 15 Oct 2009 13:54:21 +0200 Message-ID: <4AD70D64.7000406@televic.com> Date: Thu, 15 Oct 2009 11:54:00 -0000 From: =?windows-1252?Q?J=FCrgen_Lambrecht?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Larmour CC: Rutger Hofman , Ross Younger , eCos developers Subject: Re: NAND technical review References: <4ACCC13F.40009@cs.vu.nl> <4ACD9191.60102@televic.com> <4AD69CB7.3080009@jifvik.org> In-Reply-To: <4AD69CB7.3080009@jifvik.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit 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/msg00023.txt.bz2 Jonathan Larmour wrote: > Jürgen Lambrecht wrote: > >> Rutger Hofman wrote: >> >>> 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. >> > > I don't think E's implementation would have the same problem with OneNAND > as R's (see below). Yes it has a sort of controller, but it's not as > advanced as an MMC or SSD one - instead it's there as logic to manage > exchanges between its SRAM and the NAND array. > > >>>> 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 ... >> > > FAOD, I don't believe that's true. You only get a view into a small window > of the NAND. That small window is memory mapped, but that's all. It's > certainly not controlled like a NOR flash. It's a NAND, but not one with > the wire command model that R's implementation assumes. > I'm sorry Jifl, I did not check oneNAND very well. I read a bit about it some time ago when I was looking for a bigger NOR flash for our ARM7 board. Jürgen > Jifl > -- > --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine >