Some RTEMS Questions
Doyle, Bryon Thomas (Bryon)
bdoyle at lucent.com
Fri Jul 8 16:22:37 UTC 2005
Keith, Thank you for your insight, the problem was with that PPC_USE_SPRG value. However for some bizarre reason on the board that we were working the value was defaulting to zero and still not working. However, we did come across a solution to the problem, Ed Sutter proposed enabling the PPC_USE_SPRG value in both cpu.c and irq_stub.S by adding the following block of code to the beginning of both files:
#define PPC_USE_SPRG 1
Those 2 locations in the RTEMS tree seem to be the only locations that PPC_USE_SPRG is used, and with this modification the timer interrupts work fine. Thanks again for your help.
Summer Intern, Bell Labs
From: Keith Robertson [mailto:kjrobert at alumni.uwaterloo.ca]
Sent: Friday, July 08, 2005 11:15 AM
To: Doyle, Bryon Thomas (Bryon)
Cc: rtems-users at rtems.com
Subject: Re: Some RTEMS Questions
Doyle, Bryon Thomas (Bryon) wrote:
> Chris, Thank you very much for your response. I managed to correct
> the task deletion problem by changing some code around. I made the
> task delete itself after printing out "hello world", instead of the
> rtems_delete(RTEMS_SELF) being called in the Init task, it is called
> in my user_task. The problem that I have now seems to involve the
> Interrupt handler, more specifically the Timer interrupt. I have
> confirmed that the timer values are set properly my using memory
> dumps during the driver initialization. However, RTEMS seems to not
> enter the routine that processes a "tick". It performs an operation
> that results CPU error when the interrupt occurs. I have tried to
> look through the interrupt handlers for the PPC405, but it is in
> assembly and I am hesitant to fiddle around with that level of detail
> in RTEMS. I was wondering if anybody had experienced similar troubles
> with the interrupts in general for a PowerPC 405 or 403? I think
> that the problem lies in some parameter that is n! ot being set
> properly during the configuration of RTEMS, but so far I have not
> been able to find it. Thanks for any help.
Whilst it's difficult to tell without a bit more information about the
CPU error you're experiencing. I have had 'similar' problems with the
gen405 bsp. Can you check if your gen405 bsp is configured with
PPC_USE_SPRG or not? (Look in libbsp/powerpc/gen405/configure.ac for
In my tests the value being loaded from SPRG3 during your first
interrupt was dodgy. SPRG3 was supposed to store the location of
structure containing things like your default/initial MSR settings
(_CPU_IRQ_info I think). This gave a bad value for the structure and
subsequently a bad value for the msr, and things clearly aren't going to
go well from there!
If you set a breakpoint in
__ISR_Handler at about line 58 you can quickly check if this is the case.
Or you can just disable PPC_USE_SPRG and give it a go.
I haven't looked into fixing this as it is a pretty minor optimisation
in the first place (1 instruction, best I can tell) and I have a work
around. However, the place this location should be setup is in cpu.c in
the same directory. A cursory look at that code seems to indicate that
it is doing reasonable things (see line 87 in cpu.c). However, I
haven't investigated any further.
I've attached a patch that changes gen405's configure.ac to not use SPRG
by default. Patch with -p0 from the gen405 directory.
Hope this is helpful. Let us know how you get on.
More information about the users