From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15393 invoked by alias); 1 Dec 2008 16:23:05 -0000 Received: (qmail 15364 invoked by uid 22791); 1 Dec 2008 16:23:04 -0000 X-Spam-Check-By: sourceware.org Received: from top.few.vu.nl (HELO top.few.vu.nl) (130.37.20.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Dec 2008 16:22:21 +0000 Received: from [130.37.30.42] (hppc190.cs.vu.nl [130.37.30.42]) by top.few.vu.nl with esmtp (Smail #115) id m1L7BXN-00003WC; Mon, 1 Dec 2008 17:22 +0100 Message-ID: <49341026.4040200@cs.vu.nl> Date: Mon, 01 Dec 2008 18:07:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: eCos Discuss List References: <492F3B9F.8090501@cs.vu.nl> <20081130105317.GH27015@lunn.ch> In-Reply-To: <20081130105317.GH27015@lunn.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: Alpha release eCos NAND Flash, eCos YAFFS X-SW-Source: 2008-12/txt/msg00010.txt.bz2 (Limited the reply to the discuss list) Andrew Lunn wrote: > ecos-nand-flash-api-err.html: > > If a function fails, a global variable is set that indicates where the > error occurred and for what reason > > I don't like this. How do you protect against race conditions with > multiple threads doing accesses? It either needs to be a variable > passed with each function call, or at least in thread local storage. I also prefer thread-local. However, if each thread needs to allocate a struct for error handling, there must be some memory allocator. And it cannot be the one that is passed to cyg_nand_init() because that is too late (and it is nand-struct-specific). Is there a kernel allocator (in the vein of kmalloc) that I could use? > ecos-nand-flash-api-anc.html: > > cyg_flash_get_info() -> cyg_nand_get_info() Thanks, fixed. > ecos-nand-flash-api-anc.html: > > "use_cache is a boolean". eCos has a boolean type, cyg_bool. > > Checks the BBT (Bad Block Table) if this block is good, worn bad, > reserved, or factory-bad. If no BBT is used, attempts to check the > chip for factory-bad marks. > > The last sentence makes no sense. However, it makes sense. A chip can have a BBT put onto it by the NAND library (at its first ever access), or it can be initialized without BBT at the option of the application. If a chip has a BBT, then that is queried. If it has no BBT, checking the factory-bad marks is the best the NAND library can do. > I'm not so happy with cyg_hal_gpio_*. > > The idea of generic GPIO functions needs to be discussed in the bigger > context. More likely these need to be HAL macros, CYG_HAL_GPIO_SET(). > We want these to be fast as generally they are just two or three > assembly instructions. Doing a function call is too expensive in most > cases. You also need a generic way to address pins. The AT91 var hal > has some ideas here. I'd prefer to await the outcome of the ensuing discussion. Another factor is that it is only a template that is not for real use. > You can submit your NOR driver for the blackfin board anytime. It is > separate for NAND. I would much like to submit all of the BlackFin code (once I am convinced that it is stable enough). But most of that code is not by me, but by Andre Liesk who did the port for his Master's in Chemnitz. I should contact him to see if he is willing to transfer the IP to eCos. Rutger -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss