[ECOS] Mutex & Asserts during initialisation

[ECOS] Mutex & Asserts during initialisation

[Will Wagner]

Hi All,

I am trying to run with asserts on to test a couple of things. However 
there seems to be a problem with the mutex check_this function has been 
implemented.

If anything tries to lock a mutex before the scheduler has been started 
then an assert goes off. This is because when locking the mutex 
Cyg_Thread::self() returns NULL. So in the check this function locked is 
true but owner is NULL so it fails.

This means that you can't use SPI or i2c before the scheduler starts. If 
you have any driver that is initialised via static constructor that uses 
either of those then the system asserts. An example of this would be the 
DS1307 wallclock.

How has anyone worked around this in the past?

Thanks,

Will


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Mutex & Asserts during initialisation

[Andrew Lunn]

On Fri, Jul 08, 2005 at 01:17:47PM +0100, Will Wagner wrote:
> Hi All,
> 
> I am trying to run with asserts on to test a couple of things. However 
> there seems to be a problem with the mutex check_this function has been 
> implemented.
> 
> If anything tries to lock a mutex before the scheduler has been started 
> then an assert goes off. This is because when locking the mutex 
> Cyg_Thread::self() returns NULL. So in the check this function locked is 
> true but owner is NULL so it fails.
> 
> This means that you can't use SPI or i2c before the scheduler starts. If 
> you have any driver that is initialised via static constructor that uses 
> either of those then the system asserts. An example of this would be the 
> DS1307 wallclock.
> 
> How has anyone worked around this in the past?

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 think the solution for you is to also start the schedular in a
static constructor. Just give it a higher priority than anything that
needs the schedular enabled.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Mutex & Asserts during initialisation

[Will Wagner]

Thanks Andrew.

Will try that.

The issue with SPI and i2c is that all the functions ensure only 1 
thread can access the buses at once and hence the lock. Before the 
scheduler is started there is no possibility of another thread running 
and so no need to lock the mutex. However the generic functions don't 
test for this case.

Will

Andrew Lunn wrote:
> On Fri, Jul 08, 2005 at 01:17:47PM +0100, Will Wagner wrote:
> 
>>Hi All,
>>
>>I am trying to run with asserts on to test a couple of things. However 
>>there seems to be a problem with the mutex check_this function has been 
>>implemented.
>>
>>If anything tries to lock a mutex before the scheduler has been started 
>>then an assert goes off. This is because when locking the mutex 
>>Cyg_Thread::self() returns NULL. So in the check this function locked is 
>>true but owner is NULL so it fails.
>>
>>This means that you can't use SPI or i2c before the scheduler starts. If 
>>you have any driver that is initialised via static constructor that uses 
>>either of those then the system asserts. An example of this would be the 
>>DS1307 wallclock.
>>
>>How has anyone worked around this in the past?
> 
> 
> 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 think the solution for you is to also start the schedular in a
> static constructor. Just give it a higher priority than anything that
> needs the schedular enabled.
> 
>         Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Mutex & Asserts during initialisation

[Paul D. DeRocco]

> 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.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Mutex & Asserts during initialisation

[Fabian Scheler]

Hi,

> > 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!

well, this is a reasonable solution,

> 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.

while this is not. You better should design your driver properly, so
it can cooperate with the operating system, the driver is developed
for, not vice versa. Within a clean layered software design it just
means to add one more layer to make your driver thread safe! During
startup you can still use a layer where no thread synchronization is
necessary. You can add this new layer with the help of C++
inline-functions in a very efficient manner, for example. Another
possibility is to use AOP for this purpose, compare "Using AOP to
Develop Archtiecture-Neutral Operating System Components"
(Spinczyk+Lohmann), for instance.

Ciao, Fabian

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Mutex & Asserts during initialisation

[Nick Garnett]

"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

[ECOS] issues: memcpy in flash_config_insert_value & exec -r

[Michael Anburaj]

Hi,

H/w : MIPS atlas, 4Kc
Build: Redboot_ROM
source: latest from CVS

Issue #1: memcpy in flash_config_insert_value (fconfig.c), case CONFIG_ESA 
throws an exception (I guess) casues Redboot to hang-up (with GDB command 
$T0b25...)

dp = 0x80fbf016
&opt-dflt = 0x800010bc
size = 6

Other cases work fine:

case CONFIG_BOOL:
dp = 0x80fbf02e
&opt-dflt = 0x800010d4
size = 4

Let me know the reason behind this. For now, I have bypassed this by 
commenting out the memcpy for the CONFIG_ESA case.

Issue #2:
The redboot command "exec" is supposed to have -r option for RamDisk, but in 
my Redboot build I don't see this option. Let me know if I need to included 
some packages for this or enable some option in Redboot config.

Thanks a lot,
-Mike.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] SOS: [ECOS] issues: memcpy in flash_config_insert_value & exec -r

[Michael Anburaj]

Can someone help me please!

Thanks,
-Mike.

>From: "Michael Anburaj" <embeddedeng@hotmail.com>
>To: ecos-discuss@ecos.sourceware.org
>Subject: [ECOS] issues: memcpy in flash_config_insert_value & exec -r
>Date: Mon, 11 Jul 2005 10:30:16 +0000
>
>Hi,
>
>H/w : MIPS atlas, 4Kc
>Build: Redboot_ROM
>source: latest from CVS
>
>Issue #1: memcpy in flash_config_insert_value (fconfig.c), case CONFIG_ESA 
>throws an exception (I guess) casues Redboot to hang-up (with GDB command 
>$T0b25...)
>
>dp = 0x80fbf016
>&opt-dflt = 0x800010bc
>size = 6
>
>Other cases work fine:
>
>case CONFIG_BOOL:
>dp = 0x80fbf02e
>&opt-dflt = 0x800010d4
>size = 4
>
>Let me know the reason behind this. For now, I have bypassed this by 
>commenting out the memcpy for the CONFIG_ESA case.
>
>Issue #2:
>The redboot command "exec" is supposed to have -r option for RamDisk, but 
>in my Redboot build I don't see this option. Let me know if I need to 
>included some packages for this or enable some option in Redboot config.
>
>Thanks a lot,
>-Mike.
>
>
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] SOS: [ECOS] issues: memcpy in flash_config_insert_value & exec -r

[Gary Thomas]

On Tue, 2005-07-12 at 01:22 +0000, Michael Anburaj wrote:
> Can someone help me please!
> 
> Thanks,
> -Mike.
> 
> >From: "Michael Anburaj" <embeddedeng@hotmail.com>
> >To: ecos-discuss@ecos.sourceware.org
> >Subject: [ECOS] issues: memcpy in flash_config_insert_value & exec -r
> >Date: Mon, 11 Jul 2005 10:30:16 +0000
> >
> >Hi,
> >
> >H/w : MIPS atlas, 4Kc
> >Build: Redboot_ROM
> >source: latest from CVS
> >
> >Issue #1: memcpy in flash_config_insert_value (fconfig.c), case CONFIG_ESA 
> >throws an exception (I guess) casues Redboot to hang-up (with GDB command 
> >$T0b25...)
> >
> >dp = 0x80fbf016
> >&opt-dflt = 0x800010bc
> >size = 6
> >
> >Other cases work fine:
> >
> >case CONFIG_BOOL:
> >dp = 0x80fbf02e
> >&opt-dflt = 0x800010d4
> >size = 4
> >
> >Let me know the reason behind this. For now, I have bypassed this by 
> >commenting out the memcpy for the CONFIG_ESA case.
> >

Try looking carefully at how the flash_config structures are set up in
the ethernet driver you are using.   The way RedBoot handles CONFIG_ESA
data changed (about 2 years ago) and I suspect that this driver was not
updated.

> >Issue #2:
> >The redboot command "exec" is supposed to have -r option for RamDisk, but 
> >in my Redboot build I don't see this option. Let me know if I need to 
> >included some packages for this or enable some option in Redboot config.

There does not seem to be any support for ramdisks in the MIPS HAL.
What makes you think this option is supported?

n.b. the 'exec' command is highly HAL/target specific.  Not all options
are available for all targets, etc.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Mutex & Asserts during initialisation

[Bart Veer]

>>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes:

    <snip>

    >> 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.

    Nick> And this is exactly what happens. The kernel installs the
    Nick> idle thread as the current thread as soon as it is
    Nick> initialized so that mutexes and semaphores will operate
    Nick> correctly before the scheduler starts.

    Nick> However, device drivers are usually initialized before this
    Nick> point, on the assumption that the hardware should be
    Nick> initialized as early as possible. Wallclock devices are
    Nick> initialized a little later, but still before the idle
    Nick> thread.

    Nick> The driver initialization priority was set long before these
    Nick> layered I2C and SPI drivers were introduced. These are a
    Nick> fairly new feature, and there are clearly a few teething
    Nick> troubles.

    Nick> I suspect that the correct fix for this problem is to move
    Nick> the initialization of the DS1307 to after the idle thread in
    Nick> initialized. The simplest way of doing this is to make all
    Nick> wallclock devices use CYG_INIT_IO priority.

I agree this is the right short-term solution.

In the medium or long term we may want to rethink the predefined
constructor priorities. The current order is not necessarily optimal,
and I would like to see a few more categories. It is a hard problem
with lots of potential for circular dependencies and destabilizing
existing systems, so I need to think about it for a while before
coming up with a proposal.

Bart

-- 
Bart Veer                       eCos Configuration 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