You running on pd-power? As try swapping to a Raspi5.1 or dumb psu and do an apt-get upgrade as yeah when on pd that looks like the boot loop I had wish I had copy+paste now with my memory.
I swapped out to a dumb 12v with usb-c adapter and things booted fine but also now the pd does boot fine and guess something was updated as haven’t changed anything myself as have just been running stress tests continiously
I tried several Apple laptop chargers and no luck (also using Apple cable): 29W, 87W and 96W. Those chargers work fine with Rock 3A and SSD. Rock 5b is without SSD.
I will try something else and see if I can get it to start.
Thanks for the suggestion.
If you’re using sd card, I recommand you to use emmc instead.
@amazingfate I do not have an eMMC card.
It seems that the apple non-pd 12W got the board running. Thx for the suggestion @stuartiannaylor
Yeah I don’t have a emmc card either I presume I would of run apt-get upgrade whilst testing and an update fixed things as now this pd works fine, but I was the same with a boot loop.
You can flash the image into emmc module from a linux/mac computer, here is the step: Nvme software support at launch of rock 5b
Mainline support is going to be a catastrophe with anyone using real PD supplies getting infinite boot loops.
If FUSB302 on mainline is a problem, then we should somehow fix the mainline, right? We do think these kind of smart power design is way better than than fixed one.
I think PD is great for mobile battery devices/tablets/laptops where charging might take place on multiple devices.
I am a bit mweh when it comes to PD as generally when a SBC is in place so the PSU is of fixed use and not often shared elsewhere as you lose power to the SBC.
The 5.148V - 26V buck is a great piece of silicon https://www.monolithicpower.com/en/mp8759.html as does a quite a good job of an extended efficiency vs volts/ampage curve. That is the star of the show than some negotiated multi-rail PD.
So far a cheap 5.5mm barrel to USB-C still makes a fixed 12v much more cost effective than any equivalent PD and after negotiation at a fixed volt I still fail to see any advantage of PD.
If you can reclaim the x2 CPU cooler mount holes and then have room for a 5.5mm DC jack plug then please do as that then releases the USB-C to be a USB-C.
And there’s the reason:
Maybe someone can find a better solution, but when I wrote the code I just
could not get it to work reliably without resetting everything during
registration.
Since FUSB302 appears on all new RK boards these days (since being part of the reference design and as such copy&pasted) a fix in mainline will be needed. It might help pinging those at Rockchip dedicated to such stuff [1] early since everything that happens upstream usually takes ages.
[1] Kever Yang years ago, no idea whether he’s still in charge of community communication
There are a lot of commits in mainline kernel after rockchip’s 5.10 vendor kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/usb/typec/tcpm/tcpm.c?h=v5.18.12. I guess this commit is related: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/usb/typec/tcpm/tcpm.c?h=v5.18.12&id=90b8aa9f5b09edae6928c0561f933fec9f7a9987.
This issue is reported in 2020 on board ROC-RK3399-PC. I don’t know if this board still have this issue in 2022 using mainline kernel 5.18. Can anyone who has this board confirm that?
I have the board, the issue persists.
BTW: RK’s BSP kernel provides some more info about what FUSB302 is doing:
root@rock-5b:/home/tk# cat /sys/kernel/debug/usb/fusb302-4-0022 /sys/kernel/debug/usb/tcpm-4-0022 | sort
[ 1.755413] sw reset
[ 1.759173] fusb302 device ID: 0x91
[ 1.759177] Setting usb_comm capable false
[ 1.763830] pd := off
[ 1.763832] vbus is already Off
[ 1.763834] charge is already Off
[ 1.763837] vconn is already Off
[ 1.763839] Setting voltage/current limit 0 mV 0 mA
[ 1.763844] polarity 0
[ 1.763863] Requesting mux state 0, usb-role 0, orientation 0
[ 1.764672] pd header := Sink, Device
[ 1.764692] state change INVALID_STATE -> SNK_UNATTACHED [rev1 NONE_AMS]
[ 1.764707] cc1=Open, cc2=Open
[ 1.764709] CC1: 0 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected]
[ 1.764714] 4-0022: registered
[ 1.764716] Setting usb_comm capable false
[ 1.769380] pd := off
[ 1.769382] vbus is already Off
[ 1.769384] charge is already Off
[ 1.769385] vconn is already Off
[ 1.769387] Setting voltage/current limit 0 mV 0 mA
[ 1.769393] polarity 0
[ 1.769396] Requesting mux state 0, usb-role 0, orientation 0
[ 1.770189] pd header := Sink, Device
[ 1.770193] cc:=2
[ 1.770195] cc := Rd
[ 1.775633] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev1 NONE_AMS]
[ 1.775639] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[ 1.775641] pending state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED @ 920 ms [rev1 NONE_AMS]
[ 2.695799] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [delayed 920 ms]
[ 2.695815] Start toggling
[ 2.700884] start drp toggling
[ 2.703321] IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[ 2.703326] IRQ: VBUS_OK, vbus=On
[ 2.710079] IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
[ 2.710083] IRQ: TOGDONE
[ 2.715941] detected cc1=Open, cc2=Rp-3.0
[ 2.715957] cc1=Open, cc2=Rp-3.0
[ 2.715965] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected]
[ 2.715976] state change TOGGLING -> SNK_ATTACH_WAIT [rev1 NONE_AMS]
[ 2.715984] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 200 ms [rev1 NONE_AMS]
[ 2.916158] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 200 ms]
[ 2.916173] state change SNK_DEBOUNCED -> SNK_ATTACHED [rev1 NONE_AMS]
[ 2.916180] polarity 1
[ 2.916186] Requesting mux state 1, usb-role 2, orientation 2
[ 2.917179] pd header := Sink, Device
[ 2.917187] state change SNK_ATTACHED -> SNK_STARTUP [rev1 NONE_AMS]
[ 2.917214] state change SNK_STARTUP -> SNK_DISCOVERY [rev3 NONE_AMS]
[ 2.917220] Setting voltage/current limit 5000 mV 3000 mA
[ 2.917229] vbus=0 charge:=1
[ 2.917233] vbus is already Off
[ 2.917239] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS]
[ 2.922261] pd := on
[ 2.922267] pending state change SNK_WAIT_CAPABILITIES -> SNK_SOFT_RESET @ 310 ms [rev3 NONE_AMS]
[ 3.232482] state change SNK_WAIT_CAPABILITIES -> SNK_SOFT_RESET [delayed 310 ms]
[ 3.232500] AMS SOFT_RESET_AMS start
[ 3.232506] state change SNK_SOFT_RESET -> AMS_START [rev3 SOFT_RESET_AMS]
[ 3.232514] state change AMS_START -> SOFT_RESET_SEND [rev3 SOFT_RESET_AMS]
[ 3.232524] PD TX, header: 0x8d
[ 3.234669] sending PD message header: 8d
[ 3.234676] sending PD message len: 0
[ 3.237683] IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
[ 3.237710] IRQ: BC_LVL, handler pending
[ 3.237729] IRQ: PD tx success
[ 3.239940] PD message header: 161
[ 3.239955] PD message len: 0
[ 3.239968] PD TX complete, status: 0
[ 3.239989] pending state change SOFT_RESET_SEND -> HARD_RESET_SEND @ 60 ms [rev3 SOFT_RESET_AMS]
[ 3.242005] IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[ 3.242010] IRQ: BC_LVL, handler pending
[ 3.242013] IRQ: PD sent good CRC
[ 3.244030] PD message header: 163
[ 3.244034] PD message len: 0
[ 3.244041] PD RX, header: 0x163 [1]
[ 3.244043] AMS SOFT_RESET_AMS finished
[ 3.244044] state change SOFT_RESET_SEND -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS]
[ 3.248786] pd := on
[ 3.248791] pending state change SNK_WAIT_CAPABILITIES -> HARD_RESET_SEND @ 310 ms [rev3 NONE_AMS]
[ 3.267788] IRQ: 0x41, a: 0x00, b: 0x01, status0: 0x93
[ 3.267814] IRQ: BC_LVL, handler pending
[ 3.267843] IRQ: PD sent good CRC
[ 3.272130] PD message header: 4361
[ 3.272146] PD message len: 16
[ 3.272343] PD RX, header: 0x4361 [1]
[ 3.272362] PDO 0: type 0, 5000 mV, 3000 mA [DE]
[ 3.272371] PDO 1: type 0, 9000 mV, 2660 mA []
[ 3.272379] PDO 2: type 0, 12000 mV, 2000 mA []
[ 3.272386] PDO 3: type 0, 15000 mV, 1600 mA []
[ 3.272391] state change SNK_WAIT_CAPABILITIES -> SNK_NEGOTIATE_CAPABILITIES [rev2 POWER_NEGOTIATION]
[ 3.272404] Setting usb_comm capable false
[ 3.272426] cc=2 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1
[ 3.272434] Requesting PDO 2: 12000 mV, 1500 mA
[ 3.272440] PD TX, header: 0x1242
[ 3.277338] IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x93
[ 3.277365] IRQ: BC_LVL, handler pending
[ 3.279872] sending PD message header: 1242
[ 3.279873] sending PD message len: 4
[ 3.281907] IRQ: 0x41, a: 0x00, b: 0x00, status0: 0x93
[ 3.281912] IRQ: BC_LVL, handler pending
[ 3.283879] IRQ: 0x51, a: 0x04, b: 0x00, status0: 0x93
[ 3.283884] IRQ: BC_LVL, handler pending
[ 3.283887] IRQ: PD tx success
[ 3.285769] PD message header: 361
[ 3.285772] PD message len: 0
[ 3.285774] PD TX complete, status: 0
[ 3.285781] pending state change SNK_NEGOTIATE_CAPABILITIES -> HARD_RESET_SEND @ 60 ms [rev2 POWER_NEGOTIATION]
[ 3.287744] IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[ 3.287749] IRQ: BC_LVL, handler pending
[ 3.287752] IRQ: PD sent good CRC
[ 3.289885] PD message header: 563
[ 3.289889] PD message len: 0
[ 3.289906] PD RX, header: 0x563 [1]
[ 3.289913] state change SNK_NEGOTIATE_CAPABILITIES -> SNK_TRANSITION_SINK [rev2 POWER_NEGOTIATION]
[ 3.289922] Setting standby current 5000 mV @ 500 mA
[ 3.289926] Setting voltage/current limit 5000 mV 500 mA
[ 3.289938] pending state change SNK_TRANSITION_SINK -> HARD_RESET_SEND @ 500 ms [rev2 POWER_NEGOTIATION]
[ 3.291819] IRQ: 0x41, a: 0x00, b: 0x00, status0: 0x93
[ 3.291823] IRQ: BC_LVL, handler pending
[ 3.325054] BC_LVL handler, status0=0x93
[ 3.524945] IRQ: 0x41, a: 0x00, b: 0x01, status0: 0x93
[ 3.524953] IRQ: BC_LVL, handler pending
[ 3.524957] IRQ: PD sent good CRC
[ 3.526676] PD message header: 766
[ 3.526679] PD message len: 0
[ 3.526704] PD RX, header: 0x766 [1]
[ 3.526717] Setting voltage/current limit 12000 mV 1500 mA
[ 3.526733] state change SNK_TRANSITION_SINK -> SNK_READY [rev2 POWER_NEGOTIATION]
[ 3.526896] AMS POWER_NEGOTIATION finished
[ 3.528498] IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x93
[ 3.528503] IRQ: BC_LVL, handler pending
[ 3.561447] BC_LVL handler, status0=0x93
Also the only kernel I know when Booting Linux doesn’t happen at 0.000000:
root@rock-5b:/sys/kernel/debug/usb# dmesg | head -n1
[ 6.428628] Booting Linux on physical CPU 0x0000000000 [0x412fd050]Yeah I don’t wanna trigger anybody here, but just made interesting discovery in a Rock 4 chat on Discord
TLDR;
User has Rock pi 4B+
This is all speculation, but generally speaking… I think these IC’s oriented around USB-PD and SoCs, kernel code whatever-- are oriented around platforms that are battery first aka usually some persistent power to the PMIC from a lipo and charge controller etc, vs these things are getting full de-energized and having to dance.
So we’re fighting an anti-pattern.
I think this might be a noise transient issue for the Rock Pi 4 family. If the schematic is accurate, it uses a single 16V capacitor for input voltage filtering. PD will negotiate 20V (mine does) and will damage that capacitor. Over time I suspect any power line transients will go straight through the buck converter and cause unpredictable disturbances to the attached hardware.
Sorry for /offtopic
Journalctl always shows the same if pd or dumb.
Jul 16 09:46:54 rock-5b kernel: vcc12v_dcin: 12000 mV, enabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc12v-dcin: vcc12v_dcin supplying 12000000uV
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc5v0-sys: Looking up vin-supply from device tree
Jul 16 09:46:54 rock-5b kernel: vcc5v0_sys: supplied by vcc12v_dcin
Jul 16 09:46:54 rock-5b kernel: vcc12v_dcin: could not add device link regulator.2: -ENOENT
Jul 16 09:46:54 rock-5b kernel: vcc5v0_sys: 5000 mV, enabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc5v0-sys: vcc5v0_sys supplying 5000000uV
Jul 16 09:46:54 rock-5b kernel: wifi_disable: no parameters, enabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage wifi-diable-gpio-regulator: wifi_disable supplying 0uV
Jul 16 09:46:54 rock-5b kernel: bt_wake: no parameters, enabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage bt-wake-gpio-regulator: bt_wake supplying 0uV
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc-1v1-nldo-s3: Looking up vin-supply from device tree
Jul 16 09:46:54 rock-5b kernel: vcc_1v1_nldo_s3: supplied by vcc5v0_sys
Jul 16 09:46:54 rock-5b kernel: vcc5v0_sys: could not add device link regulator.5: -ENOENT
Jul 16 09:46:54 rock-5b kernel: vcc_1v1_nldo_s3: 1100 mV, enabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc-1v1-nldo-s3: vcc_1v1_nldo_s3 supplying 1100000uV
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc5v0-host-regulator: Looking up vin-supply from device tree
Jul 16 09:46:54 rock-5b kernel: vcc5v0_host: supplied by vcc5v0_sys
Jul 16 09:46:54 rock-5b kernel: vcc5v0_sys: could not add device link regulator.6: -ENOENT
Jul 16 09:46:54 rock-5b kernel: vcc5v0_host: 5000 mV, enabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc5v0-host-regulator: vcc5v0_host supplying 5000000uV
Jul 16 09:46:54 rock-5b kernel: vcc3v3_pcie2x1l0: 3300 mV, disabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc3v3-pcie2x1l0: Looking up vin-supply from device tree
Jul 16 09:46:54 rock-5b kernel: vcc3v3_pcie2x1l0: supplied by vcc5v0_sys
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc3v3-pcie2x1l0: vcc3v3_pcie2x1l0 supplying 3300000uV
Jul 16 09:46:54 rock-5b kernel: vcc3v3_pcie30: 3300 mV, disabled
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc3v3-pcie30: Looking up vin-supply from device tree
Jul 16 09:46:54 rock-5b kernel: vcc3v3_pcie30: supplied by vcc5v0_sys
Jul 16 09:46:54 rock-5b kernel: reg-fixed-voltage vcc3v3-pcie30: vcc3v3_pcie30 supplying 3300000uV
Will the production rock 5 get a jumper or a proper button for maskrom instead of that cellophane button. (Personally I prefer jumper)
Yeah please after my Radxa Zero disaster of the cellophane part detaching it would be good.
Also the onboard buttons for power and restore as they are perfectly ok but jumpers might even be cheaper but allow you to have wired switches instead or even relays (as on a PC mobo).
That leaves dsi/csi/gpio/hdmi-in to maybe have a bottom mount bracket with extension cables/risers and all i/o could be on a single plane which apart from needing a cutout would be fairly easy to fit in any enclosure bigger than the approx 100x72mm of the Rock5b.
Guess it could be top mount if you have a blower than axial fan as a gpio riser would prob choke otherwise.
Purely as an extra in the shop but it would be an auto buy for me at least.
I think most of the time, you can just use the loader/recovery button, which is next to the power button. Maskrom button should be seldom used since the bootloader corruption is not often.
Sadly maskrom is easier. There’s a lot of software orchestration typically to use the loader / recovery button.
For people on this debug thread It’s always simpler to write an entire image.
So I had more time to test mine.
First I had a problem that appears specific to my board: it will randomly reboot. It does not seem related to overheating, CPU load (idle will also reboot), or power supply issues.
Networking and storage are both great on the board, but I had the following issues:
More details @ https://www.cnx-software.com/2022/07/20/rock-5b-rk3588-sbc-preview-what-works-what-doesnt-in-debian-11/