Ticker problem on ppc405 - FIXED

Smith, Gene gene.smith at siemens.com
Tue Oct 19 17:20:05 UTC 2004

Joel Sherrill <joel at OARcorp.com> wrote, On 10/19/2004 7:08 AM:

> Smith, Gene wrote:
>>Figure out what the problem is but not why or how to correctly fix it. 
>>The problem was due statements like this for selecting code:
>>#if (PPC_USE_SPRG)
>>    do this way
>>    do that way
>>In file old_exception_processing/cpu.c "do that way" is selected, while
>>in old_exception_processing/irq_stub.S "do this way" is selected. The 
>>conflict resulted in some bad memory accesses.  I don't see anywhere 
>>that PPC_USE_SPRG is explicitly defined in the code except under 
>>build-rtems there is a automatically generated file bspopts.h that contains
>>#define PPC_USE_SPRG 1
>>But the file that (I think) controls this, bspopts.h.in, contains
>>#undef PPC_USE_SPRG
>>The kluge fix was to just add
>>#define PPC_USE_SPRG 0
>>in irq_stub.S so both files generate "do that way" code.
>>Anyhow, ticker now runs.
> Ralf.. how is this happening?  This is one of those
> macros from the BSP's configure.ac.  bspopts.h should
> have it as a 1 if I am reading the configure code correctly.
> Gene.. the installed bspopts.h has it undef'ed?
> Where does the cpu.c get its define?

cpu.c is seeing it undefined (or zero?) as I would have expected. 
irq_stub.S see it defined (non-zero?). (FWIW, the selectors are "#if x" 
not "#ifdef x".)

On my system I see

#define PPC_USE_SPGR 1

in the /opt/rtems-4.6 and /build-rtems areas for the file bspopts.h for 
all powerpc/*40x bsp's including mine which is a hybrid of gen405 and 

As a non-kluge solution I just went ahead and defined PPC_USE_SPGR as 1 in
which made it defined as 1 in both cpu.c and irq_stub.S. There was a 
warning in the code about use of SPGR messing up some debuggers but it 
seem to work ok for me when enabled

> --joel

More information about the users mailing list