Rockpi4B reboot loop - seems homeassistant and Zigbee2mqtt and USB related

[Mossieur Oeuf]

Hi, I used to run a full docker environment using the Radxa Debian buster image upgraded to bullseye. Lately as the backport repo has been archived I decided to move onto Armbian as upgrading bullseye to bookworm did not boot (or seemed so...).

After flashing the latest Rockpi4 image to the Rockpi4, I copied the docker configuration and files backups.

I now have a akward behavior:

- starting all the stacks (or containers) works fine, all seems ok

- rebooting via 

sudo reboot

provokes an endless reboot cycle which is only ended if I unplug the USB Zigbee coordinator key. Once the loop is stopped, the RockPi does not have any IPv4 address (only IPv6) and is unreacheable by SSH.

- power cycling with the USB key unplugged fixes the boot loop and everything is back to "normal", except the following dmseg errors:

rock@rockpi4b:~$ sudo dmesg -l 0,1,2,3
[    3.099273] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[    3.099333] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110
[   11.200510] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   11.731680] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[   11.732234] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
[   99.980012] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6
[   99.980072] cpu cpu4: Failed to set regulator voltages: -6
[   99.980097] cpufreq: __target_index: Failed to change cpu frequency: -6
[  246.811985] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6
[  246.812046] cpu cpu4: Failed to set regulator voltages: -6
[  246.812070] cpufreq: __target_index: Failed to change cpu frequency: -6
[  400.087329] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6
[  400.087387] cpu cpu4: Failed to set regulator voltages: -6
[  400.087410] cpufreq: __target_index: Failed to change cpu frequency: -6

Now this is where it gets strange: if I prevent zigbee2mqtt container to automatically start at boot (which cannot be a permanent solution obviously) it doesn't matter if the USB key is plugged in or not (whichever usb port), Armbian boots ok and all other containers start ok.

 

I already checked the /dev/ttyusb0 access rights, tried to change the docker container user, activate the rockchipdw3 overlay, changing the USB port for the Zigbee key, switching from rolling to stable and vice versa, to no avail.

No need to say that the same config worked under bullseye.

 

Does someone have any lead or clue about what's happening ? Where can I look as logs don't show anything special...

Any help would be greatly appreciated, thanks in advance!

 

My config:

Rockpi4B, Armbian_community_25.11.0-trunk.70_Rockpi-4b_bookworm_current_6.12.43_minimal.img, usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus

[laibsch]

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

[Mossieur Oeuf]

Hi, thanks for the tip, here's the link of the amrbianmonitor results:

https://paste.armbian.de/okeqakeval

[laibsch]

Could this be a power supply issue?

 

Unfortunately, there is no official maintainer for your board.  None of the core devs will be able to verify your issue.

[SteeMan]

Specifically, your board is "Community Maintained"

That means it is not supported by Armbian resources (beyond the automated infrastructure to make builds and host them for the community)

https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained

[Mossieur Oeuf]

Yes I'm aware that I can only rely on the community for any help or tip.

I'm now considering to revert back to a bullseye setup with a 5.10 Radxa kernel, but I was kind of reluctant to keep an old version of Debian as my Rockpi is accessible from ouside my network...

 

 

Quote

Could this be a power supply issue?

The Rockpi is powered by a PoE hat, it never had any issue so far but maybe the PoE management is the culprit. I'll try an use the Rockpi with a traditional power supply, but in any case if this is the issue it won't be a sustainable solution for my target setup.