• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 524 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.

OMAPL138 cpufreq with SDRAM

Marc-Andre Hebert
Prodigy 160 points
Other Parts Discussed in Thread: OMAPL138, AM1808

Hi,

I have 2 OMAPL138/AM1808 boards: one with mDDR  and ther other with SDRAM. I am looking at options to reduce power consumption. One the of options we are looking into is the cpu frequency. Not having a lot of success with the SDRAM board. Here is a little list of what I tried.

1) I have tried enabling the cpu frequency scaling. When I change the active governor (using /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor), It works with the mDDR board but any change in frequency fails when using the SDRAM board. I am guessing this is because the DDR is derived from PLL1 while the SDRAM uses PLL0. Is there a way to make the cpu frequency work or is this impossible with SDRAM?

2) With the SDRAM board, I then tried downclocking the cpu directly in the bootloader using the AISgen utility. Under the PLL0 tab, I modified by DIV1 from 1 to 2 to operate the CPU at 150Mhz instead of 300Mhz while preserving my SDRAM at 100Mhz. With this, the kernel hangs at boot during the SATA initialization (I can reach the console fine if I disable the AHCI). I looked at the SATA controller datasheet but couldn't find a link between the SYSCLK1 and the SATA (since DIV1 affects SYSCLK1, right?).

3) Similar to #2, I changed the PLL0 settings post-divider (2 to 3) and div3 (3 to 2). This gave me CPU 200 Mhz (with settings matching what is found under da850_opp_200 in da850.c) and still keeping the 100Mhz SDRAM. This configuration stalls during the kernel boot right after the reset of unused clocks.

I would appreciate if anyone had some information on either how to fix these issues or other ways to do this.
Thanks and regards
Marc

  • 0
    TI__Guru 62975 points

    Marc,

    I'm not sure how the linux software is handling this, but strictly from a hardware standpoint, the SDRAM should be able to retain its contents without a clock source while in Self Refresh mode.  While the SDRAM is self refreshing its contents, the OMAPL138/AM1808 can perform its frequency scaling operation, reconfigure the EMIF with updated timings, and interface with the SDRAM at the new frequency.

    -Tommy

  • 0
    Intellectual 280 points

    Hi Marc

     

    I'm wondering if you've been successful with your SDRAM board. I also am using SDRAM  on an AM1808 board and we're just getting ready to try them out. Did you have to modify the UBL as well? I tried changing the   UBL_DRAM        (RWX) : origin = 0xC0000000   length = 0x10000000 to 0x40000000 but it will not run under Code Composer. I remapped all UBL code to internal RAM so that I can run some diagnostics before SDRAM is used. I get this error when starting Code Composer.

    ARM9_0: File Loader: Data verification failed at address 0x40000000 Please verify target memory and memory map.
    ARM9_0: Unable to terminate memory download: 0x00000004/-2030 @ marker 1026 Error during: Register,  Access to an unknown or invalid register was attempted. 
    Error found during data verification.
    Ensure the linker command file matches the memory map.

    But nothing should be loading to SDRAM. Note that I'm still using the board with DDR2 until my boards are ready. But I don't think that should matter if nothing is being loaded to that memory. I should at least be able to start the debugger in Code Composer.

  • 0 in reply to John Dehelian
    Prodigy 160 points

    Hi John,

    I am not using the UBL in my design. I am using the u-boot directly with the AISgen utility. I dropped UBL pretty early as I did not see any benefits to it versus the cost of having to maintain one more piece of software (and the additionnal flash sector).

    This worked for me both with the DDR and SDRAM board.

    As for the cpufreq issue, it seems it was related to the self refresh timing not being respected after the frequency change.

    Regards

    Marc