How to control FAN on Rockpro64?

[Dunc4n1d4h0]

Hi,

 

Is fan control still broken?

Linux rockpro64 5.7.15-rockchip64 #20.08 SMP PREEMPT Mon Aug 17 00:26:28 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux

echo 255 > /sys/devices/platform/pwm-fan/hwmon/hwmon2/pwm1
echo 0 > /sys/devices/platform/pwm-fan/hwmon/hwmon2/pwm1

Commands line above work, but writing anything between (like 240, 200, etc.) does not.

I can hear noise imho coming from fan coils when I write 253 to pwm1, maybe it's pwm frequency too high/too low?

I checked two different 80x80mm fans, same result.

Fans start to spin connected to DC ~4V, so they should work for sure.

 

From kernel side there is pwm-fan module, but it can't take any parameters imho.

Every kernel version I checked comes with it's own values (lol), for. example:

https://github.com/ayufan-rock64/linux-kernel/pull/40/commits/5d9fbef9cfa01846dd0b4d66249df55c85fa344f

 

[soerenderfor]

@Dunc4n1d4h0 - you could use tux3dv fan control and edit your own pwm-fan in it? What do you think, is it an idea you could use? Please report back, thanks.

[Dunc4n1d4h0]

@soerenderfor

I already tried tux3dv fan cotrol. Well, it isn't magic box :-)

What it does is to read from /sys/devices/virtual/thermal/thermal_zone*/temp and  write values from curve build from config f.e. 100..255 into /sys/devices/platform/pwm-fan/hwmon/hwmon*/pwm1.

All of this can be done manually.

It uses pwm-fan kernel module. If you unload this module there is no more /sys/devices/platform/pwm-fan/hwmon/hwmon* and fan stops.

 

Real problem here is lack of customization in this module. In 5.7.15 version there is hardcoded 50kHz pwm frequency - which simply won't work with all 2-wire fans.

Decent DC fans aren't simple motors, such fan has microcontroller which task is to deliver AC current in correct time to coils. Since there is no control with in 2-wire fan, 50% square pwm signal simply turns on/off whole circuit (at low frequency). All you can get at high frequency is fan working at full or zero speed.

Good solution would be to add paremeter to pwm-fan module for setting pwm-freqeuncy.

 

Meanwhile I searched alot and found solution for my fan :-)

 

rmmod pwm-fan
echo 0 > /sys/class/pwm/pwmchip1/export
echo 40 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle
echo 100 > /sys/class/pwm/pwmchip1/pwm0/period
echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable

What is does:

- remove useless kernel module and unlock pwmchip

- write to export creates subfolder to control pwm

- 40/100 - set frequency to 100Hz and duty_cycle to 40% (so we have low pwm frequency and square vawe fulfillment of 40%)

 

It works, fan speed can be controlled in much higher range, no more jet turbine dB level :-)

 

PS.

I used Sunon fans for test:

https://www.tme.eu/Document/b6f8c2a3813918913726d12d942d1b83/EE80151S1-A99.pdf

https://www.tme.eu/Document/d44c6feef6683af4934c9d10cdd59c2e/ME80201V1-A99.pdf

 

IMHO RockPro64 fan solution is bad desing. It should be programmable DC output for 2 wire, or 4-wire nice pwm like we have in PC.

[soerenderfor]

@Dunc4n1d4h0 - I can see it could help a lot of people, if you have time and want to help. Maybe you could write a little guide? Thanks.

[soerenderfor]

@Dunc4n1d4h0 - So if you want to change fan speed UP or DOWN?

echo 40 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle

Then this one goes from 40 to 100? Or? Thanks.

[Dunc4n1d4h0]

@soerenderfor

 

 

echo 100 > /sys/class/pwm/pwmchip1/pwm0/period - this is 100% (at frequency of 100Hz)

echo 40 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle  - 40 here is 40% of 100

 

Period is cycle frequency, duty is percentage of this cycle filled with logical 1, here 12V, so at 100Hz cycle is 10ms, 4ms signal is 12V and 6ms its 0V

 

echo 500 > /sys/class/pwm/pwmchip1/pwm0/period - this is 100% (at frequency of 500Hz)

echo 250 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle  - 250 here is 50% of 500

 

 

No problem :-)

 

Edited September 15, 2020 by Dunc4n1d4h0

[Dunc4n1d4h0]

P.S.

It's good to set duty_cycle first, as you can't set period lower than duty_cycle - you'll get "permission denied".

[soerenderfor]

@Dunc4n1d4h0 - And how to clear the settings, if the commands have been typed in once? And wants to change it?

[Dunc4n1d4h0]

1 hour ago, soerenderfor said:

@Dunc4n1d4h0 - And how to clear the settings, if the commands have been typed in once? And wants to change it?

 

@soerenderfor AFAIR:

echo 0 > /sys/class/pwm/pwmchip1/unexport
modprobe pwm-fan

 

Edited September 15, 2020 by Dunc4n1d4h0

[soerenderfor]

@Dunc4n1d4h0 - Thanks, i will look at it tommorw, and pinn the thread.

[usual user]

The right way to use the fan would be to have a proper thermal setup (rk3399-rockpro64-tz.dts) in the devicetree. With this the kernel thermal system can handle the management.

This is a visualisation of a tmon log documenting the working of the thermal system:

Spoiler

rk3399-rockpro64.dtb is a mainline dtb with rk3399-rockpro64-tz.dtbo applied via:

fdtoverlay --input rk3399-rockpro64.dtb --output rk3399-rockpro64.dtb rk3399-rockpro64-tz.dtbo

See if this is working for you by replacing your dtb and check with tmon.

[Dunc4n1d4h0]

For me problem here is hardcoded pwm frequency;

 

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi  line 61

 

	fan: pwm-fan {
		compatible = "pwm-fan";
		#cooling-cells = <2>;
		fan-supply = <&vcc12v_dcin>;
		pwms = <&pwm1 0 50000 0>;
	};

Fans I tested work at low frequencies, below 1000 Hz.

[usual user]

9 hours ago, Dunc4n1d4h0 said:

For me problem here is hardcoded pwm frequency

There is nothing hardcoded, there is only a default value. And as one value does not fit them all, you have to set it to the value that fits your need. See rk3399-rockpro64-tz.dts for reference. Unfortunately you cannot apply this with mainline ftdoverlay because it does not support full path notion for a reference to another node. But with fdt_overlay.patch.txt applied it is working as expected.

[soerenderfor]

@usual user - Do i understand you correct. Lets say if i want to change Hz as @Dunc4n1d4h0 suggests, it can be changed in dts, if fdt_overlay_patch.txt is applied? If you have time, it could be very helpful if you can explain it in another way. Thanks.

[Dunc4n1d4h0]

8 hours ago, usual user said:

There is nothing hardcoded, there is only a default value. And as one value does not fit them all, you have to set it to the value that fits your need. See rk3399-rockpro64-tz.dts for reference. Unfortunately you cannot apply this with mainline ftdoverlay because it does not support full path notion for a reference to another node. But with fdt_overlay.patch.txt applied it is working as expected.

 

My bad, hardcoded default value.

Long time ago I used kernel module parameters. There are none in pwm-fan module.

Please, tell me how to change that to value that fits my needs? :-) (Other way that I use to write values to /sys/*)

 

Regards

[soerenderfor]

@Dunc4n1d4h0 - To go from dtb to dts, edit and make to dtb again, is something like.

dtc -I dtb -O dts -f rk3399-rockpro64.dtb -o test.dts
code testfile.dts
dtc -I dts -O dtb -f test.dts -o rk3399-rockpro64.dtb

 

Edited September 17, 2020 by soerenderfor
Spelling

[usual user]

13 hours ago, soerenderfor said:

can explain it in another way

ftdoverlay is a convenient way to apply an overlay staticly to a base dtb. You spare the DTC decompile - manually edit - DTC compile dance. Usually you write overlays with label refernces, but to be able to apply such an overlay, the base dtb has to be compiled with the @-option. This has significant impact on the size and distributions usually don't do this. When you write the overlay with full paths, it contains all the information to be applied to a base dtb that was not created with the @-option. The mainline ftdoverlay need the patch to be able to apply it.

 

13 hours ago, Dunc4n1d4h0 said:

Please, tell me how to change that to value that fits my needs

Edit the pwms property to any value you like as shown in the provided rk3399-rockpro64-tz.dts (50000 default changed to 10000).

[Guest]

Hi all ,

 

I'm also interested in this topic as I require a 5. kernel to use the marvel PCIe card with the rockpro64 , like the original poster I fan runs continuously and I have no control over it .

 

From reading this thread I have learnt a lot , however I'm trying to work out which is the best solution  or if I even  understand them all .

 

I gather that although the ATS option can be made to work on a newer kernel its not a good option because a hard-coded default 50Hz is not ideal  for the standard 80mm  pine64 fan.

I always understand by removing the PWM module as @Dunc4n1d4h0 suggests and control the fan  manually with the caveat that it runs continuously albeit at a defined frequency and duty cycle ( I'm new to all this and suggestions are that running the fan continuously is better for a NAS use case) .

 

The final solution is one that I sort of understand but in relative terms I'm still a noob with Linux, so as I understand it you use the default pwn fan module create a file rk3399-rockpro64-tz.dts  in the boot directory along with the file  fdt_overlay.patch.txt , install the fdtoverlay tool as linked by the @usual user GitHub issue and  using fdt_overlay.patch.txt overlay the existing rk3399-rockpro64.dtb with rk3399-rockpro64-tz.dts  that provides an editable option to control the fan duty cycle or frequency ,depending on the temp  similar to ATS solution but the kernel manages it instead of a script .

 

any direction , advice or information  would be appreciated

 

thanks in advance

[soerenderfor]

@GreyLinux - I just did put the fan settings in /etc/rc.local the fan runs always but nearly silent.

 

My 4xHDD temps runs very low, between 34-36° the SSD hits 37-39°

 

I did mange to fit 5 disks in the NAS case. 

 

What sata card do you have? 

[usual user]

2 hours ago, GreyLinux said:

any direction , advice or information  would be appreciated

For a first test replace your rk3399-rockpro64.dtb by the one provided in this  post. 

If your original dtb is carriing different configuration you can use the fdtoverlay method to apply rk3399-rockpro64-tz.dtbo (build from rk3399-rockpro64-tz.dts) static to your base dtb. This will work with mainline fdtoverlay without modification. Using it as dynamic overlay should also work.
The second rk3399-rockpro64-tz.dts post was only to showcase how to change a value of an existing binding.

[Guest]

22 hours ago, soerenderfor said:

@GreyLinux - I just did put the fan settings in /etc/rc.local the fan runs always but nearly silent.

 

My 4xHDD temps runs very low, between 34-36° the SSD hits 37-39°

 

I did mange to fit 5 disks in the NAS case. 

 

 

 

I think this is the route I will go , after a little bit of thought , I concluded that with my setup of 2 SSD's , the 80mm case fan and a tall heatsink, I would benefit more from just trying to keep everything cool rather than just having the fan work when the CPU is getting a little hot.

I'll have to do some testing to discover the most optimum  setting for the fan to keep everything cool but not too noisy.

 

I am however , still  intrigued with the overlay concept and so I will be doing further research into this as I think its an interesting topic that I haven't really given much thought to before. I've discovered that it features quite heavily when you begin to get serious with arm based SBC's and therefore will prove useful in learning.

 

Out of interest @soerenderfor what value did you find worked for your setup to keep the temps that low with such a full case ?

 

Quote

What sata card do you have? 

 

I decided on the Marvell 88SE9230 this one to be exact

 

I hoping, although I haven't done any serious testing, that this removes the errors I was getting with the pine64 PCIe card, w hich eventually mounted my drives as read only, before remounting them as different drive devices.

 

thanks for advice , much appreciated .

[soerenderfor]

@GreyLinux - That sata card is indeed a very good choice, i have now run with same card, just with 5 ports. Rock solid, i havent had any down time at all. I have installed a 92mm Noctua fan, i did cut the hole bigger. But before that i did run with a 80mm Noctua fan, it is indeed 25mm deep, but it can fit. The one sold as orginal is around 14mm or so. 

The fan runs very low rpm.
 

rmmod pwm-fan
echo 0 > /sys/class/pwm/pwmchip1/export
echo 110 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle
echo 500 > /sys/class/pwm/pwmchip1/pwm0/period
echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable

in /etc/rc.local

My case is full as in very full ;-) now i run with 2x6TB 2x4TB 1x1TB SSD (SSD is fastned with strips between a 3.5" drive and a 2.5" drive). The SSD runs the system and boots from port "5" - with auyfan uboot. I always run with armbian mainline kernel, and OMV installed. 

How is that card for you? I have tested around 10 cards. And runs with the same card as you besides my card has 5 ports, and it is the best of all the cards. The expensive cards have been a sad expereince.

[Guest]

On 10/20/2020 at 9:04 PM, soerenderfor said:

rmmod pwm-fan echo 0 > /sys/class/pwm/pwmchip1/export echo 110 > /sys/class/pwm/pwmchip1/pwm0/duty_cycle echo 500 > /sys/class/pwm/pwmchip1/pwm0/period echo 1 > /sys/class/pwm/pwmchip1/pwm0/enable in /etc/rc.local

 Perfect at least I have base few value to start my testing from and see if I need to adjust to suit my setup .

 

On 10/20/2020 at 9:04 PM, soerenderfor said:

How is that card for you? I have tested around 10 cards. And runs with the same card as you besides my card has 5 ports, and it is the best of all the cards. The expensive cards have been a sad expereince.

 Yeah I think it's an excellent card so far as I say I haven't yet managed to do any real intensive testing, but as you say it's given me zero down time so far compared to the pine64 standard card, which wouldn't take much to upset and then I would need to spend 20 minutes fixing every few days. The rest of the NAS case hardware ( quality speaking ) and of course the rockpro64 itself are brilliant especially for the price point .

 

I made sure I did a lot of research before purchasing the marvell 88SE9230 and  so far it's the perfect companion to the NAS case and rockpro setup .

[soerenderfor]

@GreyLinux - You could purcahse a Noctua FLX 80mm fan, and heat will not be a problem, if you have such.

[Mathias]

@soerenderforFrom what you write, I have a feeling that an old problem of mine could be solved... I currently have an HDD connected to the Pine Sata adapter and an SSD connected to the USB3 port since putting these two drive on the sata adapter lead to catastrophic failures (major file system corruption). At the time, I got convinced that my HDD was drawing too much power, so it could not share the power lines with the SSD: see

 

So, it now seems that by buying a different sata adapter (like the one that was mentioned based on the marvell 88SE9230), I should be able to have both drives connected to the sata adapter in my nas box? (I'm still kind of scared of trying, since last time I had to restore huge amounts of data from backups, the drives were totally messed up).

[soerenderfor]

@Mathias - I do run all drives from the sata adapter cables from pine store. Maybe some sort of a "dirty setup" - But hey, it works no down time at all. Hmm... Will some pictures help, from inside the my nas case?

[Mathias]

@soerenderforSo, you have the pine store pcie <-> sata adapter, the pine store cables and then 5 drives into your nas box and the whole thing is rock solid, if I understand correctly?

[soerenderfor]

@Mathias - The Sata pcie card is this one with the power cables from pine store, and from one of the power cables to this splitter - So now you have 5 power cables so to speak. 

- I use the upper sata port (5) to boot my ssd up from, auyfan' uboot can boot from that port.

ROCK solid, no down time. Only on kernel updates ;-) Just updated to 5.8.16

12V 10A power adapter.

[JackR]

Those interested to have the fan speed (pwm duty) regulated by cpu and disks temperatures may adapt the script from this post:

https://forum.armbian.com/topic/11086-pwm-fan-on-nanopi-m4/?do=findComment&comment=110117

 

[soerenderfor]

@JackR - Looks interresting, could be very cool.