From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17608 invoked by alias); 12 May 2009 12:13:44 -0000 Received: (qmail 17598 invoked by uid 22791); 12 May 2009 12:13:43 -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-vbr5.xs4all.nl (HELO smtp-vbr5.xs4all.nl) (194.109.24.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 May 2009 12:13:38 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id n4CCDXDc004164; Tue, 12 May 2009 14:13:33 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A0968BF.3050204@cs.vu.nl> Date: Tue, 12 May 2009 12:13: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> In-Reply-To: <4A0855FB.1030908@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/msg00011.txt.bz2 Simon Kallweit wrote: > Hi there > > I merged the NAND code from Rutger into my repo and tried to figure out > how to write synthetic target support, which in my opinion would be a > great addition so we can test future filesystems (UFFS) without a > target, do wear-leveling analysis and stuff like that. > > First, I noticed a few things I would like to clear up in front. > Currently, the NAND subsystem sits in io/flash_nand which I think is > fine. But the devices sit under devs/flash, which is the same location > as for NOR flash. I think we should rename this to devs/flash_nand. I > already did this in my merge. This would make the distinction between > NOR and NAND flash more clearer. I also thought about renaming the whole > framework from flash_nand to simply nand. This would also match the API > names cyg_nand_xxx better. Are there any objections? In fact, this is how I started out originally. But Andrew Lunn convinced me to do otherwise: http://ecos.sourceware.org/ml/ecos-discuss/2008-09/msg00172.html > I started out with eCos in it's default template. I was getting some > errors because of the missing ssize_t type. Either we should get rid of > it or add something like this to the CDL: > > require CYGBLD_ISO_SSIZE_T_HEADER My Ubuntu man page says that ssize_t should be defined by sys/types.h; requiring CYGPKG_ISOINFRA ought to be good enough. > Other than that there is a little bit of cleaning up to do, but I think > that's all minor stuff. I'm open for recommendations. > Next I copied the GPIO nand flash controller to make a synth version and > also copied a st-micro NAND chip driver to make a synth version. For > now, they are pretty empty skeletons. But I was able to build the NAND > subsystems with those dummy drivers. Of course, the test cases don't > work. It also occurred to me that the "shell.c" test has quite a few > dependencies. I just removed this test for the moment. Yes, sure, "shell.c" allows a number of operations to be done interactively. It is not so much in the vein of automated stress testing. It was in fact my testing vehicle for a raw terminal program. I'm fine with removing it from the standard test build, but I would be sorry to see it go. > 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. I never heard of an actual ONFI chip yet. Current chips are usually of the regular large-page kind. It might be most practical to make a generic regular large-page chip emulator that can be parameterized with the Device IDs as enumerated in cyg_nand_chip_id[] in file flash_nand/src/chip/io_nand_chip.c . > I think the basics can be implemented rather quickly. I guess we don't > need to simulate multiple concurrent LUNs, or does the framework already > support these? Multiple LUNs is the same as multiple chips, as far as the NAND package (or ONFI) is concerned. It should be supported, but it is untested because I lacked hardware. > Well that's about it. I'll try to implement a simple simulator tomorrow > and see where I get. I post back some results as soon as I have something. > > Simon Rutger