Problems with BeagleBoard-X15 GPIO fan control and lm-sensors

I’m working with an X15, and the fan is driving me crazy.

I’m using the recommended heatsink and fan from Digi-Key (the 5V F251R: ). The fan works, but it constantly turns on and off on what seems to be a completely random basis. Has no relationship with actual CPU load, either.

I’m delving into Debian’s fan control package, lm-sensors, and I’ve found this:


…which outputs this:


Adapter: ISA adapter

fan1: 0 RPM (min = 0 RPM, max = 13000 RPM)


Adapter: OMAP I2C adapter

temp1: +41.4°C (high = +160.0°C, hyst = +150.0°C)

That’s certainly informative, but those set points are insane: I don’t want it getting anywhere near 160°C, or even 150°C for that matter. I presume that someone was aiming for Fahrenheit values. These settings also indicate a problem: if tmp102-i2c-0-48 were actually controlling the fan, it would never turn on - it would probably be fried long before it hit either of those values.

The settings command allows me to query both devices for settable properties:


Adapter: ISA adapter


fan1_input: 13000.000

fan1_min: 0.000

fan1_max: 13000.000


Adapter: OMAP I2C adapter


temp1_input: 42.375

temp1_max: 160.000

temp1_max_hyst: 150.000

And I can also change them by creating /etc/sensors.d/x15-config with the following:

chip “tmp102*”
set temp1_max 41
set temp1_max_hyst 39

After either running “sensors -s” to reload settings or just rebooting, the sensors -u command shows that tmp102-i2c has accepted the override values. Unfortunately, it doesn’t affect the annoying fan behavior one bit. Reported CPU temperature is over 41, so it should run constantly until it’s under 39… no dice. Same behavior.

At this point, I can’t figure out what is actually controlling the fan, especially not in this manner. I’m ready to chalk it up to either a flaky fan or a faulty GPIO or… something.

Anyone have any ideas?

So here's the patch:

You'll need to patch the dtb to play* around with different C values
for cpu_trips/thermal_zones.. The values originally used where just a
best guess. (the am5728 is rated for -40 <-> 105 C)

You can use dtb-rebuilder for this:

Use either the 4.4-ti, 4.9-ti, or 4.14-ti branches matching your
booting kernel..



Wow - thank you! I’ll give it a shot.


David Stein

Robert: I haven’t quite solved the problem, but I’ve made some progress. Reporting back both FYI and to help anyone else with this problem.

I downloaded your dtb-rebuilder and spent some time looking at it. I anticipated having to write those changes into the patched file, but as it happened, I found that they’re already included in am57xx-beagle-x15-common.dtsi. I checked the more specific file (am57xx-beagle-x15-revc.dts) to verify that it didn’t have any overriding settings.

I built the DTB:

make all
make install

…and verified that /usr/bin/dtb (aliased to /usr/bin/local/dtb) had been updated. So far, so good.

I rebooted and found that device behavior hadn’t changed. But at least I had a lead as to where the behavior was controlled.

I tried tweaking the hystersis values in common.dtsi, making sure that the most relevant hysteresis values are reasonably large:

cpu_alert1: cpu_alert1 {

hysteresis = <2000>; /* millicelsius */


board_alert0: board_alert {

hysteresis = <5000>; /* millicelsius */


board_crit: board_crit {

hysteresis = <1000>; /* millicelsius */


I rebuilt, reinstalled, and rebooted… no change in behavior - the fan still turned on and off every couple of seconds. Watching the output of tmp102 via sensors, I can see that the CPU temperature only fluctuates about 0.1-0.2 C between fan cycles. I set them even higher - up to 5000 mC. Rebuild, reinstall, reboot… no effect.

I realized that I could tackle the problem in a more crude way - by increasing the temperature polling frequency… bordering on stupidly large:

&thermal_zones {

board_thermal: board_thermal {

polling-delay-passive = <30000>; /* milliseconds */

polling-delay = <30000>; /* milliseconds */



Rebuild, reinstall, reboot - that seems to have worked. Well, kind of. The fan typically cycles in 30-second intervals now. Oddly, it’s not 100% of the time: sometimes it conducts three or four 30-second on/off cycles and then exhibits a few short cycles (like: turning on just long enough to get up to speed, turning off just long enough to stop, and then turning on for 30 seconds again).

Honestly, though, this solves the immediate problem: rapid fan cycling was both getting on my nerves, and creating some concerns about wear and tear from constantly turning on and off. I suppose I can live with a 30-second cycle time.

However, I’m still really puzzled by the inconsistent behavior: why hysteresis temperatures didn’t work, and why the cycle time doesn’t seem to be fixed. Curious results that bear further exploration.


David Stein

Hi David,

Thanks for posting info about how to do this. One question, if I was to start doing something intensive and the temp is only checked every 30s, could the temp raise too high in this 30s and be potentially dangerous?