The RK3399 Overclock/Undervolt/Voltages Thread

[generaleramon]

I was wondering if you could describe the thickness of the shim + pad to touch the bottom panel, and the pad thickness being used to connect the other ICs to the spreader around the cpu. I'm trying to buy some thermal pads + shims in anticipation of a new pinebook pro arriving shortly.

Well, the copper shim is 2mm thick, the pad 0.5mm, and the first metal plate/shim i glued was ~3mm if i remember right, so you need almost 6mm total. I think k used two layers of 1mm thick pad under the shield, so another ~2mm there.

[generaleramon]

Sounds good!  It is expected that reducing the thermal pad thickness, using a copper shim, would result in better heat transfer.

i'm compiling a lot recently and i noticed that the red led blinks sometimes, do you know if it is just temp related or it can be an over-current protection? The SoC is now drawing 11W+ and almost touching 75c

Btw, this is my .dtsi at the moment. Running 1704Mhz / 2208Mhz / 1100Mhz and stable i'm pretty sure that ram bandwidth is holding the SoC back now

Code:

/*
* Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
*/

/ {
    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 = <725000>;
        };
        opp01 {
            opp-hz = /bits/ 64 <400000000>;
            opp-microvolt = <750000>;
        };
        opp02 {
            opp-hz = /bits/ 64 <500000000>;
            opp-microvolt = <800000>;
        };
        opp03 {
            opp-hz = /bits/ 64 <600000000>;
            opp-microvolt = <850000>;
        };
        opp04 {
            opp-hz = /bits/ 64 <800000000>;
            opp-microvolt = <1025000>;
        };
        opp05 {
            opp-hz = /bits/ 64 <900000000>;
            opp-microvolt = <1100000>;
        };
        opp06 {
            opp-hz = /bits/ 64 <1000000000>;
            opp-microvolt = <1175000>;
        };
        opp07 {
            opp-hz = /bits/ 64 <1100000000>;
            opp-microvolt = <1275000>;
        };
    };
};

&cpu_l0 {
    operating-points-v2 = <&cluster0_opp>;
};

&cpu_l1 {
    operating-points-v2 = <&cluster0_opp>;
};

&cpu_l2 {
    operating-points-v2 = <&cluster0_opp>;
};

&cpu_l3 {
    operating-points-v2 = <&cluster0_opp>;
};

&cpu_b0 {
    operating-points-v2 = <&cluster1_opp>;
};

&cpu_b1 {
    operating-points-v2 = <&cluster1_opp>;
};

&gpu {
    operating-points-v2 = <&gpu_opp_table>;
};

[dsimic]

i'm compiling a lot recently and i noticed that the red led blinks sometimes, do you know if it is just temp related or it can be an over-current protection? The SoC is now drawing 11W+ and almost touching 75c

As far as I can see, the primary reason for the red LED to start blinking is the overheating of the battery charging IC, BQ24171; the datasheet describes the STAT output and the status LED on pages 5, 17, 18, 23 and 24.  The conditions that cause the battery charging to be suspended because of the battery temperature, and the conditions required to enable or disable the battery charging in general, are described on page 9 and page 18 of the BQ24171 datasheet, respectively. 

Another reason for the red LED to start blinking could be that the battery starts to overheat under load, but that doesn't seem plausibe to me, especially because I've never felt that the part of the back cover above the battery becomes even lukewarm.

Here's what the above-described conclusion has been based on:

• As configured in the PineBook Pro, the BQ24171 is nowhere near its charging current limit, which can go up to 4 A, but the battery charging current is configured (using the BQ24171's ISET pin) to stay at or below 3.3 * (20 / (20 + 100)) / 0.2 = 2.6 A.
  
• The PineBook Pro always takes power from the battery, instead of directly from any of the two power inputs, so no overcurrent protection in the BQ24171 should be taking place, unless the battery is faulty, of course.  This pretty much follows the reference design available on page 28 of the BQ24171 datasheet.  In other words, the BQ24171 is configured to just keep topping up the battery, and the battery provides additional power even when a charger is plugged into the laptop.
  
• When the red LED starts blinking, it doesn't return back to solid red until the cooling of the underside of the laptop is improved, nine times out of ten.
  

As an unfortunate result of the first two bullet points, the most power that the PineBook Pro can effectively consume from any of its power inputs, without reaching into discharging the battery, is around 11.4 W (2.6 A at around 2.1 / (100 / (107 + 100)) = 4.37 V, which is the battery voltage when fully charged), despite the fact that the barrel port, for example, can provide 3 A at 5 V, which equals to 15 W.  Could you, please, use the BQ24171 datasheet and page 11 of the PineBook Pro schematic to verify this and correct me if I'm wrong?

What really s*cks is that the BQ24171 pretty much cannot be made visible to the software, and its configuration is performed using resistors.   This also means that it's impossible to check the current temperature of the battery in software.  The only way to communicate with it is to observe the red LED; however, the pin that drives the status LED could be connected to a GPIO line of the RK3399.

Is the BQ24171 in your PineBook Pro still in touch with the back cover, using the thermal pads you've previously applied?  If so, it might be worth trying to reduce the thickness of that thermal pad, using a square piece of aluminum sheetmetal affixed to the back cover, right above the BQ24171.

Btw, this is my .dtsi at the moment. Running 1704Mhz / 2208Mhz / 1100Mhz and stable i'm pretty sure that ram bandwidth is holding the SoC back now

Those are some rather serious overclocks.

Edit: More precisely, the above-stated limit of 11.4 W should be the limit for what the BQ24171 can put into the battery, while the total power draw from one of the two power inputs should be a little higher, due to the losses inside the BQ24171.

[generaleramon]

@dsimic
i'm looking at the schematics and it seems to me that both VCC_SYSIN and VCC_BAT+ are connected at the output of the BQ24171, VCC_SYSIN is used by the RK808-D and so on for powering a lot of the components and SoC parts. I guess that it can't charge the battery and power the Soc@Fullpower without overheating, i'm sure i placed some thermalpads between the IC and the metal "shield" around the SoC, but none between shield and backcover, with a 90%+ efficiency and around 11W output it should dissipate slightly over 1W @full load, weird that it seems to require this much cooling

[dsimic]

i'm looking at the schematics and it seems to me that both VCC_SYSIN and VCC_BAT+ are connected at the output of the BQ24171, VCC_SYSIN is used by the RK808-D and so on for powering a lot of the components and SoC parts.

Yes, VCC_SYSIN is the main power rail/source for the PineBook Pro, taking power from the BQ24171's output or from the battery. 

I guess that it can't charge the battery and power the Soc@Fullpower without overheating, i'm sure i placed some thermalpads between the IC and the metal "shield" around the SoC, but none between shield and backcover

Could you, please, try adding an additional thermal pad between the RF can/shield and the back cover of the laptop, right above where the BQ24171 sits below the shield, so the BQ24171 becomes in direct thermal contact with the back cover?  An aluminum "shim" could also be useful, to reduce the overall thickness of the thermal pad.

with a 90%+ efficiency and around 11W output it should dissipate slightly over 1W @full load, weird that it seems to require this much cooling

Based on the efficiency charts that are available on page 14 of the BQ24171 datasheet, the efficiency at which the BQ24171 operates inside the PineBook Pro should be anywhere between 92% and 89%, so you were very close.

The way I explain the need for additional cooling for the BQ24171 is the heat soak from the RK3399 SoC.  The SoC heats up quite a lot under load, and some of the generated heat inevitably gets soaked into the PCB and the surrounding components.  Guess who's one of the SoC's neighbors?  The poor little BQ24171.   As a result, the BQ24171 operates in a rather warm environment, which certainly makes it run much hotter than if it were just dissipating around 1 W of its own heat.

Edit: As a comparison, everybody complained when AMD chipsets started requiring active cooling, which was caused by the heat dissipation of the chipsets going over 3 W, if I remember correctly.  If we compare large heatsinks that all chipsets received, and the size of our little buddy, BQ24171, it should be no wonder why the BQ24171 doesn't run cool in the PineBook Pro.

[generaleramon]

@dsimic
i placed a piece of thermal pad between the shield and the backcover now to press it down and be sure to have more contact, i'll report back after compiling the kernel again. i can't believe that it needs more than that, BUT, worst case, i'm gonna put some thermal glue and a real heatsink on it an call it a day

NEWS: i found out how to overclock the CCI(CCI-500,CoreLink Cache Coherent Interconnect, so it works like the infinity fabric in AMD Ryzen CPUs).
in the rk3399.dtsi file "cru ACLK_CCI" is set to 600Mhz (Thanks to this GitHub Commit), i upped it to 800Mhz and i instantly gained 150-200MB/s in memcpy(3550MB/s) and memset(8200MB/s).
The entire SoC should benefit as the CCI manage all the data flow and cache/memory coherency. Still no idea if it is 100% stable and if i can push it more, i need time .
This little RK3399 is becoming a beast

[generaleramon]

i'm working on other clocks too

Code:

<&cru ACLK_PERIHP> 150000000 <AXI?
<&cru HCLK_PERIHP> 75000000 <AHB
<&cru PCLK_PERIHP> 37500000 <APB

<&cru ACLK_PERILP0> 100000000 <AXI?
<&cru HCLK_PERILP0> 100000000 <AHB
<&cru PCLK_PERILP0> 50000000 <APB

<&cru HCLK_PERILP1> 100000000 <AHB
<&cru PCLK_PERILP1> 50000000 <APB

###

AXI Coherency Extensions (ACE and ACE-Lite)
Advanced eXtensible Interface (AXI)
Advanced High-performance Bus (AHB)
Advanced Peripheral Bus (APB)

PERIHP i guess is peripheral high performance
PERILP0 must be peripheral low power/performance 0
PERILP1 peripheral low power/performance 1
i still don't know what kind of devices are attached, i'm guessing that the Mali GPU use the HP one(Edit: Nope)

Looking at slide 12 (https://fileadmin.cs.lth.se/cs/Education...M-Mali.pdf), i think that the APB is used as a command bus, while AXI and AHB are used for moving data
the AHB bus usually run at 1/4-1/2-1/1 the APB speed

###
Edit: Testing the CCI@1Ghz, gained another 25-50MB/s and the latency is lower. I'm gonna run some benchmarks and post some graphs
###
Edit v2: Testing CCI@1.2Ghz(+100% over Stock), getting around 3580MB/s memcpy and amost 8500MB/s memset. No stability problems
###
Edit v3: Currently running these seconday clocks, stable at the moment, no gains from increasing PERIHP/PERILP. I tested PERIHP@800+400+200Mhz and the GPU performs the same, no idea what is connected to that bus

Code:

<&cru ACLK_PERIHP> 160000000
<&cru HCLK_PERIHP> 80000000
<&cru PCLK_PERIHP> 40000000

<&cru ACLK_PERILP0> 120000000
<&cru HCLK_PERILP0> 120000000
<&cru PCLK_PERILP0> 60000000

<&cru ACLK_CCI>     1200000000

<&cru HCLK_PERILP1> 120000000
<&cru PCLK_PERILP1> 60000000

###
Memory Latency CCI@600s1200Mhz >    
Memory Bandwidth CCI@600s1200Mhz >     

7Zip Multithread-Benchmark

Code:

###600Mhz CCI
7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE)

RAM size:    3863 MB,  # CPU hardware threads:  6
RAM usage:  2427 MB,  # Benchmark threads:      6

                   Compressing  |                Decompressing
Dict    Speed Usage R/U Rating  |    Speed  Usage R/U  Rating
        KiB/s   %   MIPS  MIPS  |    KiB/s    %   MIPS  MIPS

22:      5735  537  1039  5579  |    113140  520  1857  9649
23:      5651  538  1070  5759  |    109899  516  1843  9510
24:      5594  537  1120  6015  |    107651  517  1826  9449
25:      5658  555  1165  6460  |    106508  521  1821  9479
26:      4810  560  1047  5862  |    103084  515  1806  9299
------------------------------  | ------------------------------
Avr:           545  1088  5935  |            518  1831  9477
Tot:           532  1459  7706

###1200Mhz CCI
7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE)

RAM size:    3863 MB,  # CPU hardware threads:  6
RAM usage:  2427 MB,  # Benchmark threads:      6

                   Compressing  |                Decompressing
Dict    Speed Usag  R/U Rating  |     Speed Usage R/U Rating
        KiB/s    %  MIPS  MIPS  |     KiB/s   %   MIPS  MIPS

22:      5806  509  1109  5648  |    113446  524  1848  9675
23:      5880  532  1126  5992  |    111277  524  1839  9629
24:      5913  553  1150  6359  |    108983  526  1819  9566
25:      5586  522  1221  6378  |    101429  490  1843  9027
26:      5071  563  1098  6180  |    104759  520  1816  9450
------------------------------  | ------------------------------
Avr:           536  1141  6111  |            517  1833  9469
Tot:           526  1487  7790

###
Edit v4: No, 1400Mhz is not improving performance, i'm starting to see some regression, i guess because of some form of build-in ECC

[dsimic]

i placed a piece of thermal pad between the shield and the backcover now to press it down and be sure to have more contact, i'll report back after compiling the kernel again. i can't believe that it needs more than that, BUT, worst case, i'm gonna put some thermal glue and a real heatsink on it an call it a day

Have you managed to test the behavior of BQ24171 again, after you've added the thermal pad?  I doubt that adding a small heatsink to the BQ24171 would help, simply because there's no air movement inside the laptop case.  IMHO, the best we can do is to bring the BQ24171 in contact with the back cover and use it as a heatsink.

I'll use an IR thermometer to measure the actual temperatures that the BQ24171 reaches while all of the CPU cores are under heavy load, which will clearly show is the overheating of the BQ24171 the reason why the red LED starts flashing and the battery charging stops.  I still need to figure out how to attach a heatsink (and keep it attached) to the RK3399 with the back cover removed, which I need to remove to be able to use the IR thermometer.

NEWS: i found out how to overclock the CCI(CCI-500,CoreLink Cache Coherent Interconnect, so it works like the infinity fabric in AMD Ryzen CPUs).  in the rk3399.dtsi file "cru ACLK_CCI" is set to 600Mhz (Thanks to this GitHub Commit), i upped it to 800Mhz and i instantly gained 150-200MB/s in memcpy (3550MB/s) and memset (8200MB/s). The entire SoC should benefit as the CCI manage all the data flow and cache/memory coherency. Still no idea if it is 100% stable and if i can push it more, i need time .

Those are very interesting results, thumbs up!  Any chances, please, to provide the "make -j6" timing results for the kernel compile at 100% stock settings, and with the highest overclocks you've achieved so far?  I'd be very interested to see those numbers.

[generaleramon]

Here is the first result with my config : 4xA53@1704Mhz / 2xA72@2208Mhz / GPU@1100Mhz / CCI-500@1200Mhz
I'm compiling on a decent SD card, not the internal eMMC

==> Finished making: linux 5.12.9-99 (Sat 05 Jun 2021 23:10:05 CEST)
real 213m31.122s
user 1047m18.520s
sys 76m19.904s


and yeah, i'll work a bit more on the cooling of that BQ24171, a fan blasting air at the backcover seem to mitigate the blinking led problem

[dsimic]

==> Finished making: linux 5.12.9-99 (Sat 05 Jun 2021 23:10:05 CEST)
real    213m31.122s
user    1047m18.520s
sys    76m19.904s

Could you, please, run the same kernel build on your PineBook Pro with the stock frequencies?  It's a bit hard to do a comparison without that.

and yeah, i'll work a bit more on the cooling of that BQ24171, a fan blasting air at the backcover seem to mitigate the blinking led problem

I've been using my PineBook Pro for a while with the following restrictive thermal throttling parameters applied (kind of anti-overclocking):

Code:

echo 55000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp
echo 70000 > /sys/class/thermal/thermal_zone0/trip_point_1_temp

With those settings in place, I had no red LED blinking even with maximum CPU load, while the CPU temperature always stays below 55 oC.  This pretty much confirms my assumption that the heat soak from the SoC causes the BQ24171 to overheat and stop charging the battery.