00:07 <dieselnutjob> if you think realtek is bad, I have Unisoc UWE5621DS in my device :-(

16:24 <vulpes2[m]> I've got an rk3328 board that doesn't seem to want to initialize its xhci bus and I can't figure out why

16:25 <vulpes2[m]> board is the nanopi r2s and pretty much everything I've tried so far cannot detect the usb3 gigabit ethernet adapter

16:25 <vulpes2[m]> tried latest mainline u-boot release, latest ATF, various mainline and LTS kernels, and the only thing that worked was rk's vendor kernel

16:27 <vulpes2[m]> any clues on what actually went wrong? I tried generating a diff between the rk vendor kernel and the matching mainline tag, and there seems to be a missing USB3 PHY driver

16:28 <vulpes2[m]> which is even more confusing because it does work for most people, only a small portion of people have non-functional USB3

16:29 <vulpes2[m]> the same image I made with buildroot (mainline uboot, atf and kernel) also has functional USB3 on the nanopi neo3 which is basically identical to the r2s, sans the onboard USB GBE adapter

16:32 <vulpes2[m]> error message from the kernel is the dreaded `Cannot enable. Maybe the USB cable is bad?`

16:35 <CounterPillow> I think usb3 for that needs some hack that never made it upstream, but my memory is hazy on it

16:35 <vulpes2[m]> I've also measured the various vcc rails to make sure the usb ethernet chip is receiving power on both the 5v and 1v rails, and they are all working fine even on an image that doesn't have functional usb3

16:35 <vulpes2[m]> at this point I've tried everything I can think of and made absolutely zero progress so far :/

16:36 <vulpes2[m]> CounterPillow: yeah I suspect it has something to do with the usb3 phy

16:37 <vulpes2[m]> https://github.com/friendlyarm/kernel-rockchip/tree/nanopi-r2-v5.15.y

16:37 <vulpes2[m]> this is the vendor kernel I've tested

16:39 <CounterPillow> vulpes2[m]: https://patchwork.kernel.org/project/linux-rockchip/list/?series=385165&archive=both

16:39 <CounterPillow> seemingly never made it in

16:39 <vulpes2[m]> that's unfortunate

16:39 <vulpes2[m]> https://github.com/friendlyarm/kernel-rockchip/blob/nanopi-r2-v5.15.y/drivers/phy/rockchip/phy-rockchip-inno-usb3.c

16:40 <vulpes2[m]> and I guess we are talking about the same thing

16:40 <CounterPillow> https://0x0.st/oEMS.png

16:44 <CounterPillow> I could technically pick it back up since I do have an rk3328 board but in practice I have diminished desire to work on that anymore since rk3566 is just better in most regards (asides: non-mainline u-boot and atf currently)

16:46 <vulpes2[m]> it would be great if you don't mind picking it back up, it seems like I'm not the only one affected and there is basically no solution on this

16:46 <CounterPillow> I can also ping Peter Geis about it, he showed some interest in looking into it again

16:46 <vulpes2[m]> https://github.com/openwrt/openwrt/issues/10293

16:47 <vulpes2[m]> It's weird because most people's boards will work without issues, I'm the unlucky few who got one that doesn't work without the vendor kernel

16:48 <diederik> I hope it'll get picked up again as I have 4 Rock64's

16:50 <wens> my anker six port power brick seems to be outputing too high a voltage, tripping the quartz64's overvoltage protection :/

16:53 <wens> the model B that is

17:08 <CounterPillow> wens: you could theoretically try desoldering R56 to disable OVP, but that seems adventurous

17:10 <CounterPillow> well, not disable, but bypass the adjustment. not sure what that chip does with unadjusted mode, but it does make that an option in the datasheet

17:13 <CounterPillow> Actually don't take any suggestions from me regarding that, I have no clue how this chip works and the datasheet doesn't enlighten me much