From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11021 invoked by alias); 11 Jul 2005 09:36:24 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 10907 invoked by uid 22791); 11 Jul 2005 09:36:17 -0000 Received: from anchor-post-35.mail.demon.net (HELO anchor-post-35.mail.demon.net) (194.217.242.85) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 11 Jul 2005 09:36:17 +0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1DrtOX-0001oW-Gk; Mon, 11 Jul 2005 08:12:05 +0000 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 82C322B554; Mon, 11 Jul 2005 09:16:21 +0100 (BST) To: "Paul D. DeRocco" Cc: "eCos Discuss" References: From: Nick Garnett Original-Sender: nickg@ecoscentric.com Date: Mon, 11 Jul 2005 09:36:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] Mutex & Asserts during initialisation X-SW-Source: 2005-07/txt/msg00102.txt.bz2 "Paul D. DeRocco" writes: > > From: Andrew Lunn > > > > Humm, i think this is reasonable behaviour. Anything that tries to use > > a mutex must assume it can block. Otherwise why are you using a mutex! > > I can see the other side of this. You want to write a driver that can work > in a multi-threaded environment, so you include a mutex in it. But then you > want to call it from startup code. Rather than write a second specialized > non-multi-threaded driver, or include some sort of flag that tells it to > skip the locking and unlocking, it's much cleaner to simply consider the > attempt to lock a mutex before the threading system has been initialized a > harmless null operation. And this is exactly what happens. The kernel installs the idle thread as the current thread as soon as it is initialized so that mutexes and semaphores will operate correctly before the scheduler starts. However, device drivers are usually initialized before this point, on the assumption that the hardware should be initialized as early as possible. Wallclock devices are initialized a little later, but still before the idle thread. The driver initialization priority was set long before these layered I2C and SPI drivers were introduced. These are a fairly new feature, and there are clearly a few teething troubles. I suspect that the correct fix for this problem is to move the initialization of the DS1307 to after the idle thread in initialized. The simplest way of doing this is to make all wallclock devices use CYG_INIT_IO priority. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss