this has been a problem in rawhide for months, but since most of the time i use the device over ethernet/uart, i didn't know about it until i updated it a month or so ago and nothing on usb would work, i just chalked it up to a bad kernel and powered it off until i decided to go back to stable (fc39), to which i found out, oops, it's there too, and i made this bug report upstream uboot commit b71f74eab42782199757e146483126aee5e3c271 it removes some dts stuff, which it seems some is required to keep the regulator that powers basic usb on i'll leave the finer details to you
that commit doesn't have anything to do with it, but it's absolutely uboot that is the issue playing around with uboot's environment variables turns into a make or break situation if i use upstream uboot, it seems to work if i use upstream uboot to write it's default envs to disk (env default -f -a; saveenv), it seems to work if i revert to fedora's uboot (uboot-images-armv8-2023.07-3.fc39.noarch) using the envs written by upstream uboot, it seems to work if i revert to fedora's uboot, using it's default envs (env default -f -a; saveenv), it goes badly working usb commonalities: % lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 038f:6001 [unknown] [unknown] Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub boot sdcard is labeled as mmcblk0 uboot reads /boot/efi/rockchip/rk3328-roc-cc.dtb % dtc /proc/device-tree/ | grep firefly label = "firefly:green:user"; label = "firefly:red:power"; i changed the label names as a canary to track what was happening (also to match the board's actual led colors) not working commonalities:: % lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub boot sdcard is labeled as mmcblk1 uboot does not read the dtb in the efi dir % dtc /proc/device-tree/ | grep firefly label = "firefly:yellow:user"; label = "firefly:blue:power";
There's been a bunch of churn upstream around bootstd, moving to a new dwc3 "generic" driver for some of the rockchip USB3 controllers plus a number of other things. We're working with upstream to resolve all of these for the F-40 cycle. I also have a lack of time ATM. I will update this once I think it's fixed but it will take some time. If you need USB I probably suggest to go back to 2023.04 (the one shipped in F-38) for the time being.
Can you test uboot-tools-2024.04-1.fc41 and let me know, I believe the patches I pulled in there should resolve this.
FEDORA-2024-dbf55dbc52 (bcm283x-firmware-20240823-1.6c7d171.fc41, crust-firmware-0.6-3.fc41, and 1 more) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-dbf55dbc52
FEDORA-2024-dbf55dbc52 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-dbf55dbc52` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-dbf55dbc52 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-dbf55dbc52 (bcm283x-firmware-20240823-1.6c7d171.fc41, crust-firmware-0.6-3.fc41, and 1 more) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days