From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ecos-devel-return-1667-listarch-ecos-devel=sources.redhat.com@ecos.sourceware.org>
Received: (qmail 17325 invoked by alias); 19 Oct 2009 15:02:28 -0000
Received: (qmail 17236 invoked by uid 22791); 19 Oct 2009 15:02:27 -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-vbr3.xs4all.nl (HELO smtp-vbr3.xs4all.nl) (194.109.24.23)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 15:02:23 +0000
Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) 	by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9JF2ED1073202; 	Mon, 19 Oct 2009 17:02:16 +0200 (CEST) 	(envelope-from rutger@cs.vu.nl)
Message-ID: <4ADC8114.7010503@cs.vu.nl>
Date: Mon, 19 Oct 2009 15:02:00 -0000
From: Rutger Hofman <rutger@cs.vu.nl>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Simon Kallweit <simon.kallweit@intefo.ch>
CC: Jonathan Larmour <jifl@jifvik.org>, Ross Younger <wry@eCosCentric.com>,         eCos developers <ecos-devel@ecos.sourceware.org>
Subject: Re: NAND technical review
References: <4AC6218C.20407@jifvik.org> <4AD820DE.7030002@intefo.ch>
In-Reply-To: <4AD820DE.7030002@intefo.ch>
Content-Type: text/plain; charset=ISO-8859-1; 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: <ecos-devel.ecos.sourceware.org>
List-Subscribe: <mailto:ecos-devel-subscribe@ecos.sourceware.org>
List-Post: <mailto:ecos-devel@ecos.sourceware.org>
List-Help: <mailto:ecos-devel-help@ecos.sourceware.org>, <http://ecos.sourceware.org/lists.html#faqs>
Sender: ecos-devel-owner@ecos.sourceware.org
X-SW-Source: 2009-10/txt/msg00036.txt.bz2

Simon Kallweit wrote:
> ... What 
> I dislike is how the synthetic chips have to be configured. R's 
> implementation needs the user to assign a valid NAND chip device id, 
> which will then be used through chip interrogation to determine the 
> chips geometry. I find it much more useful if you can directly define 
> the chips geometry in CDL, as it's more explicit.

This emulates the read_id command in the same way as the other commands. 
I saw no way around this because the generic code calls read_id and 
expects an answer in the prescribed way.

Well, this all (again) does mean that R's (my) common controller stuff 
is really tied to the raw NAND chips. See my other responses for what to 
do if anything else is needed.

Rutger