[RTEMS Project] #2369: [PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()

[RTEMS trac]

#2369: [PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()
--------------------------+--------------------
 Reporter:  nick.withers  |      Owner:
     Type:  defect        |     Status:  new
 Priority:  normal        |  Milestone:  4.11.1
Component:  General       |    Version:  4.11
 Severity:  normal        |   Keywords:
--------------------------+--------------------
 ''_CPU_Counter_read()'', called e.g., when RTEMS profiling is enabled,
 attempts to use the ''mftb'' instruction to access the time base. This
 instruction does not exist on Book E processors (such as the e500 used in
 the MVME3100) and causes an exception on those architectures.

 At least RTEMS profiling therefore does not work at least with the
 ''mvme3100'' BSP.

 This...:
 {{{
 diff --git a/cpukit/score/cpu/powerpc/rtems/score/cpu.h
 b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
 index 06cab2c..45298a4 100644
 --- a/cpukit/score/cpu/powerpc/rtems/score/cpu.h
 +++ b/cpukit/score/cpu/powerpc/rtems/score/cpu.h
 @@ -842,7 +842,7 @@ static inline CPU_Counter_ticks _CPU_Counter_read(
 void )
    /* Use Alternate Time Base */
    __asm__ volatile( "mfspr %0, 526" : "=r" (value) );
  #else
 -  __asm__ volatile( "mftb %0" : "=r" (value) );
 +  __asm__ volatile( "mfspr %0, 268" : "=r" (value) );
  #endif

    return value;
 }}}

 ...sorts it out on the ''mvme3100'' and I don't *think* will break
 anything for other BSPs (I believe SPR 268 is always valid).

 I wonder if we wouldn't be better off using
 ''PPC_Get_timebase_register()'', though, which also checks the upper
 32-bits of the timebase? Maybe that doesn't matter for the cases where
 ''_CPU_Counter_read()'' 's called?

--
Ticket URL: <http://devel.rtems.org/ticket/2369>
RTEMS Project <http://www.rtems.org/>
RTEMS Project