From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15274 invoked by alias); 23 Oct 2009 15:25:06 -0000 Received: (qmail 15254 invoked by uid 22791); 23 Oct 2009 15:25:05 -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-vbr9.xs4all.nl (HELO smtp-vbr9.xs4all.nl) (194.109.24.29) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Oct 2009 15:24:59 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9NFOrLA071362; Fri, 23 Oct 2009 17:24:54 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4AE1CAD0.4080206@cs.vu.nl> Date: Fri, 23 Oct 2009 15:25:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jonathan Larmour CC: Ross Younger , eCos developers Subject: Re: NAND technical review References: <4AC6218C.20407@jifvik.org> <4ACB4B58.2040804@ecoscentric.com> <4ACC0722.9020601@jifvik.org> <4ACCC13F.40009@cs.vu.nl> <4AD69BBE.6070103@jifvik.org> <4AD73386.4030300@cs.vu.nl> <4AD7CD29.1050701@jifvik.org> <4ADC777F.4020506@cs.vu.nl> <4ADD2CAB.4010000@jifvik.org> <4ADDAC7A.1070206@cs.vu.nl> <4ADE679D.1050900@jifvik.org> <4ADEFCFE.9060603@cs.vu.nl> <4AE1B864.1040409@jifvik.org> In-Reply-To: <4AE1B864.1040409@jifvik.org> Content-Type: text/plain; charset=windows-1252; 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-10/txt/msg00047.txt.bz2 Jonathan Larmour wrote: > Rutger Hofman wrote: >> Jonathan Larmour wrote: >> >>> Rutger Hofman wrote: [on adding support for other NAND chips than raw NAND] > >> I guess that this refactoring will take something like one or a few >> days' work, including having ANC call the controller over a dispatch >> table. I'll be glad to do it (ETA: somewhere in the next 1 to 1.5 >> months). > > I would be very surprised by a day! Yesterday, there was an unexpected lull in the usual storm of work. Basically, the refactoring is done so R can support hardware other than raw NAND. I must still update the documentation, though. The structure is a bit different than I first thought; there is a package IO_NAND for the general stuff (anc, ecc, bbt), and a package IO_NAND_RAW for the raw NAND. So, if somebody wants NAND but not raw NAND, that package isn't included so no raw NAND code. I will put up a next release when the documentation is done. I am aware that changing the code while you are reviewing it is not very polite; maybe you prefer to stick with the code that you have right now, and just acknowledge any updates/refactoring I did. An unusual problem has cropped up in my synth build. After having run my tests on the BlackFin, I built for synth and I am now meeting weird alignment behaviour in the HAL_TABLE device tabs. My gcc (gcc-4.2.real (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) for synth generates a directive .align 32 in the declaration of a device struct in the appropriate section, but the HAL_TABLE array has align=4. In consequence, the pointer to traverse the device table has the wrong stride. 'Proof': if I hand-align the device struct to be a multiple of 32, things work correctly in synth. Anybody any idea what I should do? Put in an align(32) directive on the device struct definitions? That is a hack to work around a compiler bug just for one platform, I'd say; OTOH it's bad that it might just bite *any* synth device driver table, not only mine. > Finally, are there any questions about E's layer that you think I should > ask about which I haven't? I am sorry, I have had no time to review E's layer. My boss tells me loudly that doing so is not on the critical path of our project... Rutger