AnsweredAssumed Answered

imx6 running slow

Question asked by Elijah Brown on Jan 30, 2015
Latest reply on Feb 25, 2015 by Elijah Brown

Hi all, I have an IMX6Q running the Freescale bare metal platform SDK.  I'm using a boundary devices nitrogen6x board and so have had to modify the SDK a bit, just swapped out the IOMUX files and have only a subset of the drivers/tests compiled in.  What I'm seeing is the processor seems to be running extremely slowly.  For instance if I increment a counter in a loop, it takes about 1 second to count to 2,000,000.  I have the freescale IPU demo hooked up to the boundary devices WVGA 480x800 display, and it takes about 800ms to paint the image up to the display (you can watch the screen 'wipe' down as the memset runs).  That's a memset() over the whole frame buffer followed by a memcpy() of the freescale logo image.  This is supposed to be running at 792 MHz, that ought to be so quick it's indiscernible, I suspect something is way off in the configuration but have not yet figured out what.  Here's what I've tried and measured so far:


Hooked up various internal clocks to the CLKO1 and CLK02 pins and measured them with a scope.  Here are my measurements:

ipg_clk_root = 66 MHz

ahb_clk_root = 132 MHz

osc_clk = 24 MHz

axi_clk_root = 264 MHz

mmdc_ch0_axi_clk_root = 528 MHz

arm_clk_root = 396 MHz.


All of these are as expected except for the arm_clk_root - it is supposed to be 792 MHz.  I verified the DIV_SELECT field of the CCM_ANALOG_PLL_ARM register is set to 0x42 which should give a multiplication of 33 * 24 MHz is 792 MHz.  The ARM_PODF is set to 0, (should not divide the clock) and the PLL1_SW_CLK_SEL is also set to 0.  I do not understand why I'm seeing half of what I expect.  However, that alone is not enough to explain the terribly slow performance. 


My other suspicion as to what might cause this is incorrect DDR settings.  I am running out of RAM with a segger JTAG debugger and have a GDB init script to setup the DDR.  There are a lot of settings and I do not understand them all yet so any help here is appreciated.  I obtained the settings from the Boundary Devices u-boot port that runs on this board.  I attached my gdbinit script so you can see what it's setting.  The code is linked to start at 0x10000000 so it is running entirely out of DDR.  The MMU is setup is exactly the same as the freescale SDK has it - 0x10000000 to 2 GB up is mapped 1:1 virtual to physical, cache policy is kOuterInner_WB_WA. 


Anything else I've missed that could be causing this?  The chip does get pretty hot compared to what it did running u-boot.  Perhaps that is another datapoint but I am not sure what to do with it.  Thanks for any advice. 

Original Attachment has been moved to: