XU4 DRAM OverClocking

[joy]

Hi all,

We've checked the further room for DDR3 of exynos5422 on XU3/4
and one more DDR frequency, 933 MHz has been added.



You can change the variable DDR frequency set using [ODROID Utility] and [boot.ini].
Please refer to the following and try it!

1. WIKI Page
http://odroid.com/dokuwiki/doku.php?id= ... _overclock

2. Android Guide
The available release version, Android 4.4.4 v4.9 (17 May, 2017) has been released.
http://odroid.com/dokuwiki/doku.php?id= ... _note_v4.9

On Android, you can adjust DDR frequency and governor using a new ODROID Utility.

(1) Frequency
The available frequency set is as following.

Code: Select all

# cat /sys/class/devfreq/exynos5-devfreq-mif/available_frequencies
165000  206000  275000  413000  543000  633000  728000  825000  933000

(2) Governor
If you want to operate DDR with the max one, please set DRAM governor to 'performance'.

Code: Select all

# cat /sys/class/devfreq/exynos5-devfreq-mif/available_governors
simple_exynos   performance

3. Ubuntu Guide
On kernel 4.9 with XU4 ubuntu, you can change ddr frequency using boot.ini interface if you updated the system software 23-May-2017.
The available frequency set is 933MHz, 825MHz, 728MHz and 633MHz
and the default one is 825MHz.

Usually, the MIF sysfs interface under the devfreq node can be expected to handle max_freq of DDR.
But so far, there is no devfreq mif node on kernel 4.9.
We added u-boot command to handle DMC,
so you can use boot.ini to change DDR frequency before MIF devfreq driver is ready.

- How to set boot.ini

Please find ddr_freq in boot.ini and change the value.

Code: Select all

...
# DRAM Frequency
# Sets the LPDDR3 memory frequency
# Supported values: 933 825 728 633 (MHZ)
setenv ddr_freq 825
...
# set DDR frequency
dmc ${ddr_freq}
...

Then, please make sure to reboot the system.

Code: Select all

# sudo reboot

3. Benchmark Scores

(1) AnTuTu Benchmark Score with Android

Here is a AnTuTu benchmark score.
We checked the following two cases.

Code: Select all

Case 1 : cpu governor - performance / devfreq governor - performance / devfreq clock - 825MHz
Case 2 : cpu governor - performance / devfreq governor - performance / devfreq clock - 933MHz

(2) mbw Benchmark Score with Ubuntu kernel 4.9

And here is mbw benchmark score on Ubuntu.

Code: Select all

- Change ddr_freq in boot.ini and reboot
- make cpu governor as performance
# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 
# echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor 
- run mbw with parameter '100'
# mbw 100

[crossover]

Great job! Really awesome. My XU4 is getting better and better every day.
I could feel improved responsiveness with updated u-boot package and edited boot.ini. I will do some stability tests.

[DarkBahamut]

Works great on 3.10, as long as you edit the mif qos rules as the dynamic driver doesn't really work (always selects minimum freq).

The 1100mV voltage is quite high, I actually found better stability by lowering the voltage to 1075mV. Otherwise it all seems to work great so far!

Haven't tested 4.9 as yet.

Edit: Those mbw benchmarks on 4.9 seem low. I can hit >4900MB/s on 3.10

[joy]

The 1100mV voltage is quite high, I actually found better stability by lowering the voltage to 1075mV. Otherwise it all seems to work great so far!

Yes, right. That's a good point!
I set the MIF voltage as 1100mV that is recommended in the exynos5422 manual.
In my case, I've tried 0.975mV with 933MHz and it worked.
We need to check the stability and put aging tests with all of XU3/XU4 series and a variety of board cases.
I will also check it and investigate the voltage and current pattern.

And if you use Ubuntu, kernel 3.10 may be a better test bench
because there is no ASV and MIF fully yet on kernel 4.9.
(I think you already know it. )

Edit: Those mbw benchmarks on 4.9 seem low. I can hit >4900MB/s on 3.10

Which component of mbw?
As I checked, the mbw scores are higher on 4.9 than 3.10,
so I thought that buses and related IP blocks may be supposed to run as max performance on 4.9 because dvfs isn't completed yet.
Anyway, let's check it more!

[phaseshifter]

i have it as per the boot.ini file @ 933Mhz on my xu3-lite...if i can be of assistance pls post @joy
seems to be fine with it....kernel 39..40

[memeka]

just to confirm:

for 4.9 kernel, setting the RAM freq is all done in u-boot? there's no kernel change?
thanks.

[Snk]

Is there any way to reduce the voltage to 0.975mv?
This reduction could somehow help in plate stability.

[joy]

i have it as per the boot.ini file @ 933Mhz on my xu3-lite...if i can be of assistance pls post @joy

The same kernel and packages are used in all of XU3/XU4 series,
so XU3-lite is also available.

Please try it
and it will be very helpful that you can check if it's working with your board.

[joy]

just to confirm:
for 4.9 kernel, setting the RAM freq is all done in u-boot? there's no kernel change?

No, there is no kernel change related to RAM frequency setting on kernel 4.9.
On u-boot, I added one command 'dmc' to set RAM frequency-related registers
and the command runs with boot.ini option.

https://github.com/hardkernel/u-boot/co ... dd17605776

[joy]

Is there any way to reduce the voltage to 0.975mv?
This reduction could somehow help in plate stability.

Do you mean the source code points to adjust the voltage?
If so, it depends on the OS, Android or Ubuntu.
On Android, devfreq kernel driver should be modified and compiled.
In case of Ubuntu, we need to change u-boot.
I will check if there is an easier way
and share more information then.

And please note that samsung recommends the 1.1V MIF voltage to run RAM frequency as 933MHz.

[phaseshifter]

yes to confirm it works on my xu3-lite

[joy]

Is there any way to reduce the voltage to 0.975mv?
This reduction could somehow help in plate stability.

1. Ubuntu with kernel 4.9
Currently, there is no dvfs and asv for MIF in kernel 4.9,
so need to modify u-boot.

https://github.com/hardkernel/u-boot/bl ... oid.h#L120
- u-boot/include/configs/odroid.h

Code: Select all

/* #define CONFIG_PM_VDD_MIF	1.10 */
#define CONFIG_PM_VDD_MIF	0.975

2. Android
https://github.com/hardkernel/linux/blo ... evt0.h#L31
- kernel/arch/arm/mach-exynos/include/mach/asv-exynos5422_evt0.h

Code: Select all

/* #define MIF_MAX_VOLT			(1100000) */
#define MIF_MAX_VOLT			(975000)

Or, you can revert the following commit to use 0.975V as VDD_MIF.
https://github.com/hardkernel/linux/com ... ad81c6d8d3

[joy]

The 1100mV voltage is quite high, I actually found better stability by lowering the voltage to 1075mV. Otherwise it all seems to work great so far!

I've tried 'stress test' with 975mV VDD_MIF and 933MHz RAM frequency
It has been worked for a half day with ubuntu kernel 4.9.

Code: Select all

# stress -c 9 -m 8

But I'm not sure about the system stability for all of XU4/XU3 including XU3 lite boards.

Would be better to check it again with dvfs and asv table, once those driver with MIF is done in kernel 4.9.

[phaseshifter]

i did it on a U-2 933 Mhz

[phaseshifter]

is 4.9 a prerequisite for the ram to be over clocked in this fashion..???

see topic here

viewtopic.php?f=8&t=28003

[ecth]

Is there such a file in the Arch Linux installation?

Code: Select all

uname -a
Linux alarm 4.9.51-1-ARCH #1 SMP PREEMPT Sun Sep 24 20:49:55 UTC 2017 armv7l GNU/Linux

So kernel is also 4.9-based.

[odroid]

@ecth
Check the available DRAM clock frequencies on command line.

Code: Select all

cat /sys/class/devfreq/exynos5-devfreq-mif/available_frequencies

[ecth]

I only have these:

Code: Select all

cat /sys/class/devfreq/soc\:bus_
soc:bus_disp1:/       soc:bus_fsys_apb:/    soc:bus_gscl_scaler:/ soc:bus_mscl:/
soc:bus_disp1_fimd:/  soc:bus_g2d:/         soc:bus_jpeg:/        soc:bus_noc:/
soc:bus_fsys2:/       soc:bus_g2d_acp:/     soc:bus_jpeg_apb:/    soc:bus_peri:/
soc:bus_fsys:/        soc:bus_gen:/         soc:bus_mfc:/         soc:bus_wcore:/

[odroid]

In that case, ALARM kernel config or code seems to be different from our official kernel repo.
https://github.com/hardkernel/linux/tre ... dxu4-4.9.y

[memeka]

@odroid, it's missing from latest HK official 4.9 kernel too

Code: Select all

root@odroid:~# uname -a
Linux odroid 4.9.52-66 #1 SMP PREEMPT Wed Oct 4 04:17:12 UTC 2017 armv7l armv7l armv7l GNU/Linux
root@odroid:~# ls -lah /sys/class/devfreq/
total 0
drwxr-xr-x  2 root root 0 Oct  9 11:08 .
drwxr-xr-x 51 root root 0 Jan  1  2000 ..
lrwxrwxrwx  1 root root 0 Jan  1  2000 11800000.mali: -> ../../devices/platform/11800000.mali:/devfreq/11800000.mali:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_disp1: -> ../../devices/platform/soc:/soc:bus_disp1:/devfreq/soc:bus_disp1:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_disp1_fimd: -> ../../devices/platform/soc:/soc:bus_disp1_fimd:/devfreq/soc:bus_disp1_fimd:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_fsys: -> ../../devices/platform/soc:/soc:bus_fsys:/devfreq/soc:bus_fsys:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_fsys2: -> ../../devices/platform/soc:/soc:bus_fsys2:/devfreq/soc:bus_fsys2:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_fsys_apb: -> ../../devices/platform/soc:/soc:bus_fsys_apb:/devfreq/soc:bus_fsys_apb:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_g2d: -> ../../devices/platform/soc:/soc:bus_g2d:/devfreq/soc:bus_g2d:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_g2d_acp: -> ../../devices/platform/soc:/soc:bus_g2d_acp:/devfreq/soc:bus_g2d_acp:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_gen: -> ../../devices/platform/soc:/soc:bus_gen:/devfreq/soc:bus_gen:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_gscl_scaler: -> ../../devices/platform/soc:/soc:bus_gscl_scaler:/devfreq/soc:bus_gscl_scaler:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_jpeg: -> ../../devices/platform/soc:/soc:bus_jpeg:/devfreq/soc:bus_jpeg:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_jpeg_apb: -> ../../devices/platform/soc:/soc:bus_jpeg_apb:/devfreq/soc:bus_jpeg_apb:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_mfc: -> ../../devices/platform/soc:/soc:bus_mfc:/devfreq/soc:bus_mfc:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_mscl: -> ../../devices/platform/soc:/soc:bus_mscl:/devfreq/soc:bus_mscl:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_noc: -> ../../devices/platform/soc:/soc:bus_noc:/devfreq/soc:bus_noc:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_peri: -> ../../devices/platform/soc:/soc:bus_peri:/devfreq/soc:bus_peri:
lrwxrwxrwx  1 root root 0 Jan  1  2000 soc:bus_wcore: -> ../../devices/platform/soc:/soc:bus_wcore:/devfreq/soc:bus_wcore:

[odroid]

Ah.. something was broken.
We will check it tomorrow.

[joy]

There is no devfreq mif driver (dynamic memory controller block) on kernel 4.9.y so far.
So you can't find the /sys/class node same as kernel 3.10.y.
We're working the driver but, now this job is adjourned until we finish another high priority works.
It's very long term job.

Instead, we provide another solution using boot.ini and u-boot.
Please refer to this wiki page.
https://wiki.odroid.com/odroid-xu4/appl ... untu_guide

Code: Select all

...
# DRAM Frequency
# Sets the LPDDR3 memory frequency
# Supported values: 933 825 728 633 (MHZ)
setenv ddr_freq 825
...
# set DDR frequency
dmc ${ddr_freq}
...

Your version should be ...

Code: Select all

Android : Available with Android 4.4.4 v4.9 (17 May, 2017) or higher version
Ubuntu : Available with Ubuntu (22 May, 2017) or higher version

[ecth]

But where can I find the boot.ini?

[odroid]

/media/boot/boot.ini on Ubuntu.
But Arch might use a boot.scr instead of boot.ini
viewtopic.php?f=96&t=23261

[ecth]

You're right, it was /boot/boot.scr.
This is what's inside:

Code: Select all

# MAC address configuration
# setenv macaddr "00:1e:ee:61:7a:39"

# --- Screen Configuration for HDMI on linux-odroid-xu3 ---
# -
# Uncomment only ONE line! Leave all commented for automatic selection.
# Uncomment only the setenv line!
# -
# ODROID-VU forced resolution
# setenv videoconfig "video=HDMI-A-1:1280x800@60"
# -
# 1920x1080 (1080P) with monitor provided EDID information. (1080p-edid)
# setenv videoconfig "video=HDMI-A-1:1920x1080@60"
# -
# 1920x1080 (1080P) without monitor data using generic information (1080p-noedid)
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1920x1080.bin"
# -
# 1280x720 (720P) with monitor provided EDID information. (720p-edid)
# setenv videoconfig "video=HDMI-A-1:1280x720@60"
# -
# 1280x720 (720P) without monitor data using generic information (720p-noedid)
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1280x720.bin"
# -
# 1024x768 without monitor data using generic information
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1024x768.bin"

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr=$$
if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

Should I add another setenv line underneath? Or should I add "ddr_freq 825" to the not-commented setenv line?
And the "dmc ${ddr_freq}" line (in my case of course "dmc 933") is just added below the setenv?

Sorry for asking that much. I just don't want to screw the setup and unplug the emmc again

[joy]

You're right, it was /boot/boot.scr.
This is what's inside:

Code: Select all

# MAC address configuration
# setenv macaddr "00:1e:ee:61:7a:39"

# --- Screen Configuration for HDMI on linux-odroid-xu3 ---
# -
# Uncomment only ONE line! Leave all commented for automatic selection.
# Uncomment only the setenv line!
# -
# ODROID-VU forced resolution
# setenv videoconfig "video=HDMI-A-1:1280x800@60"
# -
# 1920x1080 (1080P) with monitor provided EDID information. (1080p-edid)
# setenv videoconfig "video=HDMI-A-1:1920x1080@60"
# -
# 1920x1080 (1080P) without monitor data using generic information (1080p-noedid)
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1920x1080.bin"
# -
# 1280x720 (720P) with monitor provided EDID information. (720p-edid)
# setenv videoconfig "video=HDMI-A-1:1280x720@60"
# -
# 1280x720 (720P) without monitor data using generic information (720p-noedid)
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1280x720.bin"
# -
# 1024x768 without monitor data using generic information
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1024x768.bin"

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr=$$
if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

Should I add another setenv line underneath? Or should I add "ddr_freq 825" to the not-commented setenv line?
And the "dmc ${ddr_freq}" line (in my case of course "dmc 933") is just added below the setenv?

Sorry for asking that much. I just don't want to screw the setup and unplug the emmc again

Hi.
Sorry for late response.
There is no another dependency but, the "dmc ${ddr_freq} should be executed after "setenv ddr_freq 825".

Here is my example.

Code: Select all

# MAC address configuration
# setenv macaddr "00:1e:ee:61:7a:39"

# --- Screen Configuration for HDMI on linux-odroid-xu3 ---
# -
# Uncomment only ONE line! Leave all commented for automatic selection.
# Uncomment only the setenv line!
# -
# ODROID-VU forced resolution
# setenv videoconfig "video=HDMI-A-1:1280x800@60"
# -
# 1920x1080 (1080P) with monitor provided EDID information. (1080p-edid)
# setenv videoconfig "video=HDMI-A-1:1920x1080@60"
# -
# 1920x1080 (1080P) without monitor data using generic information (1080p-noedid)
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1920x1080.bin"
# -
# 1280x720 (720P) with monitor provided EDID information. (720p-edid)
# setenv videoconfig "video=HDMI-A-1:1280x720@60"
# -
# 1280x720 (720P) without monitor data using generic information (720p-noedid)
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1280x720.bin"
# -
# 1024x768 without monitor data using generic information
# setenv videoconfig "drm_kms_helper.edid_firmware=edid/1024x768.bin"

# DRAM Frequency
# Sets the LPDDR3 memory frequency
# Supported values: 933 825 728 633 (MHZ)
setenv ddr_freq 825
...
# set DDR frequency
dmc ${ddr_freq}

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr=$$
if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

[ecth]

Thanks for the reply!

But since I tried it, my Odroid won't boot. I just set back the values by commenting the two lines but the result is the same: First the fan spins at max speed (more than normally when mining coins on all cores...) and then it becomes more silent and keeps spinning. Nothing else is happening. A single red LED is lit, the rest doesn't ever go on or blink. Did I fry my XU3? =/

[ edit: ]
Okay, nevermind. In the first line of the file it says:

Code: Select all

# After modifying, run ./mkscr

Now I did (had to install uboot before...) and now it booted with 933 MHz ^^
Let's see how stable this baby runs ;D
Fantastic that a 2? 3? year old XU3 can run a new kernel (4.9) with some nice overclock on the memory. Nice

[kbaao]

I've been trying to run my own DRAM settings, but I wonder how the voltage is configured for each frequency.
I'm running Ubuntu 16.04, with kernel 3.10.106. Reason for 3.10 is that I want to use devfreq to manage my DRAM settings runtime.

Right now I'm editing the OPP values here: https://github.com/monojo/xu3/blob/mast ... #L165-L173

Next I also keep an eye on timing parameters here: https://github.com/monojo/xu3/blob/mast ... #L237-L246
Doesn't seem there is much documentation on how these values are established, but I'm assuming as voltage and frequency rise/drop the timing parameters need to become more strict or loose respectively. Only the values to the exact opposite, higher frequency/voltage gives higher timing values. Can anyone explain me what these values represent and how they're calculated? I've plotted them out and it seems there is a logarithmic step function to calculate them (which is almost at its max for the 933mhz OPP).

Coming back to the actual Frequency/Voltage OPP pairs, my feeling is that the voltage is ignored. No matter how low or high I set them the system doesn't seem the care. Having no voltage measurements on my xu4, can anyone confirm that defining custom voltages actually works?

[DarkBahamut]

Voltages are set in the ASV tables on 3.10, values in that OPP table are ignored (or more correctly, they are overwritten). Been a while since I ran 3.10 but I believe changing them works and can be done in real time IIRC (with appropriate kernel changes).

What else are you editing when you change the frequency? The value must also match the clock driver otherwise the value won't be used, so if you've only edited those OPPs then you probably haven't enforced any changes at all (clock or voltage).

[kbaao]

Voltages are set in the ASV tables on 3.10, values in that OPP table are ignored (or more correctly, they are overwritten). Been a while since I ran 3.10 but I believe changing them works and can be done in real time IIRC (with appropriate kernel changes).

I had (and still have more) to read up on ASV, but found some good discussions about it, many thanks for pointing this out!

What else are you editing when you change the frequency? The value must also match the clock driver otherwise the value won't be used, so if you've only edited those OPPs then you probably haven't enforced any changes at all (clock or voltage).

I've been using the 3.10.y-android branch as a reference to edit my 3.10.y kernel. Initially I only identified the OPP's in exynos5422_bus_mif.c as sources for devfreq, but after your post I had a closer look at the commit history and also found the ASV tables file being edited. This is really great and I will experiment with this in my kernel!

Mentioned commits for completeness sake:

• dvfs/exynos5422: Add 933MHz of mif and dram table
• dvfs/exynos5422: Add performance governor
• dvfs/exynos5422: Adjust MIF_MAX_VOLT

However, I observe the OPP being edited in these commits, while the AVS tables don't reflect these changes. This seems to contradictory to me. From the asv-exynos5422_evt0.h file I get that there are 4 MIF max voltages (MIF_MAX_VOLT, MIF_V240_MAX_VOLT, MIF_V230_MAX_VOLT, MIF_V300_BIN2_MAX_VOLT), for which I assume these are different regulators. It seems I am only interested in MIF_MAX_VOLT, which brings me to the following ADV table: asv-exynos5422_evt0.h#L413-L424. But like I said, the OPP changes are not reflected here.

On the subject of the clock driver, you mean following entries right?

Code: Select all

static unsigned int exynos5422_dram_param_3gb[][3] = {
	/* timiningRow, timingData, timingPower */
#ifdef CONFIG_SOC_EXYNOS5422_REV_0
	{0x3D6BA816, 0x4742086E, 0x60670447},	/*933Mhz*/
	{0x575A9713, 0x4740085E, 0x545B0446},	/*825Mhz*/
	{0x4D598651, 0x3730085E, 0x4C510336},	/*728Mhz*/

Can you explain how we match them? I was under the impression these values represent DRAM latencies which would need to scale together with voltage/frequency changes (high voltage => low latency, but these values seem to increase as voltage/frequency increases).

My apologies for these detailed questions, I'm trying to gain an understanding of how all this works together and all the (mostly undocumented and riddled with abbreviations- ) low-level code isn't make my life any easier. I would really appreciate your help on some of this if you have the time!

[joy]

Hi, kbaao,

Next I also keep an eye on timing parameters here: https://github.com/monojo/xu3/blob/mast ... #L237-L246
Doesn't seem there is much documentation on how these values are established, but I'm assuming as voltage and frequency rise/drop the timing parameters need to become more strict or loose respectively. Only the values to the exact opposite, higher frequency/voltage gives higher timing values. Can anyone explain me what these values represent and how they're calculated? I've plotted them out and it seems there is a logarithmic step function to calculate them (which is almost at its max for the 933mhz OPP).

Actually, there is no detailed document about mif and dram-related blocks if exynos5422.
To add 933MHz as you mentioned in "dvfs/exynos5422: Add 933MHz of mif and dram table", I also had to analyze boot code, clock and the devfreq driver in 3.10.y.
The values in this table are related to timings in DREXI block, and also clock control of LPDDR3_PHY is needed to be adjusted.

Code: Select all

static unsigned int exynos5422_dram_param_3gb[][3] = {
   /* timiningRow, timingData, timingPower */
#ifdef CONFIG_SOC_EXYNOS5422_REV_0
   {0x3D6BA816, 0x4742086E, 0x60670447},   /*933Mhz*/
   {0x575A9713, 0x4740085E, 0x545B0446},   /*825Mhz*/
   {0x4D598651, 0x3730085E, 0x4C510336},   /*728Mhz*/

And about voltage, it's right to use the following table.
https://github.com/hardkernel/linux/blo ... mif.c#L163
If you have any multimeter to measure voltage, you can see the voltage change as you set the mif frequency under the node,

Code: Select all

cat /sys/class/devfreq/exynos5-devfreq-mif/

You can use the capacitor points, C56, C224, C225... from VDD_MIF with BUCK1.

Can I ask one?
Do you want to make your own DDR table except the table we provide like 933, 825, 728 and so on,
or need higher or lower DDR frequency value?

[kbaao]

The values in this table are related to timings in DREXI block, and also clock control of LPDDR3_PHY is needed to be adjusted.

Code: Select all

static unsigned int exynos5422_dram_param_3gb[][3] = {
   /* timiningRow, timingData, timingPower */
#ifdef CONFIG_SOC_EXYNOS5422_REV_0
   {0x3D6BA816, 0x4742086E, 0x60670447},   /*933Mhz*/
   {0x575A9713, 0x4740085E, 0x545B0446},   /*825Mhz*/
   {0x4D598651, 0x3730085E, 0x4C510336},   /*728Mhz*/

I actually found a blog about this: https://blog.korena.xyz/bare-metal-2/. Looks like these hex values are bit streams which hold information on DRAM latency values. For DDR2 the timingRow would have contained (in reverse order) tRfc, TRRD, tRP, tRcd, tRc and tRAS. The bitstream values need to be multiplied with the clock duration in nanoseconds. Without having this verified, I'm assuming the encoding doesn't translate to our DDR3 memory 1:1, but at least some insight/explanation on those hex values!

You can use the capacitor points, C56, C224, C225... from VDD_MIF with BUCK1.

Excellent! I was hoping for something like this. Not having any way to confirm changes was driving me mad. C224 on the back looks like a good point to measure, C56 is under the heatsink and C225 is too small.

Can I ask one?
Do you want to make your own DDR table except the table we provide like 933, 825, 728 and so on,
or need higher or lower DDR frequency value?

Sure can! I am looking into increased voltage operation in (modern) DRAM as part of a study. This is a similar-ish paper, to give you an idea: https://arxiv.org/pdf/1705.10292.pdf.
Right now I need to collect data for (as much as possible) operating states with increased voltage and frequency. DarkBahamut mentioned voltage changes can be done real time, so ideally I would just have 2 "knobs" I can turn to increase/decrease voltage and frequency separately. I expect my tests will stop somewhere at around 1100 MHz and 1.15-1.2v, but this is mostly dependant on the stability I observe. The increased values are ment to be applied for short periods (seconds at best), so I'm not really interested in prolonged stability.

[joy]

Hi. kbaao,

If you need to adjust the voltage values for your study, try to modify this code.
https://github.com/hardkernel/linux/blo ... mif.c#L163

And about the detailed values of timing-related registers, we only have very limited information
, also it's not the official one so we can't open the detailed register descriptions.
Sorry.

And 933MHz is already overclocked one.
If you still need 1100MHz, please let me know.

[joy]

@kbaao,
For your information.....
I've tried 1066MHz today because I'm also wondering if there is more room,
but the minute I set related registers, system turns lock immediately.
I also adjusted vdd_mif voltage but no work.
So, no more room.

[DarkBahamut]

It would be interesting if someone was able to multimeter the XU4 to see what voltage it really is using. The kernel is claims that it's using the ASV tables and not the table in the bus driver. That is also the behaviour I would expect as it matches other Samsung devices running 3.10.

You can see the kernel output on my XU4 board when running 3.10:

Code: Select all

[    0.311355] [c4] VDD_MIF ASV group is 3

Code: Select all

[    8.568034] [c4] MIF 933000Khz ASV is 1100000uV
[    8.571158] [c4] DEVFREQ(MIF) : 933000Khz, ABB 8
[    8.575733] [c4] MIF 825000Khz ASV is 962500uV
[    8.580154] [c4] DEVFREQ(MIF) : 825000Khz, ABB 14
[    8.584837] [c4] MIF 728000Khz ASV is 925000uV
[    8.589263] [c4] DEVFREQ(MIF) : 728000Khz, ABB 14
[    8.593946] [c4] MIF 633000Khz ASV is 887500uV
[    8.598373] [c4] DEVFREQ(MIF) : 633000Khz, ABB 14
[    8.603057] [c4] MIF 543000Khz ASV is 862500uV
[    8.607483] [c4] DEVFREQ(MIF) : 543000Khz, ABB 14
[    8.612134] [c4] MIF 413000Khz ASV is 800000uV
[    8.616593] [c4] DEVFREQ(MIF) : 413000Khz, ABB 14
[    8.621278] [c4] MIF 275000Khz ASV is 775000uV
[    8.625708] [c4] DEVFREQ(MIF) : 275000Khz, ABB 14
[    8.630391] [c4] MIF 206000Khz ASV is 775000uV
[    8.634815] [c4] DEVFREQ(MIF) : 206000Khz, ABB 14
[    8.639499] [c4] MIF 165000Khz ASV is 775000uV
[    8.643925] [c4] DEVFREQ(MIF) : 165000Khz, ABB 14
[    8.649909] [c4] MIF: set ASV freq 825000, voltage 962500

The voltages don't match the bus driver, but they do match the ASV tables. I think the bus driver is only used if the ASV grouping is removed.

[joy]

The voltages don't match the bus driver, but they do match the ASV tables. I think the bus driver is only used if the ASV grouping is removed.

No, it doesn't match the value of the bus driver actually.
I made a confusion. sorry.
You're right.
It depends on the ASV group of each board and the assigned table values.
https://github.com/hardkernel/linux/blo ... evt0.h#L31
https://github.com/hardkernel/linux/blo ... vt0.h#L413
https://github.com/hardkernel/linux/blo ... vt0.h#L426
https://github.com/hardkernel/linux/blo ... vt0.h#L439
https://github.com/hardkernel/linux/blo ... vt0.h#L451

[kbaao]

It would be interesting if someone was able to multimeter the XU4 to see what voltage it really is using. The kernel is claims that it's using the ASV tables and not the table in the bus driver. That is also the behaviour I would expect as it matches other Samsung devices running 3.10.

You can see the kernel output on my XU4 board when running 3.10:

Code: Select all

[    0.311355] [c4] VDD_MIF ASV group is 3

Code: Select all

[    8.568034] [c4] MIF 933000Khz ASV is 1100000uV
[    8.571158] [c4] DEVFREQ(MIF) : 933000Khz, ABB 8
[    8.575733] [c4] MIF 825000Khz ASV is 962500uV
[    8.580154] [c4] DEVFREQ(MIF) : 825000Khz, ABB 14
[    8.584837] [c4] MIF 728000Khz ASV is 925000uV
[    8.589263] [c4] DEVFREQ(MIF) : 728000Khz, ABB 14
[    8.593946] [c4] MIF 633000Khz ASV is 887500uV
[    8.598373] [c4] DEVFREQ(MIF) : 633000Khz, ABB 14
[    8.603057] [c4] MIF 543000Khz ASV is 862500uV
[    8.607483] [c4] DEVFREQ(MIF) : 543000Khz, ABB 14
[    8.612134] [c4] MIF 413000Khz ASV is 800000uV
[    8.616593] [c4] DEVFREQ(MIF) : 413000Khz, ABB 14
[    8.621278] [c4] MIF 275000Khz ASV is 775000uV
[    8.625708] [c4] DEVFREQ(MIF) : 275000Khz, ABB 14
[    8.630391] [c4] MIF 206000Khz ASV is 775000uV
[    8.634815] [c4] DEVFREQ(MIF) : 206000Khz, ABB 14
[    8.639499] [c4] MIF 165000Khz ASV is 775000uV
[    8.643925] [c4] DEVFREQ(MIF) : 165000Khz, ABB 14
[    8.649909] [c4] MIF: set ASV freq 825000, voltage 962500

The voltages don't match the bus driver, but they do match the ASV tables. I think the bus driver is only used if the ASV grouping is removed.

The voltages indeed don't match. I've just measured following entry for you:

Code: Select all

[    9.487144] [c6] MIF 825000Khz ASV is 950000uV
[    9.491329] [c6] DEVFREQ(MIF) : 825000Khz, ABB 14

In reality it measures as 962mV, which seems to check out because there is some kind of MIF_VOLT_STEP of 125mV. The VDD_MIF moves with steps of 6250uV, not sure why it does that. See following example where I manually set voltage (target_volt) and then read from the regulator what the actual voltage is (mind you, this again needs +125mV):

Code: Select all

[ 1616.247707] [c7] run 7 ok! target_volt (+ 12500) @ 821500 , regulator_volt @ 825000
[ 1616.260394] [c7] run 8 ok! target_volt (+ 12500) @ 821000 , regulator_volt @ 825000
[ 1616.273103] [c7] run 9 ok! target_volt (+ 12500) @ 820500 , regulator_volt @ 825000
[ 1616.285776] [c7] run 10 ok! target_volt (+ 12500) @ 820000 , regulator_volt @ 825000
[ 1616.298724] [c7] run 11 ok! target_volt (+ 12500) @ 819500 , regulator_volt @ 825000
[ 1616.311536] [c7] run 12 ok! target_volt (+ 12500) @ 819000 , regulator_volt @ 825000
[ 1616.324588] [c7] run 13 ok! target_volt (+ 12500) @ 818500 , regulator_volt @ 818750
[ 1616.337462] [c7] run 14 ok! target_volt (+ 12500) @ 818000 , regulator_volt @ 818750
[ 1616.350244] [c7] run 15 ok! target_volt (+ 12500) @ 817500 , regulator_volt @ 818750
[ 1616.363716] [c7] run 16 ok! target_volt (+ 12500) @ 817000 , regulator_volt @ 818750
[ 1616.377114] [c7] run 17 ok! target_volt (+ 12500) @ 816500 , regulator_volt @ 818750
[ 1616.389969] [c7] run 18 ok! target_volt (+ 12500) @ 816000 , regulator_volt @ 818750
[ 1616.402918] [c7] run 19 ok! target_volt (+ 12500) @ 815500 , regulator_volt @ 818750
[ 1616.415812] [c7] run 20 ok! target_volt (+ 12500) @ 815000 , regulator_volt @ 818750
[ 1616.428755] [c7] run 21 ok! target_volt (+ 12500) @ 814500 , regulator_volt @ 818750
[ 1616.441657] [c7] run 22 ok! target_volt (+ 12500) @ 814000 , regulator_volt @ 818750
[ 1616.454580] [c7] run 23 ok! target_volt (+ 12500) @ 813500 , regulator_volt @ 818750
[ 1616.467558] [c7] run 24 ok! target_volt (+ 12500) @ 813000 , regulator_volt @ 818750
[ 1616.480741] [c7] run 25 ok! target_volt (+ 12500) @ 812500 , regulator_volt @ 812500
[ 1616.493639] [c7] run 26 ok! target_volt (+ 12500) @ 812000 , regulator_volt @ 812500
[ 1616.506529] [c7] run 27 ok! target_volt (+ 12500) @ 811500 , regulator_volt @ 812500
[ 1616.519440] [c7] run 28 ok! target_volt (+ 12500) @ 811000 , regulator_volt @ 812500
[ 1616.532322] [c7] run 29 ok! target_volt (+ 12500) @ 810500 , regulator_volt @ 812500
[ 1616.545091] [c7] run 30 ok! target_volt (+ 12500) @ 810000 , regulator_volt @ 812500
[ 1616.557974] [c7] run 31 ok! target_volt (+ 12500) @ 809500 , regulator_volt @ 812500
[ 1616.570816] [c7] run 32 ok! target_volt (+ 12500) @ 809000 , regulator_volt @ 812500
[ 1616.583619] [c7] run 33 ok! target_volt (+ 12500) @ 808500 , regulator_volt @ 812500

@kbaao,
For your information.....
I've tried 1066MHz today because I'm also wondering if there is more room,
but the minute I set related registers, system turns lock immediately.
I also adjusted vdd_mif voltage but no work.
So, no more room.

Sorry for my late reply joy! Appreciate the effort! I've developed my own kernel module in the meantime that allows for arbitrary voltage settings. I'll be sure to share the module in time, maybe its of use to someone here.

I'm still trying to figure out what the VDD_MIF is exactly and how it relates to other components. My understanding right now is that changing voltage or frequency mainly comes down to manipulating an interconnect bus between the CPU and DRAM.
1) How does this affect the memory controller itself?
2) Is the controller even part of the bus?

In general I'm still not sure what components are affected by changing the frequency or voltage. It seems there are some components to consider: memory controller, CPU<->DRAM bus, DRAM itself.
3) Which components are controlled? I read somewhere that the bus shares its clock speed with the DRAM, does that mean that changing the bus frequency directly affects the physical DRAM frequency it operates at? Does the same hold for the voltage?

And then finally, do we know the part number of the regulator? I'd assume its a regulator from Texas Instruments, but haven't been able to find which one.

[rooted]

Sorry for my late reply joy! Appreciate the effort! I've developed my own kernel module in the meantime that allows for arbitrary voltage settings. I'll be sure to share the module in time, maybe its of use to someone here.

Please do.

[kbaao]

Sorry for my late reply joy! Appreciate the effort! I've developed my own kernel module in the meantime that allows for arbitrary voltage settings. I'll be sure to share the module in time, maybe its of use to someone here.

Please do.

Will do. I'm trying to get functionality in for also modifying frequency and memory timings runtime, so just bear with me

[rooted]

Of course, take your time and get it all worked out

[moon.linux]

@kbaao
I stumbled across vert good repository to refer

Code: Select all

git clone https://chromium.googlesource.com/chromiumos/third_party/kernel.git -b release-R40-6457.B-chromeos-3.8 chromeos
cd chromeos

[kbaao]

@kbaao
I stumbled across vert good repository to refer

Code: Select all

git clone https://chromium.googlesource.com/chromiumos/third_party/kernel.git -b release-R40-6457.B-chromeos-3.8 chromeos
cd chromeos

Can you elaborate on this? The code seems a bit more descriptive with error messages and comments, is there anything else?

[moon.linux]

Opps this is the code base for Samsung Chromebook 2 XE503C12 Exynos5420/Exynos5422 platform.
So this code base is bit old but very much detailed Exynos542x platform. Below is the like for reference.

Code: Select all

http://linux-exynos.org/wiki/Samsung_Chromebook_2_XE503C12/Installing_Linux

CPU<->DRAM bus tuning is handled in u-boot side to initialize the CLK bus frequency I guess so.

[joy]

I'm still trying to figure out what the VDD_MIF is exactly and how it relates to other components. My understanding right now is that changing voltage or frequency mainly comes down to manipulating an interconnect bus between the CPU and DRAM.
1) How does this affect the memory controller itself?
2) Is the controller even part of the bus?

In general I'm still not sure what components are affected by changing the frequency or voltage. It seems there are some components to consider: memory controller, CPU<->DRAM bus, DRAM itself.
3) Which components are controlled? I read somewhere that the bus shares its clock speed with the DRAM, does that mean that changing the bus frequency directly affects the physical DRAM frequency it operates at? Does the same hold for the voltage?

And then finally, do we know the part number of the regulator? I'd assume its a regulator from Texas Instruments, but haven't been able to find which one.

Hi kbaao,
Sorry for too late response.

VDD_MIF is a power source of DREX (DRAM controller), IROM, IRAM and related internal blocks.

You can find XU4 schematics here.
https://wiki.odroid.com/odroid-xu4/hard ... d_drawings
https://dn.odroid.com/5422/ODROID-XU4/Schematics/
(page 26)
VDD_MIF is supplied from BUCK1 output of PMIC S2MPS11B.

I've developed my own kernel module in the meantime that allows for arbitrary voltage settings. I'll be sure to share the module in time, maybe its of use to someone here.

Cool! It will be very helpful.

[Marjaney]

just to confirm:
for 4.9 kernel, setting the RAM freq is all done in u-boot? there's no kernel change?

No, there is no kernel change related to RAM frequency setting on kernel 4.9.
On u-boot, I added one command 'dmc' to set RAM frequency-related registers
and the command runs with boot.ini option.

https://github.com/hardkernel/u-boot/co ... dd17605776

Thanks for the link.

[sainivedant41]

I'm running Ubuntu 16.04, with kernel 3.10.106. Reason for 3.10 is that I want to use devfreq to manage my DRAM settings runtime.

[joy]

I'm running Ubuntu 16.04, with kernel 3.10.106. Reason for 3.10 is that I want to use devfreq to manage my DRAM settings runtime.

It's available now to use dram devfreq on kernel 5.4.y with Ubuntu 20.04, too.
https://wiki.odroid.com/odroid-xu4/os_i ... ubuntu_5.4

Please refer to this thread and try it.
viewtopic.php?p=301597#p301597