From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20919 invoked by alias); 3 Jun 2009 08:51:27 -0000 Received: (qmail 20910 invoked by uid 22791); 3 Jun 2009 08:51:26 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_50,KAM_ADVERT2,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Jun 2009 08:51:20 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1MBmBn-0000Vt-00; Wed, 03 Jun 2009 10:51:15 +0200 Date: Wed, 03 Jun 2009 08:51:00 -0000 From: Andrew Lunn To: john@dallaway.org.uk Cc: "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review Message-ID: <20090603085115.GA27508@lunn.ch> References: <4A126D59.7070404@intefo.ch> <20090519162853.GA27459@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090519162853.GA27459@lunn.ch> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00005.txt.bz2 > Date: Tue, 02 Jun 2009 19:17:58 +0100 > From: John Dallaway > To: Andrew Lunn > CC: eCos Maintainers > Subject: Re: NAND & YAFFS > > Have you been able to form a view on the relative merits of the VU > Amsterdam and eCosCentric implementations so far? Just wanting to ensure > that this process is not stalled for any reason... > > John Dallaway Hi John I've spent a little time looking at the documentation and followed the discussions on the mailling lists. I've not dug into the code at all. >From this i have my first impressions: eCosCentric/Ross entered the game late, after starting behind closed doors. There was no RFC about the design, APIs etc. VU/Rutger on the other hand has been very open, posted his designs and APIs, been involved in discussion and made changes that resulted from the discussions. This gets lots of +ve points for Rutger and many -ve points for Ross/eCosCentric. I would say the current documentation of the two frameworks is about equal and generally good. No complains here. IMHO Ross's partitioning scheme/API is broken. I've tried to trigger discussion about this, but there has not been much interest. This is a shame, because to fix it will require API changes, so requiring changes to the YAFFS glue code etc. I'm also not the only one with reservations about this partitioning, i've had a private email from a respected member of the community expressing reservations about the concept. I don't see it currently being a problem that Rutgers code does not have a partitioning concept. It has a nice clean API to application/filesystem code. My first impression from reading the documentation suggests that adding partitioning to this will not require any major API changes, it might even be totally transparent. So a few +ve points to Rutger, many -ve points to Ross. I would say the way forward with partitioning is to discuss the requirements, where can the partitioning information come from, where does it need to go to, what should the APIs look like. Then do some design work to make draft APIs, collect comments and then do the implementation work/modifications as necessary. 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. Ross has a simple, but functional synthetic NAND driver. Simon started on a synth driver for Rutgers library, but stopped when Ross made his surprise announcement, wanting to see which way we go. Simon also commented that he used quite a bit of MTD code. This got me a bit worried about GPL issues, but there was an interesting comment from Ross that an older version of MTD has a more eCos friendly license. So, a few +ve points for Ross, with respect to synth drivers. Initially i was a bit worried about Rutgers need for dynamic memory allocation. This is needed for the bad block table and per thread error reporting support. This could be a problem for Redboot, where you don't normally have a "heap", malloc and free etc. However, on second thoughts, i don't think this is too big an issue. YAFFS needs malloc/free. UFFS can either use its own malloc/free implementation, or use the system provided functions. So in general, redboot is going to need malloc/free for supporting file systems, so having the NAND library using it is not that bad. Ross's code has the bad block table statically allocated, sized using CDL. This removes the need for malloc/free. However, in some ways, it reduces the flexibility. I've seen quite a few systems with the same basic hardware, just different sized FLASH chipsets. With Rutgers system, this should be no problem, is just asks for as much heap as needed. Ross's system may need different eCos builds for each hardware variant, since the size of the BBT is hard coded in the HAL, plus the partition table is also hard coded in the HAL. The important thing here is that the code for allocating/freeing the memory is nicely encapsulated so that it is not too difficult to add extra options, controlled via CDL, as to how it gets the memory it needs. I'd need to review the code to see how well this is implemented in both systems. There was an email from Rutger that Televic are willing to contribute their drivers for an AT91SAM9260 based board. If that happens, it would mean two real implementations for Rutgers, vs one for Ross. Rutgers API allows reading/writing less than a page, eg just a few bytes. Ross's API is page based. I don't know if this is an advantage or a disadvantage. Simon commented he preferred Ross's directory layout within the repository. I have no strong preference here, and it should be trivial to change Rutgers layout if we wanted to. There was comments from Ross about excessive stack usage blowing his target away. This might indicate the immaturity of his code? Rutgers has been using his code in RFID guardian, and i presume Televic have also been using the code. So i get the feeling Rutgers code is more stable and mature. Overall, i currently favour Rutgers implementation. However, as i said at the beginning, i've not looked at the actual source code yet. Andrew