Always POWER OFF the system before plug/unplug the fan. Failed to do so could damage the controlling GPIO due to power surge.
## PWM Introduction
PWM, or pulse width modulation is a technique which allows us to adjust the average value of the voltage that’s going to the electronic device by varying duty cycle of the power at a fast rate.
The term *duty cycle* describes the proportion of 'on' time to the regular interval or 'period' of time; a low duty cycle corresponds to low power, because the power is off for most of the time. Duty cycle is expressed in percent, 100% being fully on. When a digital signal is on half of the time and off the other half of the time, the digital signal has a duty cycle of 50% and resembles a "square" wave. When a digital signal spends more time in the on state than the off state, it has a duty cycle of >50%. When a digital signal spends more time in the off state than the on state, it has a duty cycle of <50%.Hereisapictorialthatillustratesthesethreescenarios:
Armada 388 incorporates a Thermal Management engine for monitoring die temperature. It includes an on-die analog-to-digital thermal sensor, that is used to determine when the maximum specified processor junction temperature has been reached.
### Ethernet PHY Thermal Sensor
Helios4's **10/100/1000 BASE-T PHY Tranceiver** ([Marvell 88E1512 Datasheet](http://www.marvell.com/documents/eoxwrbluvwybgxvagkkf/)) features an internal temperature sensor. The sensor reports the die temperature and is updated approximately once per second.
### Board Temp Sensor
Helios4 has a **Digital Temperature Sensor with 2‐wire Interface** ([NCT75 Datasheet](https://www.onsemi.com/pub/Collateral/NCT75-D.PDF)), located on bottom side of the board. It is used to read ambient temperature.
## PWM Fan Control under Linux
Linux use 8-bit integer to represent duty cycle. PWM value 0 represent 0% duty cycle and PWM value 255 represent 100% duty cycle.
Currently Linux gpio-mvebu driver does not allow more than 1 PWM under the same gpio bank. Helios4 uses 2 PWM under same bank therefore [this patch](https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-next/92-mvebu-gpio-remove-hardcoded-timer-assignment.patch) needs to be applied to kernel source to remove the restriction.
The numbering may different from above example output. It depends on whether the driver built as kernel module or built-in, device initialization order. Take this as consideration when using [fancontrol](#fancontrol-automated-software-based-fan-speed-regulation)
To identify which hwmon belong to fan, look for *j10-pwm* and *j17-pwm*. On above example
fancontrol is a shell script for use with lm_sensors. It reads its configuration from a file, then calculates fan speeds from temperatures and sets the corresponding PWM outputs to the computed values.
fancontrol includes *pwmconfig* script to create automatically a configuration file but it can not be used for Helios4.
#### UDEV rules
Since hwmon order can be changed between kernel version or even between reboot, on Armbian we use udev rules as workaround. The rules can be found from [here](https://raw.githubusercontent.com/armbian/build/master/packages/bsp/helios4/90-helios4-hwmon.rules) and to be copy to **/etc/udev/rules.d/**
Maps hwmon class devices to physical devices. This lets fancontrol check that the configuration file is still up-to-date.
It expect the **hwmonN** as symlink to **devices/***
DEVNAME
Records hwmon class device names. This lets fancontrol check that the configuration file is still up-to-date.
Since **armada_thermal** does not create symlink, use *DEVNAME* instead of *DEVPATH*
FCTEMPS
Maps PWM outputs to temperature sensors so fancontrol knows which temperature sensors should be used for calculation of new values for the corresponding PWM outputs.
Fans (**hwmon2** &**hwmon3**) are controlled based on CPU thermal sensor (**hwmon1**) reading.
MINSTART
Sets the minimum speed at which the fan begins spinning. You should use a safe value to be sure it works, even when the fan gets old.
New bundled fan restart at 15, added 5 for safety (in case of aging fan) give us **20**. The value does not affect old bundle fan.
MINSTOP
The minimum speed at which the fan still spins. Use a safe value here, too.
New bundled fan stopped at 24, added 5 for safety (in case of aging fan) give us **29**. The value does not affect old bundle fan.
-----
*Following settings can be adjusted by user to tweak further.*
MINTEMP
The temperature below which the fan gets switched to minimum speed.
Fans (hwmon2 & hwmon3) runs in minimum speed if the CPU temperature below **70** degree C.
MAXTEMP
The temperature over which the fan gets switched to maximum speed.
Fans (hwmon2 & hwmon3) runs in maximum speed if the CPU temperature above **90** degree C.
MINPWM
The PWM value to use when the temperature is below MINTEMP. Typically, this will be either 0 if it is OK for the fan to plain stop, or the same value as MINSTOP if you don't want the fan to ever stop. If this value isn't defined, it defaults to 0 (stopped fan).
Set minimum PWM value to **0**. On new bundled fan, it would stopped the fan while on old bundled fan it would run in minimal speed.
The Helios4 fancontrol configuration file can be found [here](https://raw.githubusercontent.com/armbian/build/master/packages/bsp/helios4/fancontrol_pwm-fan-mvebu-next.conf).
As an alternative to userspace tool like [fancontrol](#fancontrol-automated-software-based-fan-speed-regulation), Linux Kernel provides Thermal Framework to do thermal management.
Below is an example of device tree nodes that can be added to Helios4 device tree to make use of Linux Thermal Framework.
!!! note
Currently *armada_thermal* driver ([CPU Thermal Sensor](#cpu-thermal-sensor)) does not support thermal-zone binding in device tree, therefore it can not be used as thermal-sensor yet.
