This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GPMC at 166MHz

Other Parts Discussed in Thread: AM3703, OMAP3530

Hi,

I'm having a problem setting GPMC parameters correctly and after debugging for a whole day I find some inconsistency between the clock speeds reported by the linux kernel and reality. I'm running PSP_04.02.00.07 (based on 2.6.37) and  find the following clocks to be set at:

[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/166/500 MHz
[    0.000000] dpll3_m2_ck: 166000000
[    0.000000] core_ck: 166000000
[    0.000000] l3_ick: 83000000
[    0.000000] core_l3_ick: 83000000
[    0.000000] gpmc_fck: 83000000

Notably, the gpmc fclk is set to 83MHz. Also, with a debugger I verified the the PRCM.CM_CLKSEL_CORE[1:0] divider to be 2. However, when I use a clock divider of 1 in the GPMC CS register settings, the applied GPMC CLK is at 166MHz (measured), while it should be at 83 MHz.

What am I not understanding? The problem is, that the linux gpmc api will not calculate the gpmc parameters as to the speed constraints I'm having since the used fclk does not reflect reality :(

Any help is appreciated! Regards,

Andi

  • The GPMC_CLK max freq is 100MHz.  You will have to stay at 83MHz if you are running your DDR at 166MHz, since both are derived from the L3 clock.

    Regards,

    James

  • Hi Jethin,

    i looked at the link but couldnt find anything GPMC clock related.

    And James, actually I'm trying to run at 41.5MHz, but the real problem is that my kernel reports that gpmc_fclk is set to 83MHz, while in reality I measure 166 MHz. Because of this mismatch, the linux GPMC API sets the divider to 2, while it needs to be 4. As a consequence wrong values for the various setup, hold and cycle times are applied. If I set the GPMC registers manually things work, but thats a bit of a hack a guess.

    In the meanwhile I have found out that the problem disappears if I use a x-loader built for AM3703 instead of the proprietary first stage boot loader which comes with the module (logic loader). Note, I'm running OMAP3530.

    So the questions is more a bootloader/kernel related one and why their clock setup is out of sync with reality...