1.3GHz

[stuartiannaylor]

I am presuming the Rock64 max clock speed is set in the DTS.

I just wondered if 1.3GHz had been chosen as a safe level without cooling as the Rock64 is supplied.
Did anyone do any testing with passive and active cooling at higher clock speeds or did 1.3GHz seem to be the limit.

I am presuming with the 1.5Ghz rating its a junction temperature cooling decision and wondered if a kernel/image might be supplied at higher clockspeeds for those who want to employ increased cooling solutions.

Overclocking is not recommended;

however,  its your board.  You can do as you like with it-- but the images need to be provided for best engineering practices. As always with any good engineering setup, somebody will always want to experiment with overclocking even though its a dangerous practice that reduces the life of the processor and is prone to processing instabilities;  anyone is free to over-clock to their hearts content.

IMHO, intelligent operation of the system should always employ the proper ondemand scaling governor ( or other scaling governors as required ) so that the system is not always cranking at the "hottest" .  Over-clocking almost always introduces instability and an element of uncertainty;  as well diminishing returns.

Do as you will.

The RK3328 is a 1.5Ghz device, so essentially we are not overclocking.
[font=Arial, 宋体,]"Quad-Core Cortex-A53,up to 1.5GHz" is how rockchip advertise the RK3328.
[/font]
Its why I was asking about the current chosen 1.3Ghz and was that to provide a safe platform with no cooling?
The Rock64 has been supplied under clocked and expect this can be tweaked is maybe the engineering practices employed where to allow the use of bare chips.

---

pretty sure there's a usr/local/sbin script where you can have all the freq fun you want.

Not sure as I think the options are set in https://github.com/ayufan-rock64/linux-u...k3328.dtsi

Code:

cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;

opp@408000000 {
opp-hz = /bits/ 64 <408000000>;
opp-microvolt = <950000>;
clock-latency-ns = <40000>;
opp-suspend;
};
opp@600000000 {
opp-hz = /bits/ 64 <600000000>;
opp-microvolt = <950000>;
clock-latency-ns = <40000>;
};
opp@816000000 {
opp-hz = /bits/ 64 <816000000>;
opp-microvolt = <1000000>;
clock-latency-ns = <40000>;
};
opp@1008000000 {
opp-hz = /bits/ 64 <1008000000>;
opp-microvolt = <1100000>;
clock-latency-ns = <40000>;
};
opp@1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1225000>;
clock-latency-ns = <40000>;
};
opp@1296000000 {
opp-hz = /bits/ 64 <1296000000>;
opp-microvolt = <1300000>;
clock-latency-ns = <40000>;
};
};

I think that sets the max that you could call from a script.
I just have a hunch that all the engineering has been on the assumption of passive cooled set-top boxes.
Maybe with a squeeze and active cooling you could ramp things up, but I think it would have to be added here.