[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:  Nick Withers <nick.withers@…>
     Type:  defect        |      Status:  closed
 Priority:  normal        |   Milestone:  4.11.1
Component:  General       |     Version:  4.11
 Severity:  normal        |  Resolution:  fixed
 Keywords:                |
--------------------------+--------------------------------------------

Comment (by sebastian.huber):

 Replying to [comment:14 nick.withers]:
 > Replying to [comment:12 sebastian.huber]:
 > > Sorry, I didn't noticed your patch.  the Alternate Time Base may run
 with a much higher frequency, so I would like to keep it.
 >
 > {{{rtems_bsp_delay_in_bus_cycles()}}} at least is gonna be wrong (or
 misleadingly named, perhaps) for platforms using the ATB where it happens
 not to be operating at bus frequency, isn't it?
 >
 > Next thing though is that the ATB isn't supported for e500v1s (
 http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf p
 1-19 )... Is {{{_CPU_Counter_read()}}}'s
 > {{{
 > #if defined(ppc8540) || defined(__PPC_CPU_E6500__)
 > }}}
 > meant to be
 > {{{
 > #if defined(ppc8548) || defined(__PPC_CPU_E6500__)
 > }}}
 > ...or similar?

 This is bad, since we don't have a ppc8548 multilib. In this case we have
 to drop the defined(ppc8540).

 >
 > It'd be quite nice if we (GCC?) had individual feature flags for some of
 this stuff, given how all-over-the-place the various PPC cores are,
 wouldn't it? I'll have a crack if you think so.
 >
 > Also, would you be alright with removing the "OTOH, PSIM currently lacks
 support for reading SPRs 268/269. You need GDB patch sim/2376 to avoid a
 crash..." comment in ''powerpc-utility.h''?
 ​https://sourceware.org/bugzilla/show_bug.cgi?id=9481 is now closed ('twas
 Joel fixed the issue, back in 2010).

 Ok, can you please send a separate patch to the mailing list.

 >
 > I've cunningly avoided thinking properly about whether ignoring the
 upper portion of the time base is a good idea... But, for example, isn't
 {{{rtems_bsp_delay()}}} going to stuff up if the lower 32 bits wrap?

 The use case for the _CPU_Counter_read() is to measure short time
 intervals for the SMP lock profiling and short delay loops for device
 drivers.  Do you really want to busy wait for 123 seconds?

 The rtems_bsp_*() are legacy functions.  I would not use them.

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