Rock5 does not work on most PD power supplies


I got my Rock5 today and was a bit shocked that it did not work the first time it tried it, it would power on and then reset after ~3 seconds.
I thought maybe my phone power supply was to weak so I tried my 45 Watt laptop USB-C power supply, but the same. I smelled a PD issue so I tried a A to C cable and tada it worked.

Power supplies that do not work:

  • Samsung Travel Adapter EP-TA845
  • Anker Nano II 30W
  • Baserus 45W GanII
  • Anker PowerPort+ 5

Power supplies that do work:

  • ZMI USB-C 20000 mAh power bank
  • Xiaomi USB-A to C cable combo (this is special and has a CC line on A socket)

I also found two PD power supplies that do power the Rock5, my ZMI power bank at 12V and a Xiaomi phone charger that does it at 9V, all the others fail, which is kind of a big issue since 5V 3A won’t cut it once 2-3 peripheral devices are connected.

Did this issue not hit anyone else? Is there something wrong with my board?

P.S.: I am booting Ubuntu on the Rock5.

Pictures of the PDOs and so on:

1 Like

Connect the 12v and try and apt-get update / apt-get upgrade and give it a shutdown and then try pd.

That did not change the behaviour, I already had all packages updated.

Sure. But rock-5b-ubuntu-focal-server-arm64-20220701-0826-gpt.img.xz did work with all the USB PD chargers that now don’t work any more.

I might check tomorrow I burned the image, fresh today, and it did not work out of the box, so I guess I had this issues from the start.

Which package would have upgraded the uBoot?

Edit: I installed so the current build is already broken then, I guess…

			 PDO_FIXED(12000, 1500, PDO_FIXED_USB_COMM)>;

found this in the 5b changes in uBoot…
so I guess something is going wrong there, all the failing power supplied work well with all my other devices and at least 5V and 9V are available on all PSUs but instead of using any of them, the Rock5b just resets endlessly.

Again: rock-5b-ubuntu-focal-server-arm64-20220701-0826-gpt.img.xz is from 1st of July and that is the last image that worked with some of my USB PD chargers (me having been part of the ‘Debug Party’ as early adopter able to test/optimize software support for Rock 5B Rev 1.3)

But why would I want and old version of the OS?

even the current version has so many issues still no librga2 in repos and similar… it still feels really messy.
Packaged gstreamer has no mpp enc support, libmpp stuff is not packaged…

the ‘Debug Party’ thread has a ton of information and was meant to provide those answers and exchange inside info and findings.

It seems rga has some issues that prevent hw decode functionality in some cases.
You can build a Gstreamer plugin with hw encode, search the forum.

You may use the “desktop” img instead of the “server” img. Or build everything from scratch.

Just as a quick test. No other purpose.

I am “experienced” on this. Let me explain what happened.

The Rock 5 need negotiate with the PD power source to get any power level that this sufficient.

BUT the problem is, the PD handshaking took too long and the PD power-source just timed out and cut the power, hence the boot loop. Some power bricks allows a longer time out and those can be used.

Why the handshake took so long? Because the handshaking happens AFTER the kernel is loaded. To fix this, Radxa already updated the u-boot to add PD support so that PD can be negotiated before the kernel is loaded, but the updated u-boot is not available in all images yet(I guess).

From my own experience, connecting an UART cable to Rock 5 without the RTSN pin would delay the negotiation and some power source cannot boot the the UART attached can be used without the UART. By connecting the GPIO pin 40(UART2_RTSN) to UART cable also fixed boot loop for me, but RTS function is not available for all UART cables.


I have no serial cable connected, so that should not be the source of the issue, but ok, I hope that Radaxa will push the update to Ubuntu soon.

Also, is there any documentation on how to update the bootloader? Any specific command/package like it is on raspberry pis?

Package: rockpi4-dtbo
Package: rockpi4-dtbo-4.4
Package: rockpi4-dtbo-5.10
Package: rockpi4a-rk-u-boot-latest
Package: rockpi4a-rk-ubootimg
Package: rockpi4b-rk-u-boot-latest
Package: rockpi4b-rk-ubootimg
Package: rockpi4c-rk-u-boot-latest
Package: rockpi4c-rk-ubootimg
Package: rockpie-rk-u-boot-latest
Package: rockpie-rk-ubootimg
Package: rockpin10-rk-u-boot-latest
Package: rockpin10-rk-ubootimg
Package: rockpis-rk-u-boot-latest
Package: rockpis-rk-ubootimg
Package: rtl8723be-firmware
Package: rtl8723ds-firmware
Package: upgrade-tool

the only packages I can see are related to older RockPis

as discussed with @gnattu in another topic, I am also struggling with properly powering on Rock 5B using my PD power supply, including my USB-C monitor. you may connect to serial port following this guide and check your u-boot version… mine is U-Boot SPL 2017.09-gc060f28d70-220414 #zyf (Apr 18 2022 - 18:13:34)

as @gnattu show to me the u-boot commit, the latest image should be incorporated PD capability, though somehow my “new” Rock 5B I bought from Allnetchina only comes with the older u-boot as shown above.

but the worst of all is that I cannot update my SPL flash by following the guide due to unknown reasons, so I cannot “safely” boot up my Rock 5B… it works sometimes, but not always… rather be very seldom it could complete the boot sequence.

Yeah it is a bit of a pitty…

So there is no way to just update u-boot from the running OS?

Are you guys sure as on the pre release samples on receipt would not boot with PD.
I swapped out to 12v with usb-c barrel adapter booted and think it was merely apt-get update/upgrade as Radxa had already updated uboot as a package and I did nothing else as was initially confused that PD by magic was working as my sample was much later shipped than most and was late to the party.
So was never involved in the early discussions and apart from not being a fan of PD assumed it was all fixed from that point.

no, I paid for the v1.42 (retail) board; I just live close enough to China that I receive the board fast as I preorder early as well.

Yeah dunno as the one I got was v1.3 so don’t know what changes where made.

and yes, forget to answer… my v1.42 board did come with an OLD u-boot image as mentioned above (dated 2022-04-18), and from what I see only those compiled after 2022-09 would have the PD bits included. perhaps Allnetchina is still using an old image to put into the SPL flash.

Basically Android won’t boot because of other issues, though from serial console I can tell that PD negotiation takes like >0.82 seconds, and very often make my PD power source cut its power. I do prefer using Android myself… if it were Android 13, that would be the best.

I can successfully boot to Debain just once, and face the screen tearing issues; all the other times I know I am facing PD power issue, but get a more clear picture after discussing with @gnattu. In particular, with a m.2 SSD installed, I cannot boot to Debain so far, and @gnattu suggested that maybe booting with m.2 uses too much power, which I think is true.

Again, the worst part is 1) I cannot update the u-boot in SPL flash following the official guide, and 2) I assume the SPL flash is the MXIC chip sit right behind the RJ45 port? nothing look like a 8-pin serial flash other than this… and since it is placed so close to the HDMI port, I don’t think I can use a clamp cable to connect it to my buspriate to reflash… so, I cannot use the board now basically.

I would say being close and getting the board fast is both an advantage and disadvantage as likely maybe packages to be released are likely playing catch up?
I would tag one of the Radxa team @jack or @RadxaYuntian to what the current of state of play with PD and v1.42 is before you go any further.

I was not invited to the debug party anyway :slight_smile:

Was expecting the retail board should have fixed all these, but no. Worst experience is that I cannot update the SPL flash in any possible way, not even using an external programmer like my buspirate, as the placement of the chip is at a bad location… perhaps being located at the bottom side is better.

So far it is weird: when connecting to my machines directly, Rock 5B in masked ROM mode will never get detected (lsusb), while it is fine if I put a USB hub in between; when I try to flash according to the official guide, it will fail to load the loader when it is connected to my Thinkpad under Linux, but fine if I use my Windows VM with pass through USB controller, yet right after the loader is loaded, masked ROM device will disappear so further action is impossible. I would avoid digging further myself, as it would take too much time for me.

1 Like