From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18699 invoked by alias); 18 Nov 2008 11:39:18 -0000 Received: (qmail 18573 invoked by uid 22791); 18 Nov 2008 11:39:16 -0000 X-Spam-Status: No, hits=-1.7 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 11:38:26 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 1A0A9208030 for ; Tue, 18 Nov 2008 11:38:23 +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 Uw5WaPVnT05h; Tue, 18 Nov 2008 11:38:17 +0000 (GMT) Received: from delenn.bartv.net (hagrid.vpn.ecoscentric.com [192.168.145.1]) by mail.ecoscentric.com (Postfix) with ESMTP id DF4E83B40069; Tue, 18 Nov 2008 11:38:16 +0000 (GMT) Date: Tue, 18 Nov 2008 11:39:00 -0000 Message-Id: From: Bart Veer To: Jonathan Larmour CC: ecos-devel@ecos.sourceware.org In-reply-to: <49222917.8020407@eCosCentric.com> (message from Jonathan Larmour on Tue, 18 Nov 2008 02:31:51 +0000) Subject: Re: [flashv2 merge] io/flash References: <4922125E.9070308@eCosCentric.com> <49222917.8020407@eCosCentric.com> 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: 2008-11/txt/msg00023.txt.bz2 Switching to ecos-devel: >>>>> "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, but on the other hand there is never going to be a perfect time for that so we can at least have the discussion. Let's start with the current priorities: #define CYG_INIT_HAL 10000 #define CYG_INIT_SCHEDULER 11000 #define CYG_INIT_INTERRUPTS 12000 #define CYG_INIT_DRIVERS 13000 #define CYG_INIT_CLOCK 14000 #define CYG_INIT_IDLE_THREAD 15000 #define CYG_INIT_THREADS 16000 #define CYG_INIT_KERNEL 40000 #define CYG_INIT_MEMALLOC 47000 #define CYG_INIT_IO 49000 #define CYG_INIT_IO_FS 50000 #define CYG_INIT_LIBC 52000 #define CYG_INIT_COMPAT 55000 #define CYG_INIT_APPLICATION 60000 #define CYG_INIT_PREDEFAULT 65534 #define CYG_INIT_DEFAULT 65535 I am not too worried about anything earlier than MEMALLOC. It certainly makes sense to have the kernel fully initialized before anything I/O related so that device drivers can register interrupt handlers, create threads and alarms, malloc() memory, etc. I am also not worried about anything that happens from LIBC onwards. However INIT_IO and INIT_IO_FS are way too restrictive. 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 So we start by initializing the buses, in a hierarchical order. Something like PCI has to be done first because subsequent drivers may need to search for devices. Then comes USB host or similar, possibly on a USB bus, because there may be slave devices hanging off the USB host (although in practice I am not sure how usable a USB host subsystem will be until the scheduler starts running). Finally we come to the simpler buses like I2C and SPI. I am not sure whether CAN fits into this category or whether we should treat it more as a network/char device. Watchdog should probably be next so that if a subsequent device driver init routine hangs the system can recover. Arguably watchdog should happen earlier, right after kernel init, but that would cause problems if you have an external watchdog on a bus rather than an on-chip one. Right now the discussion is moot because watchdog devices are not supposed to start automatically, instead an application call is needed. Doing the wallclock next is harmless and ensures that subsequent operations have an accurate time stamp. Now we come to primary block devices, primarily flash chips. SPI and I2C have been initialized so there is no problem with serial flashes. >From this point on we should have a non-volatile block device capable of holding per-unit settings, so we can imagine an fconfig implementation or replacement that initializes now and provides config settings like MAC addresses to subsequent device drivers. Another round of block devices, this time for things like disks. Configuration data is available if needed. I am not entirely sure about the need for this or about the order within the init sequence. Then character devices, i.e. everything else including ethernet. I am not sure there is any point in providing finer-grained control for these. 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. 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. Or we could be more ambitious and get rid of cyg_flash_init() completely, replacing it with a CYG_INIT_DEV_FLASH constructor. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071.