i.MX6 SoloX Cortex-M4 clock frequency

[zvonimirmandi_]

Simple question: is M4 frequency set to 227 MHz by default in u-Boot boot parameters?

I wrote a simple test application with gpio output to measure M4 frequency. Applications code goes something like this:

          set_gpio

          nop; nop; nop; nop; nop; nop; nop; nop; nop; nop;

          clear_gpio

          nop; nop; nop; nop; nop; nop; nop; nop; nop; nop;

          set_gpio

          nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop; nop;

          clear_gpio

          nop; nop; nop; nop; nop; nop; nop; nop; nop; nop;

Basically I'm measuring execution time of 10 nop instructions. The difference in execution time I'm getting is 540 ns which gives me 54 ns per instruction (should be between 4 and 5 ns).

Cortex-m4 generic user guide states: "NOP does nothing. NOP is not necessarily a time-consuming NOP. The processor might remove it

from the pipeline before it reaches the execution stage.", so I have written a similar example with "teq" (test equal) assembly instruction. Difference in execution when using teq is 1 us (which gives 100 ns per instruction).

By reading CCM registers it can be seen that M4_CLK_ROOT uses PLL3_PFD3 divided by 2 so frequency should be 227.35 MHz.

Register values are:

PLLPFD3   addr=0x420C80f0        value=0x5351504c

PLL3          addr=0x420C8010       value=0x80003000

CHSCCDR addr=0x420C4034       value=0x00021148

Test application runs from DDR from address 0x10000000. It's size is smaller than cache so I think the whole code should be loaded and executed from L1. Same results are when A9 is in u-Boot and when A9 loads and runs linux.

In this application I'm using M4's SysTick with reload value 227232 (or 1 ms). I have written a handler which also toggles gpio. With this everything looks fine (measure gives exactly 1 ms period).

Also I have found a function in linux kernel in location [KERNEL]/arch/arm/mach-imx/clk_imx6sx.c called imx6sx_set_m4_highfreq(bool high_freq). Does this function set M4 to higher frequency? Maybe it's not called with high_freq=1.

Thanks

EDIT: System boot sets PLL3 frequency to 480 MHz.

Are there any internal clock setup registers in M4? Maybe some divider or bypass is enabled.

EDIT2: i.MX 6SoloX Applications Processor Reference Manual on page 466 Table 13-2. Platform Clock Descriptions lists all possible M4 clock inputs:

sw_clk_tck      Single Wire/ JTAG Test Clock

trace_clk_in    TPIU - Trace Port Clock

tcmc_hclk       TCMC Clock

cm4_hclk        Gated CPU Clock. Platform output "cm4_gate_hclk" can be used as the enable signal.

cm4_fclk         Free-running CPU Clock

ipg_clk_nic     Gated PL301 Clock

Where is input clock selected? Does M4_CLK_ROOT need additional configuring outside of CCM?

[Yuri · Accepted solution]

Hello,

  According to section 2.1 (Key features) of “Freescale_MQX_i.MX6SoloX_GA_Release_Notes.pdf” :
“
• Cortex-M4 core clock: 227 MHz (default)

• AHB bus clock: 132 MHz (default)

“

    As for GPIO module of the i.MX6 SX : the GPIO logic is the actual bottleneck of i.MX
series,  since its GPIO is not intended for high speed real time tasks.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[zvonimirmandi_]

I think I found the reason of slow execution time. M4's cache is disabled even after writing to control register.

I'm enabling cache with this code:

__raw_writel(0x85000003,0xe0002000);

__raw_writel(0x85000003,0xe0002800);

Before writing, register values are 0x00000260 and 0x00000000, and after writing values are 0x00000261 and 0x00000000.

Is there some cache enable procedure that I'm unaware of?

Write value is 0x85000003 according to section 13.9.3.6.1 Cache set commands of i.MX 6SoloX Applications Processor Reference Manual:

"After a reset, complete an invalidate cache command before using the cache. It is possible

to combine the cache invalidate command with the cache enable. That is, setting CCR to

0x8500_0003 will invalidate the cache and enable the cache and write buffer."

Cache enabling is done in main function in c.

Thanks

[Yuri]

Hello,

  use \FreeRTOS_BSP_1.0.1_iMX6SX\platform\drivers\src\lmem.c as an example.

Regards,

Yuri.