From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15199 invoked by alias); 18 Nov 2008 17:22:24 -0000 Received: (qmail 15164 invoked by uid 22791); 18 Nov 2008 17:22:22 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,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 17:21:32 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 971333B40070; Tue, 18 Nov 2008 17:21:29 +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 tI-kgct6wYf8; Tue, 18 Nov 2008 17:21:28 +0000 (GMT) Message-ID: <4922F997.8010408@eCosCentric.com> Date: Tue, 18 Nov 2008 17:22: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@ecos.sourceware.org Subject: Re: [flashv2 merge] io/flash References: <4922125E.9070308@eCosCentric.com> <49222917.8020407@eCosCentric.com> <4922E622.5070906@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/msg00004.txt.bz2 Bart Veer wrote: >>>>>> "Jifl" == Jonathan Larmour writes: > > > > >> 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 > Jifl> [big snip] > > Jifl> I think this is all absolutely fine. > > Actually, it is wrong in at least one place. I remember one board > where the CAN interface was hanging off an SPI bus instead of being > on-chip. That implies CAN should be treated as a network device, not a > bus, and should init at CYG_INIT_DEV_CHAR. > > Everybody, please think carefully about any funny boards you have come > across over the years, and whether or not the above order makes sense. Of course the purpose of having these numbers abstracted is that if we do need to, it can be tweaked. > >> 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. > > Jifl> It's certainly plausible to want to read config data from an > Jifl> FS, IMHO. But CYG_INIT_MEMALLOC seems unnecessarily early > Jifl> and would probably cause more problems than it solves. > > I am not sure I agree with that. MEMALLOC should only involve main > memory, with no need to worry about whether or not any of the I/O > subsystem is available yet. Initializing MEMALLOC early means that > device drivers could perform run-time detection and dynamically > allocate any buffers required, instead of statically allocating for > the worst case. I thought you were saying the order would be CYG_INIT_MEMALLOC, CYG_INIT_IO_FS and then the rest of the CYG_INIT_IO*. I don't have any issue with MEMALLOC being first, but wouldn't have thought that CYG_INIT_IO_FS being before CYG_INIT_IO* would work well. Were you saying something differnt perhaps? > On the other hand, some drivers for e.g. framebuffer devices may need > to mess about with the memory map and lower memtop. Although really > that kind of thing should be handled at the platform linker script > level, not at run-time. > > I suspect that in the long term we'll be happier initializing memalloc > early on. I agree, and didn't disagree :-). 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