[ECOS] please help me

[ECOS] please help me

[A Shobhan]

Hi,

I have a multi threaded program consists of just two threads on ARM =
7TDMI SOC target. The program is running fine if the eCos is built with =
"Bitmap Scheduler" option, I am able to create Mutex and =
cyg_thread_delay() is also working fine. If I use "Multi Level Scheduler =
with Time Slicing Enabled" option the program is hanging at =
cyg_mutex_init() and no thread is working. The cyg_thread_delay() is =
also hanging.=20

Why the cyg_mutex_init() is hanging in Multi level scheduler and not in =
Bitmap scheduler?
Why cyg_thread_delay() is hanging in Multi level scheduler and not in =
Bitmap scheduler?

Please help.

Thanks in advance...

Shobhan

Re: [ECOS] please help me

[Jonathan Larmour]

A Shobhan wrote:
> 
> Hi,
> 
> I have a multi threaded program consists of just two threads on ARM =
> 7TDMI SOC target. The program is running fine if the eCos is built with =
> "Bitmap Scheduler" option, I am able to create Mutex and =
> cyg_thread_delay() is also working fine. If I use "Multi Level Scheduler =
> with Time Slicing Enabled" option the program is hanging at =
> cyg_mutex_init() and no thread is working. The cyg_thread_delay() is =
> also hanging.=20
> 
> Why the cyg_mutex_init() is hanging in Multi level scheduler and not in =
> Bitmap scheduler?
> Why cyg_thread_delay() is hanging in Multi level scheduler and not in =
> Bitmap scheduler?

You've probably made some assumption somewhere that you wouldn't get
timesliced. But without seeing the program, we can't tell for sure!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] please help me

[A Shobhan]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

hi
  iam here with attaching the file hello.c.  This code is working with
bitmap scheduler, but hanging if the eCos is build with multilevel
scheduler.

thanks


----- Original Message -----
From: "Jonathan Larmour" <jlarmour@redhat.com>
To: "A Shobhan" <shobana@in.ceeyes.com>
Cc: <ecos-discuss@sourceware.cygnus.com>
Sent: Friday, August 03, 2001 6:00 PM
Subject: Re: [ECOS] please help me


> A Shobhan wrote:
> >
> > Hi,
> >
> > I have a multi threaded program consists of just two threads on ARM =
> > 7TDMI SOC target. The program is running fine if the eCos is built with
=
> > "Bitmap Scheduler" option, I am able to create Mutex and =
> > cyg_thread_delay() is also working fine. If I use "Multi Level Scheduler
=
> > with Time Slicing Enabled" option the program is hanging at =
> > cyg_mutex_init() and no thread is working. The cyg_thread_delay() is =
> > also hanging.=20
> >
> > Why the cyg_mutex_init() is hanging in Multi level scheduler and not in
=
> > Bitmap scheduler?
> > Why cyg_thread_delay() is hanging in Multi level scheduler and not in =
> > Bitmap scheduler?
>
> You've probably made some assumption somewhere that you wouldn't get
> timesliced. But without seeing the program, we can't tell for sure!
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
>

[-- Attachment #2: hello.c --]
[-- Type: text/x-c, Size: 1659 bytes --]

/* this is a simple hello world program */
#include <stdio.h>
#include <cyg/kernel/kapi.h>


/* now declare (and allocate space for) some kernel objects,
   like the two threads we will use */
cyg_thread thread_s[3];		/* space for two thread objects */

char stack[3][4096];		/* space for two 4K stacks */

/* now the handles for the threads */
cyg_handle_t simple_threadA, simple_threadB, simple_threadC;

/* and now variables for the procedure which is the thread */
cyg_thread_entry_t simple_program;

/* and now a mutex to protect calls to the C library */
cyg_mutex_t cliblock;


void cyg_user_start(void)
{


  cyg_mutex_init(&cliblock);

  cyg_thread_create(4, simple_program, (cyg_addrword_t) 0,
		    "Thread A", (void *) stack[0], 4096,
		    &simple_threadA, &thread_s[0]);
  cyg_thread_create(4, simple_program, (cyg_addrword_t) 1,
		    "Thread B", (void *) stack[1], 4096,
		    &simple_threadB, &thread_s[1]);

  cyg_thread_create(4, simple_program, (cyg_addrword_t) 2,
		    "Thread C", (void *) stack[2], 4096,
		    &simple_threadC, &thread_s[2]);

  cyg_thread_resume(simple_threadB);
  cyg_thread_resume(simple_threadC);
  cyg_thread_resume(simple_threadA);
	displayString("\r\nCalling Scheduler.... \r\n");

}

extern cyg_uint32 tick_count;
void simple_program(cyg_addrword_t data)
{
	int message = (int) data;
	int delay;
	
	//cyg_thread_delay(10);
	while(1)
	{
	
		cyg_mutex_lock(&cliblock);
		//cyg_scheduler_lock();
		diag_printf("Beginning execution; thread data is %d\r\n", data );
		cyg_mutex_unlock(&cliblock);
		//cyg_scheduler_unlock();
		//CYGACC_CALL_IF_DELAY_US(1000);
		cyg_thread_delay(100);
		//cyg_thread_yield();
	}
	
}

Re: [ECOS] please help me

[Jonathan Larmour]

A Shobhan wrote:
> 
> hi
>   iam here with attaching the file hello.c.  This code is working with
> bitmap scheduler, but hanging if the eCos is build with multilevel
> scheduler.

Works fine for me:

murgh:~/ecc/obj/i386/linux$ ./foo
Beginning execution; thread data is 1
Beginning execution; thread data is 2
Beginning execution; thread data is 0
Beginning execution; thread data is 1
Beginning execution; thread data is 2
Beginning execution; thread data is 0
Beginning execution; thread data is 1
Beginning execution; thread data is 2


Perhaps you changed something else in your configuration. One trick I use
is to use "ecosconfig export" on a configuration to see what values are set
other than to their default.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] mips_rm7000.ld and dwarf

[Chris Morrow]

Gdb (version 5.0) does not find any debugging symbols when
attaching to an image produced with mips_rm7000.ld. If I copy
debugging section stuff from the v1.3.1 linker script and remove
the new stuff, gdb does find debugging symbols.

My guess is that a -gdwarf or one of the similar flags should
be passed to gcc instead of just -g. I'm using gcc 2.96 and
binutils  version 010326 (with BFD 010326)

Is this correct?


Also how is gcc v3.0 working out?

-- 
Chris Morrow	YottaYotta Inc. email: cmorrow@yottayotta.com
phone: (780) 989 6814 web:	http:  //www.yottayotta.com

Re: [ECOS] mips_rm7000.ld and dwarf

[Jonathan Larmour]

Chris Morrow wrote:
> 
> Gdb (version 5.0) does not find any debugging symbols when
> attaching to an image produced with mips_rm7000.ld. If I copy
> debugging section stuff from the v1.3.1 linker script and remove
> the new stuff, gdb does find debugging symbols.
> 
> My guess is that a -gdwarf or one of the similar flags should
> be passed to gcc instead of just -g. I'm using gcc 2.96 and
> binutils  version 010326 (with BFD 010326)
> 
> Is this correct?

Or that debug info is broken in the tools you are using :-). What target
triple are you using for the tools? 

If you have a particular patch that you can verify works for you, we could
try it. Note that -gdwarf wouldn't be advisable because dwarf 1 has lousy
support for C++ debugging. -gdwarf-2 would be better, if that helps.

> Also how is gcc v3.0 working out?

I haven't reached any mips tools yet. I'm still testing the x86 due to some
internal difficulties.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine