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

RTEMS trac trac at rtems.org
Wed Jul 15 08:20:12 UTC 2015


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

 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).

 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?

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


More information about the bugs mailing list