[ECOS] GDB and eCos

[ECOS] GDB and eCos

[andre33]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

    Hello,
    So i'm a newbie

    It seem that GDB can emulate the target !! i'm wrong ?

   So my idea for begining is try to load eCos kernel + hello
application in GDB (emulator mode) without real    target if it's
possible !  for see what is happened !!

    But if it's possible where i need to start !!??
    i have arm-elf-gcc , arm-elf-gdb et eCos builded

    How can i load eCos kernel and the hello application ? and after run
it !

    best regards,

Sébastien.

Re: [ECOS] GDB and eCos

[Bart Veer]

>>>>> "Sebastien" == andre33  <sebastien.andre@sxb.bsf.alcatel.fr> writes:

    Sebastien>     Hello,
    Sebastien>     So i'm a newbie

    Sebastien>     It seem that GDB can emulate the target !! i'm
    Sebastien>     wrong ?

Partly correct.

Typically when gcc is ported to a new architecture, one of the first
steps is to write an instruction set simulator for that architecture.
This allows the compiler folks to do their development and testing
before any hardware exists. It is also very useful for subsequent
maintenance. However, this is just an instruction set simulator. It
will do enough to support compiler testing. It will provide only
minimal I/O facilities which bear no resemblance to how I/O happens on
real hardware. Hence typically it cannot be used for eCos development.
The simulator gets built into gdb when you configure for the
appropriate target.

During the early days of eCos development, the simulators for two of
the initial targets (AM31 and TX39) were enhanced to support
architectural simulation of specific boards, the stdeval1 board and
the JMR-TX3904 board. This architectural simulation included support
for a system clock, serial I/O, and interrupt handling, but not for
anything more advanced like ethernet or PCI. In addition eCos was
ported to the PowerPC psim simulator. More details of these can be
found at http://sources.redhat.com/ecos/hardware.html and in the
Getting Started guides for those targets.

More recent work on architectural simulators within Red Hat has
happened in the context of the SID project, http://sources.redhat.com/sid/
Unfortunately I do not really have time to track that project closely
but I suggest you take a look through their web pages and
documentation.

Bart

Re: [ECOS] GDB and eCos

[andre33]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

Hello,

Thanx for you answer !! so maybe i must start directly with the target
but i'm afraid to be losing with the bootstrap (boot, register init, etc ..)
for beginning :-(
So i will see !!

Thanx again and i will see links you say !!!

best regards,
Sébastien.



Bart Veer wrote:

> >>>>> "Sebastien" == andre33  <sebastien.andre@sxb.bsf.alcatel.fr> writes:
>
>     Sebastien>     Hello,
>     Sebastien>     So i'm a newbie
>
>     Sebastien>     It seem that GDB can emulate the target !! i'm
>     Sebastien>     wrong ?
>
> Partly correct.
>
> Typically when gcc is ported to a new architecture, one of the first
> steps is to write an instruction set simulator for that architecture.
> This allows the compiler folks to do their development and testing
> before any hardware exists. It is also very useful for subsequent
> maintenance. However, this is just an instruction set simulator. It
> will do enough to support compiler testing. It will provide only
> minimal I/O facilities which bear no resemblance to how I/O happens on
> real hardware. Hence typically it cannot be used for eCos development.
> The simulator gets built into gdb when you configure for the
> appropriate target.
>
> During the early days of eCos development, the simulators for two of
> the initial targets (AM31 and TX39) were enhanced to support
> architectural simulation of specific boards, the stdeval1 board and
> the JMR-TX3904 board. This architectural simulation included support
> for a system clock, serial I/O, and interrupt handling, but not for
> anything more advanced like ethernet or PCI. In addition eCos was
> ported to the PowerPC psim simulator. More details of these can be
> found at http://sources.redhat.com/ecos/hardware.html and in the
> Getting Started guides for those targets.
>
> More recent work on architectural simulators within Red Hat has
> happened in the context of the SID project, http://sources.redhat.com/sid/
> Unfortunately I do not really have time to track that project closely
> but I suggest you take a look through their web pages and
> documentation.
>
> Bart

[ECOS] cyg_semaphore_post

[Joerg Rapka]

Hi

Is it allowed to call cyg_semaphore_post from within an ISR?

Thanks,
Joerg

Re: [ECOS] cyg_semaphore_post

[Bart Veer]

>>>>> "Joerg" == Joerg Rapka <joerg.rapka@duagon.com> writes:

    Joerg> Is it allowed to call cyg_semaphore_post from within an
    Joerg> ISR?

No. In general it is not possible to call any kernel function from
inside an ISR because kernel operations like manipulating a semaphore
only lock the scheduler, they do not disable interrupts. This helps to
keep down the interrupt latency. Instead the ISR should indicate that
its corresponding DSR should be run, using its return value. The DSR
will be run when it is safe to do so. Usually this will be
immediately, but if the interrupted code was in a critical section and
had locked the scheduler then the DSR will be run a little bit later
when the critical section has been exited. The DSR can make
non-blocking calls such as cyg_semaphore_post()

For more information, see e.g. the section "eCos Interrupt Model" in
the Reference Guide.

Bart

Re: [ECOS] cyg_semaphore_post

[harri.siirtola]

At 16:44 13.6.2001 +0200, Joerg Rapka wrote:
>Hi
>
>Is it allowed to call cyg_semaphore_post from within an ISR?

Calling from a DSR is better and it works. I'm using it all the time.

>
>Thanks,
>Joerg

Good luck,
	Harri

[ECOS] cyg_semaphore_post

[Stijn Symons]

Will the cyg_semaphore_post function still increment the count if there
are threads waiting on it, or does it only wake up a thread?
And witch thread does it wake up, the one with the highest priority or
just random?

thanks,

Stijn Symons


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

Re: [ECOS] cyg_semaphore_post

[Andrew Lunn]

On Mon, Feb 11, 2002 at 12:58:04PM +0100, Stijn Symons wrote:
> Will the cyg_semaphore_post function still increment the count if there
> are threads waiting on it, or does it only wake up a thread?
> And witch thread does it wake up, the one with the highest priority or
> just random?

The documentation says:

"If there are threads waiting on this semaphore this will make exactly
one of then. Otherwise it simply increments the semaphore count".

So that answers 1/2 of your question. 

Reading the code, it looks like post takes from the head of the
queue. It does not look like the queue is prioritized.

Thinking about it, i'm not sure priorities make sense. Could you
explain what you mean and how you would use them.

       Andrew

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

Re: [ECOS] cyg_semaphore_post

[Stijn Symons]

> The documentation says:
>
> "If there are threads waiting on this semaphore this will make exactly
> one of then. Otherwise it simply increments the semaphore count".
>
> So that answers 1/2 of your question.
>
>

Indeed, I'll read more carefull the next time ;-)


>
> Reading the code, it looks like post takes from the head of the
> queue. It does not look like the queue is prioritized.
>
> Thinking about it, i'm not sure priorities make sense. Could you
> explain what you mean and how you would use them.
>
>        Andrew

I'm mapping an API to eCos, the API states that  "When any threads are
waiting on the semaphore count to become higher than zero, the thread with
the highest priority will be woken up to acquire the semaphore".

Stijn


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

Re: [ECOS] cyg_semaphore_post

[Robin Farine]

On Mon, 2002-02-11 at 13:38, Stijn Symons wrote:

[snip]

> I'm mapping an API to eCos, the API states that  "When any threads are
> waiting on the semaphore count to become higher than zero, the thread with
> the highest priority will be woken up to acquire the semaphore".

... which in cases of heavy load of the semaphore will lead to
starvation of low priority threads :-\

> 
> Stijn

Robin



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

Re: [ECOS] cyg_semaphore_post

[Chris Gray]

Robin Farine wrote:

> On Mon, 2002-02-11 at 13:38, Stijn Symons wrote:
>
> [snip]
>
> > I'm mapping an API to eCos, the API states that  "When any threads are
> > waiting on the semaphore count to become higher than zero, the thread with
> > the highest priority will be woken up to acquire the semaphore".
>
> ... which in cases of heavy load of the semaphore will lead to
> starvation of low priority threads :-\

Then don't do that. ;>

If eCos were a `hard' real-time OS, it probably would behave the way that Stijn

describes, and if starvation resulted that would be down to programming error.
The `hard' real-timers would care only that the starvation was predictable. ;>

Of course eCos isn't `hard' real-time, so eCos semaphores will not deliver the
behaviour described in Stijn's API.

Chris Gray
VM Architect, ACUNIA



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

Re: [ECOS] cyg_semaphore_post

[Nick Garnett]

Robin Farine <robin.farine@acn-group.ch> writes:

> On Mon, 2002-02-11 at 13:38, Stijn Symons wrote:
> 
> [snip]
> 
> > I'm mapping an API to eCos, the API states that  "When any threads are
> > waiting on the semaphore count to become higher than zero, the thread with
> > the highest priority will be woken up to acquire the semaphore".
> 
> .. which in cases of heavy load of the semaphore will lead to
> starvation of low priority threads :-\
> 

Indeed.

However there is the CYGIMP_KERNEL_SCHED_SORTED_QUEUES option that
allows all thread queues to be sorted. This was added primarily to
support POSIX, but you can enable it yourself if you want.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

Re: [ECOS] cyg_semaphore_post

[Robin Farine]

On Mon, 2002-02-11 at 14:58, Nick Garnett wrote:

[snip]
 
> However there is the CYGIMP_KERNEL_SCHED_SORTED_QUEUES option that
> allows all thread queues to be sorted. This was added primarily to
> support POSIX, but you can enable it yourself if you want.

Does the pthreads standard explicitely specify to enqueue threads in
priority order (sorry, I don't have this paper)? How to avoid starvation
then?

Robin



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

Re: [ECOS] cyg_semaphore_post

[Nick Garnett]

Robin Farine <robin.farine@acn-group.ch> writes:

> On Mon, 2002-02-11 at 14:58, Nick Garnett wrote:
> 
> [snip]
>  
> > However there is the CYGIMP_KERNEL_SCHED_SORTED_QUEUES option that
> > allows all thread queues to be sorted. This was added primarily to
> > support POSIX, but you can enable it yourself if you want.
> 
> Does the pthreads standard explicitely specify to enqueue threads in
> priority order (sorry, I don't have this paper)? How to avoid starvation
> then?
> 

It certainly requires this for semaphores if
{_POSIX_PRIORITY_SCHEDULING} is defined. It is less clear on what
should happen in mutexes, but if priority inheritance is going to mean
anything then the highest priority waiting thread must get the mutex
when it is unlocked.

As for starvation. I suspect that in real-life systems this is largely
a theoretical problem. If you really have high priority threads
hammering on a mutex at such a rate that waiting low priority threads
cannot get a look-in, you are already overloaded. The only solution is
to rewrite the application to reduce the amount of contention for this
resource.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


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

Re: [ECOS] cyg_semaphore_post

[Robin Farine]

On Fri, 2002-02-15 at 12:39, Nick Garnett wrote:

[snip]

> As for starvation. I suspect that in real-life systems this is largely
> a theoretical problem. If you really have high priority threads
> hammering on a mutex at such a rate that waiting low priority threads
> cannot get a look-in, you are already overloaded. The only solution is
> to rewrite the application to reduce the amount of contention for this
> resource.

This seems a sensible argument, thanks for the clarification.

Robin



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

RE: [ECOS] cyg_semaphore_post

[Woller, Thomas]

we are also wondering how to handle the non-priority based (ie.
FIFO based) waiting under eCos. when there are a series of
threads waiting on the same semaphore, we basically want the
highest priority thread to run, NOT the first one that happened
to wait on the semaphore.  some of our current s/w on another
RTOS that we are porting over currently supports both FIFO and
priority based semaphores/mutexes. so we think that core
modifications are the only option we have. we could just allow
the lower priority threads, that are first on the FIFO, to cycle
out with context switches at the most every system tick. not sure
if this is going to be too much latency for the higher priority
thread though, we'll have to test and see.
tom


[snip]

> I'm mapping an API to eCos, the API states that  "When any
threads are
> waiting on the semaphore count to become higher than zero, the
thread with
> the highest priority will be woken up to acquire the
semaphore".

... which in cases of heavy load of the semaphore will lead to
starvation of low priority threads :-\

> 
> Stijn

Robin



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

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

Re: [ECOS] cyg_semaphore_post

[Andrew Lunn]

On Mon, Feb 11, 2002 at 09:10:16AM -0600, Woller, Thomas wrote:
> When there are a series of
> threads waiting on the same semaphore, we basically want the
> highest priority thread to run, NOT the first one that happened
> to wait on the semaphore.

OK. You use this sort of Semaphore. You should be able to answer my
question... to me it still does not make sense. Why do you want
prioritization on what gets woken up? Please can you give an
example...

        Andrew

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

RE: [ECOS] cyg_semaphore_post

[Robin Farine]

On Mon, 2002-02-11 at 16:10, Woller, Thomas wrote:
> we are also wondering how to handle the non-priority based (ie.
> FIFO based) waiting under eCos. when there are a series of
> threads waiting on the same semaphore, we basically want the
> highest priority thread to run, NOT the first one that happened
> to wait on the semaphore.  some of our current s/w on another
> RTOS that we are porting over currently supports both FIFO and
> priority based semaphores/mutexes. so we think that core
> modifications are the only option we have. we could just allow
> the lower priority threads, that are first on the FIFO, to cycle
> out with context switches at the most every system tick. not sure
> if this is going to be too much latency for the higher priority
> thread though, we'll have to test and see.
> tom
> 

You might try a mutex, a condition variable and an appropriate priority
inversion protection protocol instead of a counting semaphore.

[snip]

Robin



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

Re: [ECOS] cyg_semaphore_post

[Jonathan Larmour]

"Woller, Thomas" wrote:
> 
> we are also wondering how to handle the non-priority based (ie.
> FIFO based) waiting under eCos. when there are a series of
> threads waiting on the same semaphore, we basically want the
> highest priority thread to run, NOT the first one that happened
> to wait on the semaphore.  some of our current s/w on another
> RTOS that we are porting over currently supports both FIFO and
> priority based semaphores/mutexes.

You should be able to get this behaviour using the
CYGIMP_KERNEL_SCHED_SORTED_QUEUES option. With this option enabled (it is
by default disabled), thread queues (as used to queue threads waiting for
semaphores) are sorted in thread priority order.

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

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

RE: [ECOS] cyg_semaphore_post

[Woller, Thomas]

The question about a specific example made me go back and ask the
core s/w team what specific implementation they were looking for
with this priority based wakeup scheme.  we are rewriting some of
the code as well as porting.  
basically, the current s/w does not use multiple priorities, but
their plan is to have "task rendezvous" events in which a
particular event needs to occur before a series of threads must
run each with their associated functionality. the threads don't
depend on each other (just that an event occurred) but have
definite priorities among themselves.  an example might be when a
STOP or REVERSE command occurs with a DVD player.  a series of
internal threads must cleanup now that PLAY is no longer the
state, and the Video is the highest priority, with audio coming
next and then so on.
that's all i can give as an example right now, but perhaps we
don't need this functionality when we get further down the design
and implementation phases.  and perhaps the mutex as robin
indicated might be sufficient. thanks for all the information,
and i'll give more specific info when i have the example.
Tom



>You might try a mutex, a condition variable and an appropriate
priority
>inversion protection protocol instead of a counting semaphore.

[snip]

Robin


On Mon, Feb 11, 2002 at 09:10:16AM -0600, Woller, Thomas wrote:
> When there are a series of
> threads waiting on the same semaphore, we basically want the
> highest priority thread to run, NOT the first one that happened
> to wait on the semaphore.

OK. You use this sort of Semaphore. You should be able to answer
my
question... to me it still does not make sense. Why do you want
prioritization on what gets woken up? Please can you give an
example...

        Andrew

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