Ticker problem on ppc405 - FIXED
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:
>> 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
>>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
More information about the users