[ECOS] ref to previous question-'calling path questions, thanks'

[Qiang Huang]

Thanks gary. But whenever IRQ/FIQ/SWI/other exception occurs ecos operating 
mode will be switched from supervisor mode to IRQ/FIQ... mode afterward mode 
will be switched back to supervisor mode ASAP, but I have seen some code 
which perform saving pre-exception mode registers and the routine 
return_from_exception also determine which mode to switched back to 
(supervisor mode/other non-user modes) before returning back from this 
routine. So what happens?
How to grasp the last few statement in return_from_exception routine which 
will determine the operating mode to switch back to? Thanks a lot for your 
help.

Best regards,


>From: Gary Thomas <gary@mlbassoc.com>
>To: Qiang Huang <jameshq@hotmail.com>
>CC: ecos-discuss@sourceware.org
>Subject: Re: [ECOS] ref to previous question-'calling path questions, 
>thanks'
>Date: Mon, 02 Oct 2006 09:51:30 -0600
>
>Qiang Huang wrote:
>>Thanks a lot for your help Bart.
>>
>>But inside IRQ (vector.s) what does pre-exception mode points to? (Is that 
>>always supervisor mode prior to entering IRQ mode? (if it is supervisor 
>>mode for pre-exception mode, what is difference between saving 
>>pre-exception mode context and what will be saved later on in 
>>hal_switch_context function?)
>
>eCos on the ARM runs only in supervisor mode.
>
>>
>>>From: Bart Veer <bartv@ecoscentric.com>
>>>To: jameshq@hotmail.com
>>>CC: ecos-discuss@sourceware.org
>>>Subject: Re: [ECOS] ref to previous question-'calling path questions, 
>>>thanks'
>>>Date: 01 Oct 2006 16:59:13 +0100
>>>
>>> >>>>> " " == Qiang Huang <jameshq@hotmail.com> writes:
>>>
>>>      > Hi eCOS experts:
>>>      >    Maybe my previous question
>>>      > 
>>>(http://ecos.sourceware.org/ml/ecos-discuss/2006-09/msg00231.html) is a
>>>      > little confusing, what it really means is the followings:
>>>
>>>      > (ARM target)
>>>      > Two thread #1 and #2 exist in system
>>>
>>>      > (1) Thread #1 runs first
>>>      > (2) Thread #1 issues SWI instruction
>>>      > (3) Enter SWI ISR and run on thread #1 stack (svc mode)
>>>      > (4) At the time IRQ occurs and preempts SWI ISR
>>>      > (5) Switch SVC and run on thread #1 stack (svc mode)
>>>      > (6) Eventually comes to interrupt_end() and unlock_inner(), which 
>>>will cause
>>>      > a context switching
>>>      > (7) Thread #2 context is loadded and return with thread #2 
>>>running
>>>
>>>      > Here seems SWI is preempted by thread #2? Is this correct?
>>>      > (shouldn't all ISR be finished before any thread has the chance 
>>>to run?)
>>>
>>>      > Hope someone can give me some hint, that would be very
>>>      > thankful.
>>>
>>>eCos does not use SWI's. The main purpose of the SWI instruction is to
>>>provide a controlled mechanism for switching between user mode and
>>>supervisor mode, but eCos applications always run in supervisor mode
>>>so there is no need for a switch. If for some obscure reason an
>>>application does execute a SWI instruction the resulting system
>>>behaviour is basically undefined.
>
>
>--
>------------------------------------------------------------
>Gary Thomas                 |  Consulting for the
>MLB Associates              |    Embedded world
>------------------------------------------------------------

_________________________________________________________________
Windows Live™ Messenger has arrived. Click here to download it for free! 
http://imagine-msn.com/messenger/launch80/?locale=en-gb


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