[Spam?] Re: RTEMS on Zynq Microzed
soja-lists at aries.uberspace.de
Sun Feb 7 19:58:48 UTC 2016
Am Wednesday 03 February 2016, 11:10:34 schrieb Jeff Webb:
> On 02/02/2016 08:57 AM, soja-lists at aries.uberspace.de wrote:
> > Hi,
> > I hope it's not a problem to dig up this old thread.
> This is what worked on my Zedboard:
> ../rtems-git/configure --target=arm-rtems4.12 \
> --enable-rtemsbsp=xilinx_zynq_zedboard \
> --enable-tests=samples \
> --enable-cxx \
> --enable-posix \
> --prefix=/opt/rtems/bsps/4.12 BSP_ARM_A9MPCORE_PERIPHCLK=333333333U
> make -j8 install
> I still haven't tried a microzed yet, so I can't say whether the same clock setting would work.
I can confirm that compiling the BSP with BSP_ARM_A9MPCORE_PERIPHCLK set to 333MHz fixes the timing issues.
After some digging I think I also found out the why (for the case someone else stumbles upon this):
RTEMS registers a timer interrupt for the global timer of the Microzed's A9 processor. It uses initialization from the arm/shared-directory because the
global timer works similar among the A9 cores.
The ARM Cortex-A9 MPCore TRM section 4.3  states: " The global timer is clocked by PERIPHCLK.", which is reflected in the initialization.
However in Zynq-7000 TRM from Xilinx section 8.3.1  they say: "The GTC is always clocked at 1/2 of the CPU frequency (CPU_3x2x)."
That means the shared driver initialization sets the wrong frequency for the Zynq-7000 family, because Xilinx deviated from the ARM reference implementation which then breaks the computation of ticks from timespans.
I grepped for the BSP_ARM_A9MPCORE_PERIPHCLK-variable and corresponding functions and it seems that it is only used in the timer initialization routine. Therefore it should be safe to just change the variable to the correct timer frequency without breaking other drivers which may need the actual cpu-freqency (which is still 667 MHz in the standard setup).
> users mailing list
> users at rtems.org
More information about the users