[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 nick.withers):

 Replying to [comment:15 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.

 Shall do.

 > > 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?

 Do you really want to busy wait 123 seconds instead of the intended short
 time interval because you lost the race and the lower 32 bits of the
 counter wrapped?

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