The RK3399 Overclock/Undervolt/Voltages Thread

[generaleramon]

hey, i'm tweaking the SoC voltages in the .dtsi files and i was wondering what was the lowest possible voltage that i could set for the CPU and/or GPU. Looking in the rk3399-pinebook-pro.dts i've found something that might help.

Code:

vdd_cpu_l: DCDC_REG2 {
regulator-name = "vdd_cpu_l";          <<< cpu_l is the little cluster
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <750000>;    <<<750 mv
regulator-max-microvolt = <1350000>;   <<<1350mv   
regulator-ramp-delay = <6001>;

vdd_cpu_b: regulator@40 {
compatible = "silergy,syr827";
reg = <0x40>;
fcs,suspend-voltage-selector = <1>;
pinctrl-names = "default";
pinctrl-0 = <&vsel1_pin>;
regulator-name = "vdd_cpu_b";          <<<cpu_b is the big cluster
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <712500>;    <<<712.5 mv
regulator-max-microvolt = <1500000>;   <<<1500mv
regulator-ramp-delay = <1000>;
vin-supply = <&vcc_1v8>;

vdd_gpu: regulator@41 {
compatible = "silergy,syr828";
reg = <0x41>;
fcs,suspend-voltage-selector = <1>;
pinctrl-names = "default";
pinctrl-0 = <&vsel2_pin>;
regulator-name = "vdd_gpu";           <<<GPU
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <712500>;   <<<712.5mv
regulator-max-microvolt = <1500000>;  <<<1500mv
regulator-ramp-delay = <1000>;
vin-supply = <&vcc_1v8>;

###
As of now i've found that the GPU can run at 712.5mv@400Mhz no problem but i need 775mv@500Mhz so i can confirm that it can go below the stock 800mv.
Same with the 2 cpu clusters, in some cases i was able to undervolt around 200mv at the same frequency.
i'm currently running 4xA53@1.7Ghz/2xA72@2.1Ghz/GPU@1050Mhz.
    << my (old) voltage curve

###
I wonder is someone can confirm that 750-712mv is the lowest voltage that can be set and i also wonder what is the "step size", meaning how precisely i can tune it. 6.25mv like in modern gpus? 12.5? 25mv?

###
EDIT: I'm pretty sure that a 12.5mv step is accepted. The A72 Cluster is stable @1Ghz with 775mv, can't even boot with 750mv, Linpack unstable with 762.5mv.

###
EDIT2: 08/06/2021 - Here is my latest 99% stable rk3399-opp.dtsi file:

Code:

cluster0_opp: opp-table0 {
        compatible = "operating-points-v2";
        opp-shared;

        opp00 {
            opp-hz = /bits/ 64 <600000000>;
            opp-microvolt = <750000>;
            clock-latency-ns = <40000>;
        };
        opp01 {
            opp-hz = /bits/ 64 <696000000>;
            opp-microvolt = <750000>;
        };
        opp02 {
            opp-hz = /bits/ 64 <816000000>;
            opp-microvolt = <800000>;
        };
        opp03 {
            opp-hz = /bits/ 64 <1008000000>;
            opp-microvolt = <850000>;
        };
        opp04 {
            opp-hz = /bits/ 64 <1200000000>;
            opp-microvolt = <925000>;
        };
        opp05 {
            opp-hz = /bits/ 64 <1416000000>;
            opp-microvolt = <1025000>;
        };
        opp06 {
            opp-hz = /bits/ 64 <1512000000>;
            opp-microvolt = <1075000>;
        };
        opp07 {
            opp-hz = /bits/ 64 <1608000000>;
            opp-microvolt = <1125000>;
        };
        opp08 {
            opp-hz = /bits/ 64 <1704000000>;
            opp-microvolt = <1225000>;
        };
    };

    cluster1_opp: opp-table1 {
        compatible = "operating-points-v2";
        opp-shared;

        opp00 {
            opp-hz = /bits/ 64 <408000000>;
            opp-microvolt = <725000>;
            clock-latency-ns = <40000>;
        };
        opp01 {
            opp-hz = /bits/ 64 <600000000>;
            opp-microvolt = <750000>;
        };
        opp02 {
            opp-hz = /bits/ 64 <696000000>;
            opp-microvolt = <775000>;
        };
        opp03 {
            opp-hz = /bits/ 64 <816000000>;
            opp-microvolt = <775000>;
        };
        opp04 {
            opp-hz = /bits/ 64 <1008000000>;
            opp-microvolt = <800000>;
        };
        opp05 {
            opp-hz = /bits/ 64 <1200000000>;
            opp-microvolt = <850000>;
        };
        opp06 {
            opp-hz = /bits/ 64 <1416000000>;
            opp-microvolt = <950000>;
        };
        opp07 {
            opp-hz = /bits/ 64 <1512000000>;
            opp-microvolt = <975000>;
        };
        opp08 {
            opp-hz = /bits/ 64 <1608000000>;
            opp-microvolt = <1025000>;
        };
        opp09 {
            opp-hz = /bits/ 64 <1704000000>;
            opp-microvolt = <1075000>;
        };
        opp10 {
            opp-hz = /bits/ 64 <1800000000>;
            opp-microvolt = <1125000>;
        };
        opp11 {
            opp-hz = /bits/ 64 <2016000000>;
            opp-microvolt = <1212500>;
        };
        opp12 {
            opp-hz = /bits/ 64 <2040000000>;
            opp-microvolt = <1225000>;
        };
        opp13 {
            opp-hz = /bits/ 64 <2088000000>;
            opp-microvolt = <1250000>;
        };
        opp14 {
            opp-hz = /bits/ 64 <2184000000>;
            opp-microvolt = <1325000>;
        };
        opp15 {
            opp-hz = /bits/ 64 <2208000000>;
            opp-microvolt = <1362500>;
        };
    };

    gpu_opp_table: opp-table2 {
        compatible = "operating-points-v2";

        opp00 {
            opp-hz = /bits/ 64 <297000000>;
            opp-microvolt = <712500>;
        };
        opp01 {
            opp-hz = /bits/ 64 <400000000>;
            opp-microvolt = <725000>;
        };
        opp02 {
            opp-hz = /bits/ 64 <500000000>;
            opp-microvolt = <787500>;
        };
        opp03 {
            opp-hz = /bits/ 64 <600000000>;
            opp-microvolt = <850000>;
        };
        opp04 {
            opp-hz = /bits/ 64 <800000000>;
            opp-microvolt = <1012500>;
        };
        opp05 {
            opp-hz = /bits/ 64 <900000000>;
            opp-microvolt = <1087500>;
        };
        opp06 {
            opp-hz = /bits/ 64 <1000000000>;
            opp-microvolt = <1212500>;
        };
        opp07 {
            opp-hz = /bits/ 64 <1100000000>;
            opp-microvolt = <1275000>;
        };
    };
};

[dsimic]

Unfortunately, I cannot help you with some hard facts, but I'd like to know about the temperatures of the undervolted SoC, under full load?  Are there any significant differences compared with the standard voltages?

[generaleramon]

Unfortunately, I cannot help you with some hard facts, but I'd like to know about the temperatures of the undervolted SoC, under full load?  Are there any significant differences compared with the standard voltages?

well i don't have exact numbers for that, but from my limited experience overclocking/undervolting the PBP i can say that if you want to lower the temps than you have to improve the contact between the SoC and back cover. I noticed the thermal throttling at 70degrees when compiling the kernel (2-3 hours), pressing down the back cover in the soc area was instantly lowering the temp by some degrees, so i took another thermal pad and put it on top of the original one. That helped, the back cover now gets hotter and faster. BUT, as i want to overclock and stress test the 2 clusters with Linpack-HPL2.3(which is very heavy) i needed more thermal mass, so i used thermal glue to glue a 2-3mm thick metal plate (50x50mm) on the backcover, soc area. This was i can use a thin thermal pad and i have way more thermal mass. Using small fan barely running at 5v i can stresstest the 2 cluster at max clock(1.7Ghz/2.1Ghz) keeping the SoC under 75degrees(the standard limit is 70 but i increased it to 80 for now just for testing). Firefox with GPU rendering enabled use barely 4W when watching a 720p60 video on youtube, temps are under 40deg. Under a normal daily use i never see the SoC go over 50degrees
so in the end i would say that considering the thermal mass, the soc is going to throttle no matter what, but undervolting it you can make it run for longer. In my case, if i keep stock clocks and decide to just ondervolt i can lower the A53cores by 150mv and the A72 by 50mv @max clocks. Not bad.

[dsimic]

I had very similar plans for improving the heat dissipation as yours, so it's realy good that we can share the ideas and results.  I'll describe my plans below.

Did you use a 50x50 mm piece of copper sheet metal?  I presume you glued it to the inside of the back cover, using thermal epoxy?  Could you, please, post some pictures?

My plan was/is to reduce the thickness of the thermal pad between the back cover and the SoC.  Out of the factory, the pad is really thick, which simply cannot be better than using a thinner thermal pad.  So, I plan to use thermal epoxy to affix a piece of copper sheet metal to the inside of the back cover, right above where the SoC sits.  That will allow use of a thinner thermal pad.

However, the back cover is rather thin and heat doesn't propagate well through it.  So, another part of my plan was/is to use thermal epoxy to glue one or two flat heatpipes, about 10 cm in length, to the inside of the back cover, right next to where the thermal pad touches the back cover (more precisely, the aforementioned copper shim).  That should allow heat to spread further across the back cover.

Based on your experience, would it be worth it?

Also, prolonged use of the CPU at 100% causes the battery charging IC (TI BQ24171) to overheat and stop charging the battery, as decribed in this post.  Improving the spreading of the heat across the back cover should also reduce the heat soak into the components around the SoC, which includes the BQ24171.

[generaleramon]

I had very similar plans for improving the heat dissipation as yours, so it's realy good that we can share the ideas and results.  I'll describe my plans below.

Did you use a 50x50 mm piece of copper sheet metal?  I presume you glued it to the inside of the back cover, using thermal epoxy?  Could you, please, post some pictures?

My plan was/is to reduce the thickness of the thermal pad between the back cover and the SoC.  Out of the factory, the pad is really thick, which simply cannot be better than using a thinner thermal pad.  So, I plan to use thermal epoxy to affix a piece of copper sheet metal to the inside of the back cover, right above where the SoC sits.  That will allow use of a thinner thermal pad.

However, the back cover is rather thin and heat doesn't propagate well through it.  So, another part of my plan was/is to use thermal epoxy to glue one or two flat heatpipes, about 10 cm in length, to the inside of the back cover, right next to where the thermal pad touches the back cover (more precisely, the aforementioned copper shim).  That should allow heat to spread further across the back cover.

Based on your experience, would it be worth it?

Also, prolonged use of the CPU at 100% causes the battery charging IC (TI BQ24171) to overheat and stop charging the battery, as decribed in this post.  Improving the spreading of the heat across the back cover should also reduce the heat soak into the components around the SoC, which includes the BQ24171.

i used a sheet of random metal i found, nothing fancy. the SoC has a TDP of 7-10W at most, there is no need to go crazy on the cooling.
This is the glue i used https://www.ebay.it/itm/Silverbead-W%C3%...2749.l2649
Heatpipes are surely going to help spread the heat but i'm not sure is worth it. As of now i'm watching a youtube video and compiling the kernel, 100% usage and the temps are never going over 65deg. 75% of the back cover is pretty warm to the touch. i think the metal sheet really helps to spread out those 7w. Thanks for the info regarding the charging IC, i'm gonna look into that. and yes, i'm gonna post some photos as soon as i'm done compiling.

[dsimic]

Your results are very good!  Looking forward to the pictures.

I agree, there's no need to go overboard with a cooling solution, but the bad effects of the heat soak are the main cause for my attempts to improve the cooling.  The overheating of the BQ24171 makes the PineBook Pro almost unusable for long compilation jobs.

Spreading the generated heat better over the back cover is exactly what I'm looking for, and, quite frankly, there's nothing more that could be done in the space available under the back cover.  Also, nothing more is really needed either.

I've already bought a couple of flat heatpipes, so they're worth a try.  Also, affixing the heatpipes requires less thermal epoxy than what's required for affixing a rather large piece of sheet metal.  Although, I'm not sure if the approach with heatpipes is going to be less expensive in the end.

By the way, my plan is to use Phobya thermal epoxy.

[generaleramon]

Your results are very good!  Looking forward to the pictures.

I agree, there's no need to go overboard with a cooling solution, but the bad effects of the heat soak are the main cause for my attempts to improve the cooling.  The overheating of the BQ24171 makes the PineBook Pro almost unusable for long compilation jobs.

Spreading the generated heat better over the back cover is exactly what I'm looking for, and, quite frankly, there's nothing more that could be done in the space available under the back cover.  Also, nothing more is really needed either.

I've already bought a couple of flat heatpipes, so they're worth a try.  Also, affixing the heatpipes requires less thermal epoxy than what's required for affixing a rather large piece of sheet metal.  Although, I'm not sure if the approach with heatpipes is going to be less expensive in the end.

By the way, my plan is to use Phobya thermal epoxy.

here you go, i now added that green 2,5W/mK pad to cool the components under the shield. The entire area should now dissipate heat on the back cover.

[dsimic]

Good job! This should take care of the heat soak. Have you noticed any issues with battery charging while compiling the Linux kernel source?

[generaleramon]

sure, i mean.. i noticed that the battery wasn't charging while compiling, the charging icon on the toolbar is active but the battery level is going down... my idea was that the problem was the charging circuit , as it seems to be limited to 3A(?), so 15W (5v*3A). I'm using a 4A charger btw.

[dsimic]

Sorry, my question wasn't precise enough...  Was the red LED next to the barrel port blinking while you were compiling the kernel source?  Blinking red LED indicates that the BQ24171 is overheating, no longer charging the battery.

You're right, PineBook Pro cannot take more than 3 A at 5 V from any of its two power inputs.  Please, have look at this thread, which describes the limitations of the PineBook Pro's battery charging circuitry, together with some possible solutions.