Re: [ECOS] Mutex & Asserts during initialisation

[Nick Garnett <nickg at ecoscentric dot com>]

"Paul D. DeRocco" <pderocco@ix.netcom.com> 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