It seems more like a “lazy” solution, which is also less flexible, but it clearly works a lot better of the start, yes. But I guess they might fix the issues over time.
The decision to “share” the SMbus/I²C however is more an issue worth a revision of the board…
Rock5 does not work on most PD power supplies
Doh!
May I know your mounted accessories?
I have a Radxa A8 wifi module and Samsung nvme disk only.
Success with an Apple 20W charger, booting from NVMe via SPI. I (pre-)ordered the Radxa 30W from AmeriDroid, that should, fingers crossed, put paid to this issue.
Just to be clear:
Do you got nvme + wifi bt module + emmc + micro sd + mouse n keyboard + hdmi screen.
All hands on deck and with rApple charger it works fine?
Same for me, since I used NVMe, instead of SD, my previous non working PD charger are working now.
I’m booting with wifi/bt module + mouse and keyboard wireless dongles + hdmi screen.
So definitely looking like a timing issue, and workaround provided in wiki, to use a faster booting device seems to be the quick way to fix it for now.
Indeed a real pain dealing with these PD negotiation issues…
The u-boot commit you’ve mentioned is not present in the stable-5.10-rock5 branch.
To test it I’ve cherry picked it to realize that it doesn’t change anything at least with my DELL 65w with PD modes (5V-3A; 9V-3.0A;15V-3.0A;20V-3.25A) as the board still ends up in an infinite loop with both recent Debian and Ubuntu images using an old class 4 16GB micro SD.
I’ve followed instructions here to compile U-boot https://wiki.radxa.com/Rock5/dev/Debian, so unless I’m doing something wrong this commit is not cutting it.
The latest android 12 image flashed on my NVME works fine with my Dell USB Power supply, which confirms the theory that with slow storage the PD negotiation is not timely executed.
Using a Samsung 15w max charger and booting from TF I’m able to go a little further but I suspect it’s drawing too much current during the boot process and it ends up rebooting anyway.
As for the SPI flash process I’ve discovered that the only way to make it work reliably is to use a USB 2 port, it works nicely for me including flashing android from the windows RKdevtool app.
Anyway PD negotiation would need to happen early on with U-boot rather than in the kernel otherwise anyone with less than stellar performance storage will experience this pain and honestly unless someone can confirm successfully booting debian with a class 10 mirco-sd card I don’t want to waste my time anymore.
I have some powersupplies that work with the updated uboot and some that don’t, but before almost none did work.
I got 65W Allnet power supply, with which I was unable to boot 5b both from SD and nvme. The board booted from SD with a Raspberry power brick and a dumb 12V 3A power supply almost always, but only rarely from nvme, more frequently it got stuck. I tried different linux and SPI images. Frustrated, I revisited the Allnet power supply and lo and behold - the board booted (to debian) with the latest SPI development and debian images, negotiating 20.3 V. Since then I rebooted it from nvme with wifi on multiple times without a single fail, making it the most successful of power supplies I tried.
Could you please point me to the “latest SPI development image” ?
Thanks!
1 Like
Err, I mistyped - latest debug not developmental image, from here :
https://dl.radxa.com/rock5/sw/images/loader/rock-5b/debug/rock-5b-spi-image-g3caf61a44c2-debug.img
Aren’t “stable-5.10-rock5” and similar branches deprecated?
The latest android 12 image flashed on my NVME works fine with my Dell USB Power supply, which confirms the theory that with slow storage the PD negotiation is not timely executed.
That’s what I found also, using Linux on NVMe. Making me a bit less worried about this PD issue then, as I don’t plan on using SD card (except for temporary/testing use), because I don’t consider it to be reliable .
But that doesn’t mean it is acceptable of course. I guess we can be a bit more confident a software fix will be possible.
with my DELL 65w
out of curiosity which model do you have? I’m currently looking for USB-C desktop monitor.
As far as I’m aware this branch is the only one under development with DTC for our Rock5b boards.
Interesting, did the PSUs which worked for you had a 12V mode ?
Mine doesn’t just 5,9,15 or 20V.
out of curiosity which model do you have? I’m currently looking for USB-C desktop monitor.
I’m using (or trying to use would be more accurate) a Dell LA65NM170
Ah ok thought you had the screen with it because some of their monitor delivers 65W from USB-C PD port. (was out of topic request, just wondered monitor model cause I thought you mentionned it 
)
Just an FYI that I’m having success with the Anker 736 Charger (Nano II 100W) using their Anker 333 USB C to USB C Cables (I bought the 2-pack of cables).
Tried a few PD chargers and they all resulted in endless restarts.
30w of power through the GPIO using a 5v 6a power brick.
I used 2 in-line 3A fuse to prevent potential overcurrent, but it may not be necessary.
This is just proof of concept at the moment, I’m now planning a breakout board eventually.
When I asked, Radxa mentioned that my monitor, Dell U2720Q, should be one of the many that should work out of box, as they are also using Dell USB-C monitors (I think they used U2720QM?) in their own testing; but of course it is not true in my case 
I’m also trying to boot with the 65W Allnet PD power supply, are you able to boot from an SD card with the latest debug SPI image or does it only fix the nvme boot?