From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19441 invoked by alias); 12 May 2009 12:18:02 -0000 Received: (qmail 19431 invoked by uid 22791); 12 May 2009 12:18:01 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr17.xs4all.nl (HELO smtp-vbr17.xs4all.nl) (194.109.24.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 May 2009 12:17:55 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr17.xs4all.nl (8.13.8/8.13.8) with ESMTP id n4CCHo57063752; Tue, 12 May 2009 14:17:50 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A0969C0.7080901@cs.vu.nl> Date: Tue, 12 May 2009 12:18:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Simon Kallweit CC: "ecos-devel@ecos.sourceware.org" Subject: Re: Synth NAND Flash References: <4A0855FB.1030908@intefo.ch> <4A093512.60903@intefo.ch> In-Reply-To: <4A093512.60903@intefo.ch> Content-Type: text/plain; charset=ISO-8859-1; 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-05/txt/msg00012.txt.bz2 Simon Kallweit wrote: > Simon Kallweit wrote: >> Now for the actual design of the synth driver. I think the best way >> would be to implement a NAND simulator based on the ONFI >> specification. Something similar has been done for the MTD framework, >> but I guess other than for inspiration we're not allowed to use that >> code. So basically we would simulate the interface to the chip. I >> guess we don't have to simulate the signal lines. We just need some >> mechanism for chipselect and reset I guess. The interface will more be >> along the lines of writing commands, addresses, reading back etc. This >> means that the simulator will be implemented as a state machine. There >> is even one described in the ONFI specification for reference. > > Well after some more thought it's probably a better idea to keep the > interface to the NAND chip simulator very close to the hardware. That > means, a function for setting signal lines (CE, CLE, ALE, WP) as well as > two functions for read and write access. See my suggestion on a NAND chip simulator in my previous mail. Having it be accessed using the control lines is the right way to go IMHO: this is where the package boundary/API for NAND chips is. > I don't intend to support multiple LUNs for the moment, just to keep it > simple. > > I have already done the interface to the NAND chip simulator. This seems > to work fine. I'll keep you updated. I'm looking forward! Rutger