[RTEMS Project] #2369: [PowerPC Book E] Invalid mftb instruction in _CPU_Counter_read()
RTEMS trac
trac at rtems.org
Wed Jul 15 08:26:30 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 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
More information about the bugs
mailing list