From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32390 invoked by alias); 15 Oct 2009 03:53:37 -0000 Received: (qmail 32382 invoked by uid 22791); 15 Oct 2009 03:53:36 -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; Thu, 15 Oct 2009 03:53:33 +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 n9F3rU418205; Thu, 15 Oct 2009 04:53:30 +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 0CD1A3FEB; Thu, 15 Oct 2009 04:53:29 +0100 (BST) Message-ID: <4AD69CB7.3080009@jifvik.org> Date: Thu, 15 Oct 2009 03:53:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: =?windows-1252?Q?J=FCrgen_Lambrecht?= Cc: Rutger Hofman , Ross Younger , eCos developers Subject: Re: NAND technical review References: <4ACCC13F.40009@cs.vu.nl> <4ACD9191.60102@televic.com> In-Reply-To: <4ACD9191.60102@televic.com> 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/msg00020.txt.bz2 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. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine