RPi4
RPi4 copied to clipboard
pftf
Official Pi PoE hat fan doesn't work
The official HAT (https://www.amazon.com/poe-hat/dp/B07GR9XQJH) has a fan. This fan doesn't spin. While the fan is actually actuated by the VPU firmware (via an mbox command), but requires an OS agent (a driver) to issue that command. The driver of course is OS dependent and DT-dependent... so...
The workaround would be to add an opt-in advanced config option to UEFI to always spin the fan up.
Other Pi POE hats such a the UCTRONICS one have a spinning-always fan.
I'll do this.
Hi!
Is there any timeline for this addition? Currently unable to run my nodes full time due to my bad decision on PoE hat and don't have the talents to fix this myself.
Appreciate all the work that goes into this, thank you.
Hi Sc0th I've also been wondering about this, but in the end, my solution to this was a hardware mod
I ended up stripping the Red and Black wires of the PoE Hat fan and soldering them to jumper wires I had lying around and then connecting them straight to the 5V and Ground connectors on the GPIO headers after using stacking headers to increase the pin length.
That solution would cost <$10 AUD. It is semi-permanent as your cutting the wires to take the I2C bus out of the equation. You can also purchase a Pico Blade 2-pin Molex cable and resolder the wires back to plug back into the PoE hat if you wanted if you went ahead with this which is my I called it 'semi-permanent'. Frankly, I prefer the fan running at 100% for better cooling performance.
Its not ideal but its a kind of 'solution' for now if you really need to use the PoE fan. I would preferably buy a 5V fan that plugs straight into the GPIO pins. I understand if this is not worth your time and effort. Its just a potential temporary solution until these hardworking developers implement the solution for the fan.
Cheers
I mean... The whole issue here is that i2c doesn't work. If I wanted a 100% fan, I'd use a different PoE hat that doesn't use i2c. My ESXi board runs a different hat because this doesn't fit the heatsinks I need to run that hot.
I think I mentioned on discord that we could use the rpi mailbox register (as i'm doing in the not yet upstream CPPC patches) to trigger TF-A to send the appropriate VPU firmware mailbox. Of course that fan is variable speed so the fan object needs to be updated as well.
As a further comment, the existing fan-shim/GPIO activated fan object isnt "always on" its only on when the temp threshold set in the menu is exceeded. I will look at this after the emmc/400 pci issues have landed (although that will be at least a month out. unless I get motivated over Christmas).
Ah, bummer that this isn't resolved yet. but that's just me fussing because I don't have the skillset to resolve it personally.
Nicolas Saenz Julienne, with a SUSE email address, has developed a PWM bus driver for the POE fan. Possibly available in the 5.13 kernel. See https://git.kernel.org/pub/scm/linux/kernel/git/nsaenz/linux-rpi.git/tag/?h=rpi-poe-v5.13
That's pretty cool, though doesn't help the UEFI-booted vmware ESXI fling.
but, looking back at commits, there is support (since v1.20) for a GPIO pin-driver; and it seems like I could simply tie the driver transistor for the POE fan with a 1k resistor tied to GPIO18, and it 'should' work... not sure if i need to add a back-bleed diode yet, but if i can find some magnet wire around here i'll give it a try (fry?)
Well, the cm4+ioboard fan header doesn't appear to use the same mailbox as the POE hat despite some hints to that effect. I picked up a POE hat, and I have the fan working, but I was trying to add a generic AML->PCC channel for it and that seems to have uncovered further issues. It like a number of other things are lower priority so they are happening slowly.
Here is the TFA code which implements the mailbox interface and adds an additional pcc space for it. Right now the two are only lightly wired up as the AML to call this doesn't yet call it properly. https://github.com/jlinton/arm-trusted-firmware/commit/9e787f9a8ccea7365bd640df70fd1612de97c79c
I guess while i'm at it, here is the hacky edk2 bits where I stopped after failing to get the PCC channel to trigger.
https://github.com/jlinton/edk2-platforms/commit/0876f528f1492645aba295c36bb29ed1ce90a652
I've got this "working" for now, but now that its working I'm curious what all the fuss was about. That is because its possible to set the fan profile from the config.txt with something like:
dtoverlay=rpi-poe dtparam=poe_fan_temp0=40000 dtparam=poe_fan_temp1=45000 dtparam=poe_fan_temp2=50000 dtparam=poe_fan_temp3=55000
There are a few more documented here: https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/rpi-poe-overlay.dts
And it turns out that because of this, its a pain to control via AML, because the AML can be setup to create OSPM trip points. But the firmware (or something) wakes up on some duty cycle and seems to override the last pwm request. I may have to reprogram that profile from UEFI directly (or just with AML, because the OS can choose to adjust the thermal trip points at the request of the user). Anyway, for now the workaround I've been using is to set the trip points up near the throttle point and that seems to keep the current firmware from messing with it. But one of the nice things about this fan is that it is fully variable speed, so now we are getting into fan curves/etc and I don't want to try an encode that in the menus.
Anyway, this is just to say I will push another set of patches to my github that makes this work properly, or at least submit the boolean on/off behavior so that it at least behaves like the GPIO fans.
In the meantime, hack those lines into the config.txt adjusting the temp thresholds as needed.
@jlinton Sorry to ping you.
In the meantime, hack those lines into the config.txt adjusting the temp thresholds as needed.
dtoverlay=rpi-poe dtparam=poe_fan_temp0=40000 dtparam=poe_fan_temp1=45000 dtparam=poe_fan_temp2=50000 dtparam=poe_fan_temp3=55000
Did you attempt this on a standard release or were you using a custom build to get this to work?
The reason I ask is I stumbled across this issue when trying to get the poe plus hat to work (changed rpi-poe to rpi-poe-plus) but failed to find any success. I also tried copying over the overlays from the rpi firmware repo to no avail, although I am not especially experienced with these so am not sure if anything else would be required. Also, did you change any settings in the UEFI interface (such as enabling fan)?
for everyone who is messing around with that issue: in installed the PoE-HAT (not the PoE-HAT+) on a Raspberry Pi 4 and it did not work for me using the overlays rpi-poe or rpi-poe-plus. I had to use
dtoverlay=pwm-raspberrypi-poe,i2c
Additionally i set
dtparam=poe_fan_temp0=10000, poe_fan_temp0_hyst=1000
dtparam=poe_fan_temp1=40000, poe_fan_temp1_hyst=2000
dtparam=poe_fan_temp2=45000, poe_fan_temp2_hyst=2000
dtparam=poe_fan_temp3=50000, poe_fan_temp3_hyst=2000
my system is Fedora Workstation 38 , installed using a raw.xz with arm-image-installer (https://download.fedoraproject.org/pub/fedora/linux/releases/38/Workstation/aarch64/images/Fedora-Workstation-38-1.6.aarch64.raw.xz). That used u-boot instead pftf. But i guess the same issue occures with another bootloader
Actually, both proposed workarounds do not work for me. I am starting the UEFI shell only (no operating system yet installed or booted), but the fan does not work.
I seek to install ESXi for ARM, which likely does not (and will not) have a proper driver.
Any ideas?
in my case, the fan starts up when the OS is loaded nearly completely. So it seems that the dtoverlay is loaded really really late. From powering on up to the gdm greeter it takes about 1 to 1.5 minutes. While this time the fan is off, but than it starts.
for the thing before booting OS i have no clue. But indeed it would make more sense to have cooling from the beginning.