Re: [ECOS] Redboot-GDB

[Nick Garnett <nickg at ecoscentric dot com>]

"Michael Anburaj" <embeddedeng@hotmail.com> writes:

> Hi Nick/Mark/All,
> 
> 
> >You can test the basic GDB stub entry/exit handling by typing:
> >
> >   $k#6b
> >
> 
> I was about to try this with the redboot build from the current cvs
> source, but Redboot was dying while the context was switched to reach
> trampoline() of redboot\current\src\main.c after receiving Â$Â.
> 
> After much debugging I found that in hal_thread_load_context at the
> last instruction Âmovs    pc,lr the SPSR (with I bit cleared)
> was moved to the CPSR. Thus enabling the IRQs. At this point the
> ECOS-RTC (tick timer) interrupt was pending & because of which the
> flow never reached trampoline(). This may be the reason for my other
> problem too.

Hmm. I has been some time since I last looked at this code, and it has
all changed! I suspect that some of the things I said before may have
been a little bogus. 

> 
> Questions (please let me know, which is right & which is not):
> 1. Is this ok? Can the flow, while switching to trampoline() be
> interrupted? If this is normal, then I need to debug further to find
> why it did not resume after the ECOS-RTC interrupt was serviced.

HAL_THREAD_LOAD_CONTEXT() was really designed for doing thread context
loading (hence the name!) where the state of the interrupt flag is
part of the thread's state. The default for HAL_THREAD_INIT_CONTEXT()
is to arrange for interrupts to be enabled.

As for handling the interrupt. eCos is not running yet. It is still up
to RedBoot to deal with interrupts, expected or otherwise. Maybe the
RedBoot ISR for the timer is not being installed, or is otherwise
failing.

> 2. I believe the ECOS-RTC (tick timer) interrupt got unmasked at
> hal_clock_initialize(). hal_clock_initialize() getting called in
> Redboot at this point; is it normal?

hal_clock_initialize() needs to get called since RedBoot may use the
timer for the microsecond delay function, and may support other timer
based features for stand-alone GCC applications such as profiling.


> 3. hal_clock_initialize() starts the timer & unmasks the interrupt
> (from this point the timer can generate ARM-IRQs, provided the I bit
> in CPSR is low). Is this right? Or should hal_clock_initialize() not
> unmask the timer interrupt.

hal_clock_initialize() shouldn't really unmask the interrupt, that is
usually done elsewhere, in the kernel clock constructor for
example. But the need to have a timer in RedBoot may have changed
that.

> 4. The following lines in hal_thread_load_context of context.s moves
> 0x13 (with I & F bits low):
> ldr     r0,[fp,#armreg_cpsr]
> msr     spsr,r0
> Is this right? Or should the I & F bit be high, disabling the IRQs
> before shifting control to trampoline()?

Maybe the correct thing to do is to initialize this context to have
interrupts disabled by default.

Mark is responsible for most of this stuff, I'm sure he can answer
these questions better than I can.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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