Rock5 does not work on most PD power supplies

Do you have a WIFI card on the board?

Yes, I’m using the Radxa wireless A8 . WIFI is OK but I’m struggling with Bluetooth, BT didn’t find my BT Speaker.
Greetings
Andreas

Do you mind sharing a link to the particular power supply. I am having random crashes with an Intel NVME and the Radxa wireless A8. I was starting suspect issues with the WIFI but maybe I am wrong. I will have to Open the case and remove the card to test.

I’m using this one:
https://www.amazon.com/dp/B07W8XHMJZ/ref=twister_B081DBD553?_encoding=UTF8&th=1 and a NVME from HP MZ-VKW1T00
Greetings
Andreas

Thanks @linuxfriend I got the Raspberry Pi 4 power supply and I am seeing some stability for sure. I will need to run the board for a while to see if I will run into any issues and maybe run some stress tests as well.

1 Like

Fine, my board is running with that PD for about 2 weeks, without any problems, inc. some stress tests.
Greetins
Andreas

I initially had PD problems and issues booting with a Raspberry Pi 4 PSU as well. After pulling my eMMC and M.2 NVMe I was able to boot from the SD card with the RPI 5v adapter. I ran the SPI flash using the files from here https://wiki.radxa.com/Rock5/install/spi (rk3588_spl_loader_v1.08.111.bin and rock-5b-spi-image-g49da44e116d.img). After that my PD issues were resolved and my Lenovo USB-C PD brick worked with no issues.

I did some testing with 5v using my RPI adapter, as well as using 5v from my ATX bench PSU, 12v (from my ATX bench PSU and a old Vizio TV brick), and my Lenovo USB-C PDU. I found that the Rock 5b would only boot with a 5v input if ONLY the SD card was installed. If anything was in the eMMC or M.2 slot it would go into a boot loop. (NOTE: I don’t have a wifi card installed, so not sure what the impact of this device might be.)

With a 12v or USB-PD (after the flash update), everything works with SD, eMMC and NVMe installed. I ran through all my tests and results here: https://www.learningtopi.com/sbc/radxa-rock-5b-setup/

So, a little update since my last post, I was waiting for a new nvme to usb adapter and some cables to arrive so now I can test everything properly.

I tried booting from an Nvme ssd (WD green SN350 240GB) with the Allnet 65WD PD power supply and it works with no problems for now!

1 Like

The Spigen 65W USB PD charger works as a power supply without issue. I have 4 of them, 1 is powering a Rock 3a server. It resets power negotiation on device plug/unplug, so not recommended to use other port while using as a power supply. There is a lack of small USB PD power supplies out there so I just get chargers.

1 Like

After getting the Raspberry PI 4 power supply, I was able to boot but kept getting random crashes with Armbian 22.11.2 Bullseye and the Radxa Ubuntu image. Currently, I am running Armbian 22.11.2 Jammy with reasonable stability. Thanks, @linuxfriend, for sharing your success with the Raspberry PI 4 power supply. I will now put the board through its paces.

1 Like

Hi all, I am seeing some unusual behavior related to PD and am hoping you can shine some light on whether or not it’s the PD handshake timing issue that’s been reported in here.

I am using this particular power supply for my Rock 5B: https://www.amazon.com/dp/B0B1LY7Z19
It’s a 45-watt USB PD supply with five different modes, ranging from 5v/3a to 20v/2.25a. When I first plug it in, the machine boots perfectly every time. I’ve done it hundreds of times and it boots with no issue. It even recognizes the PD options and picks the one with the highest voltage:

[    1.658490] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS]
[    1.665407] pd := on
[    1.665428] pending state change SNK_WAIT_CAPABILITIES -> SNK_SOFT_RESET @ 310 ms [rev3 NONE_AMS]
[    1.697205] IRQ: 0x41, a: 0x00, b: 0x01, status0: 0x93
[    1.697222] IRQ: BC_LVL, handler pending
[    1.697234] IRQ: PD sent good CRC
[    1.702120] PD message header: 51a1
[    1.702135] PD message len: 20
[    1.702308] PD RX, header: 0x51a1 [1]
[    1.702326]  PDO 0: type 0, 5000 mV, 3000 mA [DE]
[    1.702332]  PDO 1: type 0, 9000 mV, 3000 mA []
[    1.702339]  PDO 2: type 0, 12000 mV, 3000 mA []
[    1.702343]  PDO 3: type 0, 15000 mV, 3000 mA []
[    1.702348]  PDO 4: type 0, 20000 mV, 2250 mA []
[    1.702353] state change SNK_WAIT_CAPABILITIES -> SNK_NEGOTIATE_CAPABILITIES [rev3 POWER_NEGOTIATION]
...
tcpm_source_psy_4_0022-i2c-4-22
Adapter: rk3x-i2c
in0:          20.00 V  (min = +20.00 V, max = +20.00 V)
curr1:         2.25 A  (max =  +2.25 A)

That’s great!

The problem is when I restart or power off the device without unplugging the power supply. When I do either of these things, I hit the infinite boot loop as many of you have mentioned. Unplugging the board (but leaving the PSU plugged into the wall) and plugging it back in resolves the issue and it can successfully boot again.

I’m using an NVMe SSD as the boot drive, booting into Debian 11, loading kernel 5.10.110-34-rockchip-gca15bbe36e6c which seems to be the latest on the apt repo. I flashed rock-5b-spi-image-g49da44e116d.img (which seems to be the latest, from September) onto the SPI chip so it could boot from NVMe.

Peripherals don’t matter, Ethernet connection doesn’t matter, and the UART console output looks the same on a good boot and a boot loop.

I suspect this is a PD issue because I can put a dumb Canakit PiSwitch in-between the PSU and the Rock, which doesn’t pass data through so the PD handshake doesn’t work. When I do this, sensors reads it as just a dumb 5v power supply:

tcpm_source_psy_4_0022-i2c-4-22
Adapter: rk3x-i2c
in0:           5.00 V  (min =  +5.00 V, max =  +5.00 V)
curr1:         0.00 A  (max =  +0.00 A)

Doing so makes powering on/off work every time, including reboots and power cycles (while leaving the board plugged into the PSU).

What’s happening here? Is this something that can be fixed in the kernel, or is there something else at play? Why does it have a “memory” in this case of being restarted while still being plugged in? Is there a fix I can apply besides simply removing PD from the equation?

1 Like

An update on Raspberry PI 4 power supply. I have 3 boards I left them on overnight to test for stability 2 of them remained on. One crashed which is weird the only difference from the other two is that it has an intel nvme pulled from a laptop on it while the other has Lenovo ones. So it is either an issue with nvme or just a defective board.

For full test now swap this nvme to one of two, make longer tests on both boards and be sure that they have same spi.

Is there a way to tell whether it’s just a psu problem, or if my unit is defective? With a spi update, the boot loop went away on all of my power supplies, but the booted OS does not detect an nvme connected. The drive does not even get warm. I even tried re-scanning the pci bus when the device is fully booted.

I flashed an armbian image to the nvme drive with etcher, and when it is the sole storage device, it will sit there getting warm, but doesn’t boot or output anything to the serial terminal, other than what is normally output with no storage connected. The led is stable blu-ish during this time.

I’m mainly using my Dell monitor’s 100w pd connection, but I also have 2 different 65 watt chargers, a powered usb (A) hub, and a samsung quick charger. The device boots from all of them now, but no nvme.

update:
Linux can mount the nvme drive via a USB adapter, but only through the powered hub. If it’s plugged in directly to the Rock5’s usb, I see sda detected in dmesg periodically, but it the led on the usb adapter won’t stay on like it does normally. The nvme drive does heat up, though.

usb-c adapter on a 12v psu with no PD if it still happens its not PD.

Ok, powered it with 12v from my bench power supply without any luck. I’ll try another nvme next.

Not every nvme is working, I failed to get to work hp ex900 which works literally everywhere. Few others nvme are working correctly with no issues so I just swapped them. If there is not enough power probably nvme will initialize and die with errors when its in use (system may restart or hang up).

in another thread, I was looking into the same issue, and with others’ help it is concluded that it is the SoC’s own compatibility issue with some NVMe controller(s), which failed at PCIe lane training and thus not detected. it likely requires Rockchip to fix the kernel driver side of thing to make it work with more NVMe devices.

1 Like

Yep. Tried a couple more drives from other computers and they both work. I guess it just doesn’t like the Adata XPG 256G that I wanted to use with it. FWIW, the working boards are all 1-sided, and the non-working one has chips on both sides.

haha maybe we have the SAME NVMe that we savaged from our old computer and wanna make it work with Rock 5B :slight_smile:

The controller is realtek? If so then it is the same as mine and perhaps not supported. I think Phison controller are more common and should have better compatibility, so I also removed another old NVMe with this brand’s controller, but I am yet to test it out.