-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Raspberry Pi PoE hat fans don't respect /boot/config.txt settings #1689
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Please post your full |
I don't have access to There is a workaround posted in that issue, but it looks like it's for Debian/Ubuntu and it'll take me a little bit to see if I can get it working on Arch. |
Although the overlays for the PoE hats are loaded automatically, if you want to configure them by supplying parameters it is necessary to put the parameters "in scope" by loading the overlay explicitly immediately before using them, i.e. add one of the following just before the reference to poe_fan_temp0:
|
@pelwell I tried adding I'm going to install Raspberry Pi OS today and see if I can repro the issue. If so, I'll use the commands recommended above to provide more logs. |
I'm having a different issue on 64-bit Raspberry Pi OS, the fans don't turn on even though my temp reading is this:
If I use 32-bit Raspberry Pi OS, it works as expected. OS:
Kernel:
Firmware:
Reproduction Steps: Rapsberry Pi OS Image: https://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2022-01-28/2022-01-28-raspios-bullseye-arm64.zip After installing the OS, I booted and signed in via SSH, and then I cloned this repo and checked out commit
|
I followed the workaround in #1118 and got I'm still reproducing the same issue above. The @pelwell do the debug logs below help? Details: CPU Temp:
OS:
Kernel:
Firmware:
|
Thanks - I see what is happening. The point where the automatic loading of the rpi-poe overlay happens is after the point where config.txt is scanned for overlays, causing your settings to be overwritten. I'm sure this was not the case previously - I've tested the fan settings before. Leave this with me. |
Catch 22 - it needs to be late enough to detect that an overlay has enabled i2c_vc, but that also means that it's after loading the overrides. |
It may be possible to rework it in such a way that the switch can be made after the overlay has been merged. |
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have up to now been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
Linux pull request raspberrypi/linux#4877 is half of the proposed fix, the other half being a firmware patch. |
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have up to now been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
I am running a pi4 8gb 32bit piOS and the poe fan do not respect the config.txt overrides
here is my config.txt:
Here is the output of
So I think the issue is still alive. |
The problem hasn't been fixed because although the companion patch went into our internal firmware software repo on February 9th, the last firmware build (the one you are running) was released on February 4th - the last kernel build was much more recent (the 18th). Any chance of a firmware release, @popcornmix ? |
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
Is this fix workable for Ubuntu 21, or did the mechanism for controlling the fan speed change? |
That's up to whether Ubuntu have picked up the relevant kernel and firmware updates - Raspberry Pi have no control over that. |
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/1964144 The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]> (cherry picked from commit 9c170663726240de2e6ae71bd7de005088adbd99 rpi-5.15.y) Signed-off-by: Juerg Haefliger <[email protected]>
The support of PoE HATs is complicated because there are two methods to control them - via the firmware, and directly over I2C - the choice between the two methods depending on which side "owns" the i2c0 bus. The firmware determines the ownership of i2c0 by analysing the Device Tree after applying any dtoverlays and dtparams. For this reason the PoE HAT overlays have recently been applied by the firmware _after_ config.txt has been processed, but this has prevented any user-supplied threshold settings from being applied - either because the parameters are unknown or because (after an explicit dtoverlay=rpi-poe) the firmware's reload of the overlay has overwritten the user's settings. Solve the problem by restructuring the rpi-poe overlays to support a mode switch _after_ the overlay has been merged, thereby allowing the overlays to be loaded _before_ config.txt is processed. There is a companion firmware patch that changes the point at which the overlays are loaded, and the parameter used to switch modes, but the updated overlays are still compatible with older firmware, albeit without working parameters. See: raspberrypi/firmware#1689 Signed-off-by: Phil Elwell <[email protected]>
Is this the right place for my bug report?
This repository contains the GPU firmware used on the Raspberry Pi. This software is the closed source part of the Raspberry Pi system, it includes booting (including network booting and USB booting), low-level power and clock control, FKMS and legacy HDMI control (not full KMS that is in the linux kernel), hardware legacy codecs (MPEG2, H264 and VC1), encode hardware including the ISP (image sensor pipeline) and camera control, audio output (analogue and HDMI audio).
If you believe that the issue you are seeing is within this area, this is the right place. If not, we have other repositories for the linux kernel at github.com/raspberrypi/linux and Raspberry Pi userland applications at github.com/raspberrypi/userland. If you have problems with the Raspbian distribution packages, report them in the github.com/RPi-Distro/repo. If you simply have a question, then the Raspberry Pi forums are the best place to ask it.
Describe the bug
I'm using the official Raspberry Pi PoE Hat (the first gen, not the plus version) with a Raspberry Pi 4 Model B Rev 1.4.
I recently applied an update from my distro and when I rebooted the machine I noticed the fan on the PoE hat started running and didn't turn off. I have added this block to my /boot/config.txt to prevent the fan from running in idle conditions:
I checked by the CPU temperature and got this output:
The firmware I upgraded to was this version:
So, I downgraded my firmware to this version:
And after reboot, the PoE hat turned off as expected.
To reproduce
Note: It's assumed you are indoors in a room at room temperature.
Expected behaviour
After reboot, the PoE hat fan should turn off
Actual behaviour
After reboot, the PoE hat fan stays on
System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
Which OS and version (
cat /etc/rpi-issue
)?Which firmware version (
vcgencmd version
)?uname -a
)?Logs
If applicable, add the relevant output from
dmesg
or similar.Additional context
Add any other relevant context for the problem.
The text was updated successfully, but these errors were encountered: