From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23118 invoked by alias); 11 Jun 2009 11:25:14 -0000 Received: (qmail 23050 invoked by uid 22791); 11 Jun 2009 11:25:13 -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-vbr15.xs4all.nl (HELO smtp-vbr15.xs4all.nl) (194.109.24.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Jun 2009 11:25:07 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id n5BBOhkf043262; Thu, 11 Jun 2009 13:24:44 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A30EA39.8030008@cs.vu.nl> Date: Thu, 11 Jun 2009 11:25:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Nick Garnett CC: Andrew Lunn , john@dallaway.org.uk, "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> <20090603085115.GA27508@lunn.ch> In-Reply-To: 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: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-06/txt/msg00020.txt.bz2 Nick Garnett wrote: > Andrew Lunn writes: > >> There has been comments that Rutgers code has too many layers. Rutger >> aims to allow as much code reuse between drivers as possible, which i >> think is good. Simon commented that he thinks Ross's design may result >> in a lot of code stuck in HALs where it is hard to reuse without copy >> paste. However Ross argued that he thinks that making code reusable is >> going to be hard, there is too many different configurations of chips >> and controllers, etc. >> >> With only one supported platform on Ross's code and two with Rutgers, >> i think it is too early to tell the truth. However, im generally in >> favour of layers. > > Just a few quick words about layering... > > We have to be very careful in eCos not to over-do the abstractions. > eCos is still an embedded operating system and not a full-featured > general purpose OS. As such we must take care not to compromise code > size and performance. There are some areas in eCos already where we > have more layers than we strictly need, and performance has > suffered. Many of the target processors are relatively slow, without > caches or much fast memory and every extra call and indirection can > cost a lot of cycles. In my NAND package, there are indirect calls to the device-specific code of the controller. I followed the examples in the eCos documentation, where serial line, Ethernet etc all use this approach. Per NAND page that is written (typically 2KB or 4KB) there are a few indirect calls. My unsubstantiated intuition is that the data transfers would dominate performance compared to a few indirections. There are also a few indirect calls in the chip module, but these are used at initialization time only. Still, this indirection is only needed for heterogeneous controllers. Besides the layering issue, there is another thing that I would like to point out. My NAND package has support for 3 types of NAND chip: small-page (the old type), 'regular' large-page (that's what you buy today), ONFI (I think this still has to hit the market). Small-page has its own instruction set, and has interrogation protocol worth mentioning. 'regular' and ONFI largely share the instruction set but differ completely in the interrogation protocol. For a specific build, it would be not hard at all to compile only the support for the type of chip that is actually used, and to /not/ compile command implementations and interrogation for the other types. This same observation would hold for the ECC routines, and, as I mentioned in an earlier email, for the code that hides away controller or chip heterogeneity. Rutger