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
ROCK 5B Debug Party Invitation
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.
3 Likes
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.
1 Like
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
1 Like
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]
1 Like
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+
- RTC clock has battery.
- when using USB-PD to power, depower and power againā¦ the RTC clock resets
- when using dumb 5V, the RTC clock value persists over power cycling
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.
2 Likes
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
2 Likes
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)
2 Likes
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.
1 Like
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.
2 Likes
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:
- Only the HDMI port next to the USB ports works. The other HDMI output port does not work, and neither USB-C DisplayPort alt mode (my USB dock is not supported either, see below)
- 3D GPU acceleration not supported, itās using llvmpipe software rendering
- VPU not tested hardware video playback, as Iām not sure which program to use if any.
- NPU driver spew several errors. Iāve not tested it because the documentation is not clear.
- USB Type-C port does not seem to work properly with a MINIX USB-C dock with a 480GB SSD. Itās detected but emits errors such as āusb usb10-port1: Cannot enable. Maybe the USB cable is bad?ā, and the SSD does not show up at all.
- Bluetooth is not working out of the box
More details @ https://www.cnx-software.com/2022/07/20/rock-5b-rk3588-sbc-preview-what-works-what-doesnt-in-debian-11/
4 Likes
I got my board a couple of days ago, and Iām noticing that performance with Panfrost isnāt very good compared to libmali. Has anyone else experienced this?
2 Likes
- 3D GPU acceleration not supported, itās using llvmpipe software rendering
3D GPU should be enabled, test with glmark2-es2-wayland as @icecream95 shows
1 Like
I did just realize that emmc is removableā¦ soooo maskrom really just needed when SPI is screwed upā¦so thats good news
As far as I knew things had got as far as the G57.
The G610 is Vallhall but there are differences and I donāt think Collabora or others have had devices or time to do anything for G610/710 as much went into apple silicon.
Anyway it gives us chance to check out if opencl works out better with libmali on the BSP as with kernel version 5.10 none of the latest Mesa has been backported as far as I know.
It might be the 1st board I have seen ArmNN run well on without crashing as the G610 is supposedly very strong as an AI accelerator also.
To be honest even surprised you got it running as you need Mesa 22.02 min and a very new kernel, maybe 5.19 min.
On Mali-G52 (with Mesa), overall glmark2 score is
improved from 1026 to 1037. Geometry-heavy scenes like -bshading are
improved from 1068 to 1098
5.10 without backports was released 2020-12-13 which is sort of around Mesa 20.3.0 Release Notes / 2020-12-03 time.
Itās not using any mali driver in the Debian 11 image, only software rendering.