+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: General Discussion on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=112)
+--- Thread: The RK3399 Overclock/Undervolt/Voltages Thread (/showthread.php?tid=13506)
RE: RK3399 OC-UV Voltage Limits - generaleramon - 04-26-2021
(04-26-2021, 03:54 PM)coetzeesg Wrote: 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.
RE: RK3399 OC-UV Voltage Limits - generaleramon - 05-23-2021
(04-20-2021, 08:43 AM)dsimic Wrote: 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>;
};RE: RK3399 OC-UV Voltage Limits - dsimic - 05-23-2021
(05-23-2021, 09:05 AM)generaleramon Wrote: 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.
(05-23-2021, 09:05 AM)generaleramon Wrote: Btw, this is my .dtsi at the moment. Running 1704Mhz / 2208Mhz / 1100Mhz and stable
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.
RE: RK3399 OC-UV Voltage Limits - generaleramon - 05-24-2021
@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
RE: RK3399 OC-UV Voltage Limits - dsimic - 05-24-2021
(05-24-2021, 06:22 AM)generaleramon Wrote: 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.
(05-24-2021, 06:22 AM)generaleramon Wrote: 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.
(05-24-2021, 06:22 AM)generaleramon Wrote: 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.
RE: RK3399 OC-UV Voltage Limits - generaleramon - 05-25-2021
@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
RE: RK3399 OC-UV Voltage Limits - generaleramon - 05-25-2021
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/EDAN35/guestLectures/ARM-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
RE: RK3399 OC-UV Voltage Limits - dsimic - 06-04-2021
(05-25-2021, 10:30 AM)generaleramon Wrote: 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.
(05-25-2021, 10:30 AM)generaleramon Wrote: 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.
RE: The RK3399 Overclock/Undervolt/Voltages Thread - generaleramon - 06-05-2021
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
RE: The RK3399 Overclock/Undervolt/Voltages Thread - dsimic - 06-05-2021
(06-05-2021, 03:17 PM)generaleramon Wrote: ==> 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.
(06-05-2021, 03:17 PM)generaleramon Wrote: 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_tempWith 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.