• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 468 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM365 CPU frequency scaling

bandini
Intellectual 630 points

I am unable to decrease cpufrequency below 180 MHz either at init time, or after in Linux.

  • ARMCLK is provided py PLL2 SYSCLK2
  • PLL2 freq is 540 MHz
  • At init time (ie before enabling PLL) setting PLLDIV2 to 1 (270 MHz) or 2 (180 MHz) works. If however I set it to 3 (135 MHz), my first stage bootloader continue to work, but U-boot  crahes while booting
  • At runtime, ie using the cpufreq architecture (I extended the patch for DA850, so that it works for dm365 too) I use davinci_set_sysclk_rate on pll2 sysclk2 to modify the frequency, so basically the same thing as in the bootloader, except that the pll is running. I can use the 180 MHz settings, but the 135 MHz settings also hangs the board.

What is stopping me from using a lower cpufreq (DDR is on PLL1) ?

 

  • 0
    TI__Genius 9510 points

    Bandini,

    The limiting factor could be the source clock to the DDR2 is below the minimum threshold, as well as the EMIF timings not being adjusted accordingly. The first stage bootloader (I assume UBL) is works because it running from internal on chip memory.

    Marcus

  • 0 in reply to Marcus Cooksey
    Intellectual 630 points

    The source clock to the DDR2 is not changed, only the cpu clock is changed. Regarding EMIF timings, usually lowering the clock and keeping the same timing result in a working setup.  When doing the change at runtime, EMIF is not used, and it still fails.

    It certainly has something to do with working from DDR2, since Bootloaders still works. However, a very basic memory test run from the bootloader passes without problem.

  • 0 in reply to bandini
    TI__Genius 9510 points

    I believe the DDR2 clock will change if the system clock increases or decreases (unless you adjust the SYSxPLLx values).  One debug method is to connect via JTAG using CCS and adjust the system clock to the frequency of when the failure occurs.  Then, in CCS, open a memory view window and perform read/write at various DDR2 addresses.

  • 0 in reply to Marcus Cooksey
    Intellectual 630 points

    As stated in my first message :

    1. I change the PLLDIV2 register, which means I do not touch the PLL frequency, but the divider used to generate SYSCLK2, so no other clock should change.
    2. In any case, the DDR clock is generated from another PLL (PLL1)

    I have no JTAG access, but a memory test in my bootloader. This test works fine.  I will check the refresh value. May be the DDR PHY CLK (which is not touched) does not handle the refresh timer ?

  • 0 in reply to bandini
    Prodigy 240 points

    Hello!

    I have same problem!

    There is my post:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/90929/315651.aspx#315651

    http://marc.info/?l=linux-omap&m=129646148928317&w=2

     

    Do you resolve this problem ???