amcduffee

I too have encountered this issue after downloading Armbian 22.08 Jammy XFCE (Release date: Oct 28, 2022). It appears that X server is crashing on launch with a backtrace. See the attached Xorg.0.log. Searching on Google leads to the following thread and the suggestion to use mesa-git instead of the distro mesa: https://forum.pine64.org/showthread.php?tid=8915 I know it is an old thread, but it got me thinking that this may be a related and/or similar issue. At the very least it made me realize the issue is likely related to Mesa drivers, so I decided to try enabling Oibaf PPA to get the latest Mesa drivers. While doing so I came to realize that Armbian is already building images with the Oibaf PPA enabled: anderson@rock64:/etc/apt/sources.list.d$ cat oibaf.list deb [signed-by=/usr/share/keyrings/oibaf.gpg] http://ppa.launchpadcontent.net/oibaf/graphics-drivers/ubuntu/ jammy main So, I decided to instead purge out the PPA to see if the issue is only present in newer Mesa drivers: anderson@rock64:~$ sudo apt install ppa-purge anderson@rock64:~$ sudo ppa-purge ppa:oibaf/graphics-drivers anderson@rock64:~$ sudo reboot After purging the Oibaf PPA drivers I can at least get X server to start, however it is not a good solution. There are some graphical glitches such as black bands across the screen when it is redrawn in high activity cases. These black bands happen for me when I move the mouse cursor around quickly at the login screen, or when I drag a window around rapidly on the desktop. In any event, this almost certainly appears to be an issue with the rockchip_drm driver and/or Mesa driver. I don't know if this is in Mesa, Xorg or both, but it likely needs a bug filed upstream with one of those projects in order to get a fix. Xorg.0.log

Yw and likewise. I am still hoping to find someone who can help puzzle through what is missing to get OTG switching fully functional on Armbian 'current' branch kernels for the RockPi 4b. I have at least realized through our discussion that the 'dwc3-rockchip' driver is entirely absent in the 5.10.y current kernels, so that almost certainly needs to be patched in for there to be any shot at getting it to work. It is also clear why it is absent based on the upstream NAK link you provided. These past couple days are the first time I have ever ventured to understand what extcon is and what it is used for. It is still vague, but I am guessing it is meant to be an abstraction between drivers that need some awareness of each others events? So, in your case the dwc3-rockchip driver for the dwc3 controller needs a way to be aware of the UFP/DFP mode switch events generated by the fusb302 driver? Does the later version of the patch provide the controller reset using a different approach? Based on the patch thread it is mandatory to reset the dwc3 controller, so if the newer patch doesn't have equivalent behavior, implemented a different way, then it is very likely an issue. After closer examination of the dwc3-rockchip driver in the Ayufan kernel I can now see that the dwc3_rockchip_otg_extcon_evt_work callback seems to use an OTG reset to force the dwc controller into P2 power state. Upon resuming the PM runtime in core.c re-initializes the dwc3 controller. I guess this is their workaround to not being able to remove 'static' and call dwc3_phy_setup() directly. I understand, but I was more suggesting that you could use the Ayufan kernel as a point of reference to see how the drivers differ. In other words, does the Ayufan version have logic that your ported driver doesn't? If so, it could be the missing piece. For example, the PM trick I pointed out above. Also, it may be worth a shot to try porting the drivers, as is, from the Ayufan kernel to see if they work when compiled into your kernel? The RockPi4 B I am working with is a bit interesting because although it does have a fusb302 chip and a type-C connector it is only used to power the board. The dwc3 OTG port is wired to one of the type-A connectors. So, although technically there is a fusb302 preset it isn't used for anything USB related (i.e. fusb302.ko is compiled but not loaded). Both host and peripheral modes are fully working, on 5.10.y with Terry's DTS patch, as far as I have tested. However, I can only switch between the modes by changing dr_mode in DT and rebooting. The live switching doesn't work because I now realize the 'dwc3-of-simple' driver is being used which doesn't support OTG switching. For clarity, since the RockPi4 B connects the OTG port to a type-A connector it can only accomplish mode switching using either a sysfs file (soft switch as I call it), or by reacting to the physical switch that Radxa put on their board underneath the USB ports (hard switch as I call it). I don't care about the hard switch, so I don't plan to make that functional on 5.10.y. I only need the soft switch via a sysfs file and the drivers that can effect the switch correctly on a running system. I presume your problem is a missing interaction between the fusb302 UFP/DFP mode switch events and a correct dwc3 controller reset catalyzed by the dwc3-rockchip driver. If this isn't happening then when you modprobe the fusb302 module you lock the system because nothing causes the requisite dwc3 controller reset so that both chips are synchronized on what mode they should be operating in? I would definitely compare the dwc3-rockchip driver in the Ayufan kernel to the one you ported to see if any differences stand out.

Thanks for sharing the link, that was an interesting read. Seeing the patches jogged my memory a bit. The 'dwc3_rockchip_otg_extcon_evt_work' function is what handles the actual mode switching. Its execution is scheduled using a work queue via the dwc3_rockchip_*_notifier functions which are based on some extcon notifier. I have almost no understanding of what extcon is nor how the notifiers work and how they are ultimately connected to the physical switch. It is possible the physical switch manipulates a basic resistance circuit to force the CC pin resistance to the required amount to force UFP/DFP modes. Once the resistance is forced the dwc3 controller generates IRQs that inform the driver via notifiers? I am guessing here, but it makes sense because the OTG port is wired to a type-A connector which means the physical switch could control the CC pin resistances without interfering since CC pin can't be wired to a type-A connector. You are right about the dwc3 controller needing to be reset at the same time, the patch thread discusses this requirement. In fact, I think it was this very requirement that led to them stripping the 'static' keyword from the 'dwc3_phy_setup' function in dwc3/core.c so it could be called from their new dwc3/dwc3-rockchip.c driver. It was this change in particular that caused the immediate NAK for upstream. I presume that if your port attempts lack the required logic to reset the dwc3 controller managed in core.c that is likely why the work queue item is hanging or locking up the system? What kernel version and from what source did you port the driver? If it isn't from the 'legacy' branch repo used by Armbian it might be worth trying again with the following version which I can confirm has functioning mode switch logic: https://github.com/ayufan-rock64/linux-kernel tag:4.4.202-1237-rockchip-ayufan Are you possibly running into issues getting back to USB2 HS peripheral mode because you still have ported code compiled in? I ask because I took Terry's DTS patch from above and integrated it into the Armbian build for a linux-5.10.y 'current' branch kernel (specifically 5.10.92-rockchip64) and have the peripheral mode operational as long as 'dr_mode = "peripheral"' is set in the built DTB as shown in the patch. I have tested it with mass storage, hid and ncm gadgets, all working as expected.

I recall looking into how the switch worked in the past. It is a live switch and can be used after boot to switch between modes. I remember coming across the driver callback (GPIO based ISR?) that is registered to handle whenever the switch is flipped. The callback itself doesn't effect the mode change immediately but rather schedules a work item to make it happen later on another thread. I don't think the switch plays a role in DTB overlays at boot, but I could be wrong on that point. I am not a kernel/driver developer myself so my understanding of the lower level driver details is fuzzy at best. I am fairly good at finding my way around the kernel layers and associating what parts/drivers are responsible for the actions I am interested in and/or troubleshooting. I suspect the issue you are encountering with the driver not working and work queue items hanging will require the attention of a driver developer that is familiar enough with the DWC3 controller, its registers, transition timing sensitivities, etc. Once things hit the level that requires understanding the datasheets on the controllers and ICs I can't help much, unfortunately. Do you have a link to the upstream BSP patch that was rejected? I would like to read up on that. It certainly helps to explain the lackluster support for RK3399 OTG on mainline kernels. A shame really because I find the RK3399 platform to be very capable otherwise...

I know that not all features of legacy vendor kernels can be supported in mainline kernels. However, has anyone considered and/or attempted to get the OTG capability working in a current/mainline kernel? I have a couple different projects where I need to have OTG working so I can have the RockPi 4 be a USB device (e.g. mass storage, ethernet, etc.). For the time being this means I can only use the legacy kernels, but I am hoping that might change in the future. There are a number of different RK3399 boards with DWC3 controllers that could benefit from such a feature being available, right? Since I don't understand the kernel/driver/platform glue layers well enough to make an attempt myself, I am hoping someone who knows more about this might have some extra info? Is it planned for the future? Too complex? Something else?