Allow disabling fan in the bootloader stage to prevent fan from eating into the USB power limit on boot

[C0rn3j]

Describe the bug

I have a very power hungry USB NVMe enclosure+NVMe, and I have issues booting properly.

As per documentation, the power limit of the USB ports is shared with the fan port.

This means that the 1.6A power limit, that is reached with a proper 5A PSU on the RPi5, is eaten into.
This is especially problematic since the fan is running at full throttle, so it could not be consuming more.
I would like to have an option for setting fan behavior in bootloader stage, I would prefer to just disable it there, to ensure it is not fighting my USB enclosure for power.

This would also fix #501 which was closed, but the complaint there is more about the loudness.

Steps to reproduce the behaviour

Power the Pi on, fan is full throttle.
Get a funny xHC error some of the times.
Sometimes this actually prevents HDMI from toggling on, despite HDMI_DELAY=0, it will show HDMI upon a physical replug though and will end up on the same xHC fail log as always.

picture taken with mostly bare bootloader config, does not match my current one

Device (s)

Raspberry Pi 5 8GB with the official power supply
USB M.2 NVMe enclosure by Sabre with RTL9210B
ADATA XPG SX8200 Pro 2TB

More details than about my hardware/firmware can be found here if necessary.

Bootloader configuration.

[all]
BOOT_UART=0
POWER_OFF_ON_HALT=0
BOOT_ORDER=0xf461
USB_MSD_PWR_OFF_TIME=0
USB_MSD_STARTUP_DELAY=2000
USB_MSD_DISCOVER_TIMEOUT=10000
HDMI_DELAY=0
NET_INSTALL_ENABLED=0
PSU_MAX_CURRENT=5000

---

As a side note, neither the fan case nor the active cooler sections have documented wattage, this would be a welcome addition. raspberrypi/documentation#3541

I had to set USB_MSD_PWR_OFF_TIME=0 to even get it to boot once off the USB NVMe. Seems to be placebo effect combined with my USB delay timing.

[lurch]

As a side note, neither the fan case nor the active cooler sections have documented wattage, this would be a welcome addition.

Just a quick side note that questions / requests about the documentation should be asked at https://github.com/raspberrypi/documentation

[timg236]

The correct fix is to have a suitable power supply for the attached peripherals. This means that really power hungry USB will need their own power supply.

When the OS is started the CPUs will enabled and can consume several watts of power at peak operation. Therefore, if it the system is not stable with VPU + SDRAM powered it's not going to be stable when the OS is started.

FAN control from the bootloader was rejected in a different PR because the PWM is controlled by the OS / RP1.

[timg236]

USB_MSD_PWR_OFF_TIME=0 does nothing on Pi5. VBUS is ALWAYS off at boot / reboot and is only enabled after DDR is initialised so this is just noise between reboots, possibly due to the power supply not providing enough current.

[C0rn3j]

FAN control from the bootloader was rejected in a different PR because the PWM is controlled by the OS

Does that mean it is impossible to add fan control to the bootloader?

The setup on the left booted 10 out of 10 times I tried in a row.
The setup on the right (second picture) booted 1 out of 10 times.

The only difference between guaranteed success and 90% failure rate is a disconnected fan.
I booted 20 times total, failure was counted at first xHC error as it never recovers from that without intervention.
When it booted it did so immediately on first try in the first two-three seconds.

Config was identical between runs.

[all]
BOOT_UART=0
POWER_OFF_ON_HALT=0
BOOT_ORDER=0xf461
USB_MSD_PWR_OFF_TIME=0
USB_MSD_STARTUP_DELAY=2000
USB_MSD_DISCOVER_TIMEOUT=10000
HDMI_DELAY=0
NET_INSTALL_ENABLED=0
PSU_MAX_CURRENT=5000

possibly due to the power supply not providing enough current

Turns out the power supply provides enough current, but it is stolen by the fan that's maxed out at 100%, preventing correct SSD initialization.

When the OS is started the CPUs will enabled and can consume several watts of power at peak operation. Therefore, if it the system is not stable with VPU + SDRAM powered it's not going to be stable when the OS is started.

When the enclosure/SSD is started, it can consume several watts of power during initialization, and then it never consumes that much again, especially since it will never reach its max speeds on the Pi's USB ports.

For testing whether it will get enough power or not, I booted without the fan and plugged it in later, to ensure it wasn't going to get limited on boot by the OS and kept running at 100%.

I ran stress -c 4 to kept all 4 cores at 100% at all times.

Then I wrote a 20GB file to the SSD.

root@rpi5:~# dd if=/dev/urandom of=/root/testfile20 bs=64M count=320 iflag=fullblock
320+0 records in
320+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 86.3758 s, 249 MB/s

There wasn't as much as a warning in dmesg/journal, no stability issues.

The correct fix is to have a suitable power supply for the attached peripherals. This means that really power hungry USB will need their own power supply.

So either I buy:

• Outlet extender
• Power adapter
• Cable for the power adapter
• Powered USB 3.1+ HUB ($$$)

And deal with the extra bulk, increased power consumption from running two power supplies and a much higher cost of my setup,

OR I somehow get the fan to not turn on for about a second after boot.

With the above demonstration that clearly singles out the fan as the culprit which is preventing my setup from working properly, do you still believe that the correct fix is buying multiple new components to provide a secondary power supply?

[gokulr488]

@C0rn3j I was facing the same issue.
I tried the same thing as you, i.e disconnecting the fan and trying the reboot, which worked fine.

What I've found was that the USB rail has some power limitation, unless the Power Delivery handshake protocol is completed.
it's limited to 0.6A instead of 1.6A

There seems to be a fix for this. you can change the bootloader config.
Add this line to the bootloader config
PSU_MAX_CURRENT=5000

https://www.raspberrypi.com/documentation/computers/raspberry-pi.html

setting this parameter to 5000, allows the board to draw the full 1.6A available to the USB rails.

After setting this, I haven't faced this issue at all. I now have two fans connected directly to the PI (one to the fan header and a 5V fan directly to the GPIO pins).
Even with the loads of the two fans and an external HDD, the Pi is successfully booting Up now.

By the way,
I'm not using the official power supply or cooler,
I'm using a 25W PD charger, which only supports 3A on the 5V channel (I know it's not a good idea :D )

Steps followed
rpi-eeprom-config
sudo -E rpi-eeprom-config --edit
(add the next line to the end of the file)
PSU_MAX_CURRENT=5000
Ctrl+O Ctrl+X
sudo reboot.

Apologies for the messy setup.

[timg236]

Alternatively put usb_max_current_enable=1 could be added config.txt. This directly controls the USB current limiter GPIO without reporting an incorrect max-current level.

It's possible to augment the loaded config.txt via the EEPROM config by adding this special section at the end

[config.txt]
usb_max_current_enable=1

A reason for setting PSU_MAX_CURRENT to the 'wrong' value in the EEPROM is to silence warnings for the Raspberry Pi UI and make it a persistent change, the downside is that it will be wrong if a 5V/5A supply is ever connected.

N.B. For reference, setting PSU_MAX_CURRENT causes USB-PD negotiation to be skipped entirely so a USB-PD capable source should only ever supply up to 3A at 5V in that scenario.

[C0rn3j]

@gokulr488
Unfortunately, in my case I have the original PSU and it seems it's not the 0.6A limit causing the trouble, I seem to genuinely exceed the 1.6A with the fans on, making the enclosure not be able to power on.
Different enclosures with an identical chip can work in the same setup, but the enclosure I have is unable to initialize itself without a power spike.

I have resorted to a rather crude approach of plugging the enclosure to a desktop PC before connecting it to an already-booting Pi, as charging the enclosure capacitors this way seems to make the enclosure require less power for subsequent init, which ends up being enough for the Pi's power implementation even with the 100%-on-fan contending with it.
This is not an ideal approach, as I cannot reboot the Pi without being physically present.

So, the current FW implementation on Pi(+fan) is fine with a well implemented enclosure power supply, but combined with a poor enclosure implementation results in the Pi not being able to boot.

I believe the way to go here is a limited fan control implementation in the bootloader FW, to be able to shut the fan off without taking too much of the EEPROM space.
However, I am not sure if this is actually feasible, and even if this challenge were beatable, that there is enough will and time on Pi's engineers side to solve this.

EDIT: I wonder if connecting the fan to 5V&GND GPIO while keeping the PWM pin in the fan header would work around this issue by making the power limit not be taken from the USB anymore...