[Potential Hardware Fault] BPI-R4 Pro (2.5GbE): 12V Rail Failure & Buck1 Dependency Cycle
Disappointment & Logistics Concerns
I am writing this with a heavy heart. After waiting a month for my BPI-R4 Pro to arrive in the UK from the official SinoVoip Shop on AliExpress, the board appears to have developed a hardware failure after just seven days of perfect operation.
While I can pursue an AliExpress refund, the logistics are a nightmare: I’d face another 4-6 week wait for a replacement, and because I bought this during a sale, a re-order would now cost me £65 more than my original purchase. I am hoping a BPI staff member (@simon / @sinovoip) can confirm if this is a known issue or if there is a way to rectify this without a full return/refund cycle that leaves me out of pocket.
Back Story & Setup
The unit worked brilliantly out of the box with stock firmware. I took every precaution:
- Cooling: 3D-printed custom case with dual Noctua NF-S12A PWM fans (12V, 0.12A).
- Protection: Case was treated with ESD anti-static coating prior to installation.
- Power: High-quality Netgear 12V 5A PSU (tested under load with minimal voltage sag).
- Performance: Under 99% load, the CPU was stable at a cool 41°C. No Wi-Fi modules were installed.
The Failure
After one week of stable runtime (no config changes), I found the unit idling at 60°C with both fans stopped. After hours of troubleshooting and factory resets, I’ve confirmed a hardware failure (or at least, I’ve run out of software fixes):
- Fans: Tested externally in a PC; they work perfectly.
- Physical Voltage: Multimeter confirms 0V output at the fan headers.
- Firmware: Using stock builds; reset multiple times with no change.
The “Smoking Gun” Evidence (I2C & Regulator Logs)
The software seems to think the rail is active, but the hardware has disappeared from the bus. On the BPI-R4 Pro, I believe, I could be wrong, but the INA2xx power monitor is powered by the 12V rail it monitors. I haven’t changed any configuration regarding the fans; out of the box, they just worked silently and perfectly. I’m providing my technical findings below in hopes they shed light on the issue.
System Information
root@BPI-Pro-Router:~# {
echo "--- SYSTEM IDENTITY ---"
echo -n "Kernel: "; uname -a
echo "--- OPENWRT RELEASE ---"
cat /etc/openwrt_release
echo "--- BOARD IDENTIFICATION ---"
echo -n "Model (Sysinfo): "; cat /tmp/sysinfo/model
echo -n "Device Compatible: "; strings /proc/device-tree/compatible | head -n 1
echo -n "CPU Architecture: "; opkg print-architecture | head -n 1
}
--- SYSTEM IDENTITY ---
Kernel: Linux BPI-Pro-Router 6.6.93 #0 SMP Tue Jun 17 03:09:13 2025 aarch64 GNU/Linux
--- OPENWRT RELEASE ---
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='24.10-SNAPSHOT'
DISTRIB_REVISION='unknown'
DISTRIB_TARGET='mediatek/filogic'
DISTRIB_ARCH='aarch64_cortex-a53'
DISTRIB_DESCRIPTION='OpenWrt 24.10-SNAPSHOT unknown'
DISTRIB_TAINTS='no-all busybox'
--- BOARD IDENTIFICATION ---
Model (Sysinfo): Bananapi BPI-R4-PRO-8X
Device Compatible: bananapi,bpi-r4-pro-8x
CPU Architecture: arch all 1
I2C Bus Scan (i2cdetect -y 3)
I ran a scan on I2C bus 3 to see which devices are being detected. Most of the reserved addresses appear to be showing up as expected, but I noticed that address 0x40 is completely missing.
I’m assuming this is where the INA2xx sensor should be, based on the errors I’m seeing in the logs. If that’s the case, its absence in the scan might be another sign that the sensor—and the rail it’s responsible for—isn’t getting power. I’d be interested to know if this address shows up normally on a healthy R4 Pro.
root@BPI-Pro-Router:~# i2cdetect -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
Kernel Error (dmesg)
I took a look at dmesg to see how the system is handling the power-on sequence. I noticed a couple of errors that I’m not entirely sure about, but they seem relevant to the missing 12V output.
First, the ina2xx driver seems to be having trouble. It mentions it can’t find its supply and then fails with a “device configuration” error. Since I’m getting 0V at the fan headers, I’m wondering if this chip is failing to initialize because of that missing voltage, or if this is just a software quirk.
Also, I noticed a “Fixed dependency cycle” involving the rt5190a buck1 regulator. I don’t have enough experience with the PMIC logic to know if this is normal for the R4 Pro, but since buck1 appears linked to the initialization sequence, I thought it was worth sharing.
root@BPI-Pro-Router:~# dmesg | grep ina2xx
[ 90.147671] ina2xx 3-0040: supply vs not found, using dummy regulator
[ 90.155424] ina2xx 3-0040: error configuring the device: -6
root@BPI-Pro-Router:~# dmesg | grep cycle
[ 0.015847] /soc/interrupt-controller@c000000: Fixed dependency cycle(s) with /soc/interrupt-controller@c000000
[ 3.222113] /soc/i2c@11003000/rt5190a@64: Fixed dependency cycle(s) with /soc/i2c@11003000/rt5190a@64/regulators/buck1
Regulator State
I’ve been looking into the regulator states to see if there is any obvious software-side reason for the 12V failure. The output below shows the current state of the regulators on my unit.
It seems the kernel identifies the RT5190A components and has them marked as enabled, yet as I mentioned, there is no physical voltage at the headers. I’m not an expert on the PMIC’s internal mapping, but seeing buck1 and buck4 enabled while the 12V-dependent monitor at 0x40 remains invisible is confusing.
root@BPI-Pro-Router:~# for r in /sys/class/regulator/regulator.*; do echo -n "$(basename $r) ($(cat $r/name)): "; cat $r/state; done
regulator.0 (regulator-dummy): cat: can't open '/sys/class/regulator/regulator.0/state': No such file or directory
regulator.1 (fixed-1.8V): cat: can't open '/sys/class/regulator/regulator.1/state': No such file or directory
regulator.2 (fixed-3.3V): cat: can't open '/sys/class/regulator/regulator.2/state': No such file or directory
regulator.3 (rt5190a-buck1): enabled
regulator.4 (vcore): enabled
regulator.5 (vproc): enabled
regulator.6 (rt5190a-buck4): enabled
regulator.7 (rt5190a-ldo): enabled
I’m hoping this data helps the team identify if this is a known batch issue or a software bug. I really love the board’s performance otherwise and would love to get this sorted without the long AliExpress refund loop.
Thanks in advance for any help or guidance you can provide! Keep up the great work on these boards.