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:


#ifdef PPC_USE_SPRG
#undef PPC_USE_SPRG
#endif
#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.

Bryon Doyle
Summer Intern, Bell Labs
Lucent Technologies
 

-----Original Message-----
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 
more information).

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 
libbsp/powerpc/support/old_exception_processing/irq_stub.S 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.

Cheers,

Keith



More information about the users mailing list