From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26279 invoked by alias); 18 Nov 2008 15:59:23 -0000 Received: (qmail 26135 invoked by uid 22791); 18 Nov 2008 15:59:21 -0000 X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Nov 2008 15:58:31 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id CCE363B40070; Tue, 18 Nov 2008 15:58:28 +0000 (GMT) X-Virus-Scanned: amavisd-new at ecoscentric.com Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb0Gn2Ps+Knp; Tue, 18 Nov 2008 15:58:27 +0000 (GMT) Message-ID: <4922E622.5070906@eCosCentric.com> Date: Tue, 18 Nov 2008 15:59:00 -0000 From: Jonathan Larmour User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Bart Veer CC: ecos-devel@ecos.sourceware.org, eCos Maintainers Subject: Re: [flashv2 merge] io/flash References: <4922125E.9070308@eCosCentric.com> <49222917.8020407@eCosCentric.com> In-Reply-To: X-Enigmail-Version: 0.94.4.0 OpenPGP: id=A5FB74E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2008-11/txt/msg00002.txt.bz2 [Adding maintainers due to request for volunteers! Bart's mail came from ecos-devel] Bart Veer wrote: > >>>>>> "Jifl" == Jonathan Larmour writes: > > > > Jifl> To which Bart validly replied: > Jifl> -=-=-=-=-=-=- > Jifl> I raised it with Andrew back in July. Unfortunately it is > Jifl> not currently possible. The currently defined constructor > Jifl> priorities are not sufficiently flexible to cope with > Jifl> dataflash, where the flash subsystem cannot be initialized > Jifl> until after the SPI bus. It would be necessary to reorganize > Jifl> the defined priorities, which is not something to be tackled > Jifl> lightly. > Jifl> -=-=-=-=-=-=- > > Jifl> Unfortunately discussion fizzled out. My bad. > > I am not sure this is the right time to change the init priorities, Only because it eventually affects the flash API, which means that this is the right time. > Now, I suspect that no solution is going to work for every bit of > hardware that people can conceive off. As and when we run into > problems we may have to add configury for setting certain init > priorities, together with requires constraints in the platform HAL, to > ensure that everything initializes in the correct order for a specific > platform. However the following order should work for most systems: > > #define CYG_INIT_BUS_PRIMARY > #define CYG_INIT_BUS_PCI (alias for PRIMARY) > #define CYG_INIT_BUS_SECONDARY > #define CYG_INIT_BUS_USBHOST (alias for secondary) > #define CYG_INIT_BUS_TERTIARY > #define CYG_INIT_BUS_SPI (alias for tertiary) > #define CYG_INIT_BUS_I2C (ditto) > #define CYG_INIT_BUS_CAN (?) > #define CYG_INIT_DEV_WATCHDOG > #define CYG_INIT_DEV_WALLCLOCK > #define CYG_INIT_DEV_BLOCK_PRIMARY > #define CYG_INIT_DEV_FLASH (alias for BLOCK_PRIMARY) > #define CYG_INIT_CONFIG > #define CYG_INIT_DEV_BLOCK_SECONDARY > #define CYG_INIT_DEV_CHAR (all other devices) > #define CYG_INIT_IO_FS [big snip] I think this is all absolutely fine. > Finally the file I/O subsystem. Possibly this should happen earlier, > between DEV_BLOCK_PRIMARY and CONFIG, so that an implementation of the > config data module can be layered on top of file I/O. Or possibly > CYG_INIT_IO_FS should happen immediately after CYG_INIT_MEMALLOC, with > the proviso that file I/O operations for devices may fail until later > in the init sequence. It's certainly plausible to want to read config data from an FS, IMHO. But CYG_INIT_MEMALLOC seems unnecessarily early and would probably cause more problems than it solves. > Back to the original email and what should happen in the flash code, > off the top of my head my preference would be along the following > lines: > > 1) assume that diag_printf() is available after CYG_INIT_HAL, although > on a few platforms it may discard data until later in the init > sequence. > > 2) change the CHATTER() macro to cope with a NULL pf field. > > 3) default all devices to pf=NULL, which should be happening anyway > because the CYG_FLASH_DRIVER() macro does not initialize it. > > 4) remove the pf argument from cyg_flash_init() completely, so that by > default the flash subsystem is silent. > > 5) add a cyg_flash_set_printf() function which installs a > printf()-style function for a given flash device. Or possibly two > functions, one for a given device, another for all devices. Allow this > function to be called before cyg_flash_init(). > > 6) change RedBoot to install diag_printf() before cyg_flash_init(). > > I think this automatically gives us the desired default behaviour for > both applications and RedBoot, and may end up removing a diag_printf() > dependency for some applications. I think that's great and clearly set out. I expect I'll be up to my eyeballs on eCos 3.0 stuff and the other bits and pieces you know about. Can one of the other maintainers or contributors perhaps step up and take this forward please? I think that pinning down the flash driver API for the 3.0 release is vital. > Or we could be more ambitious and get rid of cyg_flash_init() > completely, replacing it with a CYG_INIT_DEV_FLASH constructor. That's a comparatively small step. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine