Pi 5 dwc2 overlay fails
Closed this issue · 47 comments
Likely more of a Pi 5 issue than a strictly Bookworm issue but as the two go together...
Hardware: Pi 5 8GB, 16GB SD card
OS: Raspberry Pi OS Bookworm full downloaded and updated today. Booting to command line w/o automatic login
Problem: enabling the dwc2 overlay and USB controller fails. The dwc2 kernel modules is loaded, g_* modules will load but the corresponding devices are not present on either RPiOS or the USB host.
Steps to reproduce:
- Download, install, and update OS.
- Add any one of the following to /boot/config.txt
[all]
dtoverlay=dwc2
[all]
dtoverlay=dwc2,dr_mode=host
[all]
dtoverlay=dwc2[,dr_mode=peripheral
- Reboot
Other information:
dmesg includes the following:
pi@pi5:~ $ dmesg|grep dwc
[ 1.333392] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 1.339252] dwc_otg: FIQ enabled
[ 1.339255] dwc_otg: NAK holdoff enabled
[ 1.339257] dwc_otg: FIQ split-transaction FSM enabled
[ 1.339261] Module dwc_common_port init
[ 2.757311] dwc2 107c480000.usb: supply vusb_d not found, using dummy regulator
[ 2.768661] dwc2 107c480000.usb: supply vusb_a not found, using dummy regulator
[ 2.811867] dwc2 107c480000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST
[ 2.820521] dwc2: probe of 107c480000.usb failed with error -16
Attmpting to manually load the dtoverlay (sudo dtoverlay dwc2) results in
pi@pi5:~ $ sudo dtoverlay dwc2
DTOVERLAY[warn]: no matching platform found
Same SD card and cables work as expected with a 4B.
See also https://forums.raspberrypi.com/viewtopic.php?t=357757
Thanks - we're aware of this problem. The Pi 5 bootloader/firmware is missing a small amount of initialisation code required to enable the DWC OTG USB interface.
noticed that there is a dwc2-pi5, for dtoverlay in config.txt should it be
dtoverlay=dwc2-pi5
?
dwc2 - the suffix is not required, although I don't think the firmware support is available yet
Any movement on this issue? Really enjoyed the ipad pro direct USB over Ethernet VNC setup on the Pi 4. Don't see any workarounds to get that working for the 5
It's coming - we're not exactly resting on our laurels here.
Ooh I see this commit yesterday,
raspberrypi/firmware@ce3a0b4
raspberrypi/firmware@9272f0f
and a version bump here
raspberrypi/firmware@83dafbc
Does that mean that Pi 5 dwc2 is available if I do a sudo rpi-update I can get v6.1.61 and this fix?
Thanks
Ooh I see this commit yesterday, raspberrypi/firmware@ce3a0b4 raspberrypi/firmware@9272f0f
and a version bump here raspberrypi/firmware@83dafbc
Does that mean that Pi 5 dwc2 is available if I do a
sudo rpi-updateI can get v6.1.61 and this fix?
No, as pelwell says, it's coming.
Those commits are steps on the road, but not there yet.
My apologies for asking, but is there at least an approximate time horizon when you expect this regression to be fixed? Right now we're in the process of procuring new Raspberry Pis for our remote learning setups (which use this function), and we're currently wondering if we need to procure 4Bs instead of 5s, or if we should wait a few more days. Again, my apologies for asking, I know you're doing your very best, but I hope you can give us an estimate (or a "we can't tell at all" if that is the case) to help us decide which path to go. Thank you very much.
I assume the dwc2 problem also applies to using the USB-C connector in Host mode? I have a USB-C audio dac I want to use but can't get it to show up.
Correct.
Cause found.
raspberrypi/linux#5772 fixes the kernel side, but there's a bootloader update required too.
Cause found.
raspberrypi/linux#5772 fixes the kernel side, but there's a bootloader update required too.
Thank you very much for working on this.
Is there any way I can help with the Bootloader side? I'd be happy to donate my time for this. (I know C/C++ [and Python and FORTRAN, but I suspect those won't be that helpful here])
I think the bootloader-update part of this is in raspberrypi/rpi-eeprom#503
I think the bootloader-update part of this is in raspberrypi/rpi-eeprom#503
Ah cool, thank you for the info!
I see that the EEPROM part of this got pushed out as an update yesterday. Could someone from RPi comment on when the kernel side might make it out into the field?
That depends on how large a field you want. It's available now as a beta via sudo rpi-update. Updates to the stable branch (and thence to the regular raspberrypi-kernel package) are less frequent, but can be accelerated if an important feature or bug fix is required.
@pelwell Thanks for the reply. I have tried with the 6.1.66-v8-16k+ (Mon Dec 11 12:10:50 GMT 2023 ) kernel installed by rpi-update but I can't get any host computer to recognise the presence of the Pi5, either as a serial gadget or as an ethernet gadget. Would you expect it to be working with that kernel?
I've not tried it in either mode myself, but I expected that with the fixed DTB and the appropriate config.txt and cmdlline.txt settings that both host mode and gadget mode would work.
What configuration changes have you made? Is this something you've had working on an older Pi?
This is all working with ecm and rndis ethernet devices.
Thanks for getting this working again, I'll update my scripts for modifying RaspberryPiOS images over Christmas.
Hello, has this problem been fixed?
We believe so, provided the EEPROM image is also updated.
Issue does not appear to be resolved.
Updated the EEPROM on a Raspberry Pi 5. The USB network device is now created on the Pi 5, which did not occur before the EEPROM update.
All looks fine from the Pi 5; USB device is created, is recognized in Network Manager, and can create a shared connection.
But the client hardware on the other end of the USB cable does not detect a USB Ethernet device. Same thing observed with both a Linux and Mac device.
Move the MicroSD card to a Pi 4, and it works perfectly.
Fully updated Raspbian OS. Managing with network manager.
Entry in cmdline.txt is "modules-load=dwc2,g_ether"
Entry in config.txt is "dtoverlay=dwc2"
/etc/modules contains "libcomposite" and "g_ether"
@olsonmn I have this working, but I had to remove the serial port I was also creating. You can find my script for setting up the devices here: https://www.hardill.me.uk/wordpress/2023/12/23/pi5-usb-c-gadget/
You should not need the g_ether
@olsonmn I have this working, but I had to remove the serial port I was also creating. You can find my script for setting up the devices here: https://www.hardill.me.uk/wordpress/2023/12/23/pi5-usb-c-gadget/
You should not need the
g_ether
Thank you for the quick response; it is now working.
Applying the "sudo rpi-update" from your blog post fixed the problem. I had run "sudo rpi-eeprom-update -a", so my guess is the latest EEPROM updates have not yet made it through to the public repositories.
Just received my new Pi5 and can confirm stock issues, the applied fix/update is working with my pi 4 scripts now.
Thanks so much, i was worried this would get ignored.
I was able to make it work on non Apple devices, but it didn't work on either my iPad or MacBook.
The only way I've managed to connect to my apple devices was through USB-A to USB-C (I had to use an adapter for that).
Anyone managed to connect to Apple devices using USB-C to USB-C?
I did get it to work USB C to USB C on a Macbook Air, but it does not appear to work 100% of the time.
I've found my Macbook Pro has a very limited ability to power devices over USB C (which is all it has).
I suspect his is the root of many of the "USB C to USB C" issues. It is not the USB A that solves the problem, it is the powered hub in the middle that is solving the problem.
I suspect his is the root of many of the "USB C to USB C" issues. It is not the USB A that solves the problem, it is the powered hub in the middle that is solving the problem.
I'm not using a powered hub between my iPad and Pi5, just a USB-C to many USB-A ports adapter. Also, my Macbook is the 14 inch Apple M1 Pro version with Thunderbolt 4 (USB-C) ports. I would expect it to have enough power to support a RPi.
From a MacRumors answer (https://forums.macrumors.com/threads/usb-power-output-of-m1-and-m2-macbook-usb-c-thunderbolt-ports.2356508/):
Minimum power output for the first port is 15W, and 7.5W for subsequent ports, per thunderbolt/USB4 specification.
So if you have nothing else plugged in you might get 3A @ 5V (marginal on a Pi 5), otherwise it could be 1.5A (nope).
Just confirming the "sudo rpi-update" fixed the USB C audio detection and function. Thank you. Nathan Scherdin
May I ask from which build/OS to initiate the command? Just to have a reliable method...
From a MacRumors answer (https://forums.macrumors.com/threads/usb-power-output-of-m1-and-m2-macbook-usb-c-thunderbolt-ports.2356508/):
Minimum power output for the first port is 15W, and 7.5W for subsequent ports, per thunderbolt/USB4 specification.
So if you have nothing else plugged in you might get 3A @ 5V (marginal on a Pi 5), otherwise it could be 1.5A (nope).
Ok... just to rule out the power problem, I'm using an unpowered usb hub with both iPad and Macbook Pro. That's why I can't understand why it works with a USB-C hub connecting via its USB-A port to RPi's USB-C port, and the direct USB-C to USB-C doesn't work. I can even ssh to the RPi5 via Wi-Fi in both scenarios.
From a MacRumors answer (https://forums.macrumors.com/threads/usb-power-output-of-m1-and-m2-macbook-usb-c-thunderbolt-ports.2356508/):
Minimum power output for the first port is 15W, and 7.5W for subsequent ports, per thunderbolt/USB4 specification.
So if you have nothing else plugged in you might get 3A @ 5V (marginal on a Pi 5), otherwise it could be 1.5A (nope).
Ok... just to rule out the power problem, I'm using an unpowered usb hub with both iPad and Macbook Pro. That's why I can't understand why it works with a USB-C hub connecting via its USB-A port to RPi's USB-C port, and the direct USB-C to USB-C doesn't work. I can even ssh to the RPi5 via Wi-Fi in both scenarios.
Hm. Something like in
https://forums.raspberrypi.com/viewtopic.php?t=246348
where in the hub setup the roles would be clear?
I’ve just updated the RPi5’s firmware this morning and USB-C to C worked with my MacBook, but stopped working after reboot. My naive guess is that something was reset during the upgrade, but changed during the reboot.
I even tried to force an update (delting .bootloader_revision and .firmware_revision files), but din’t work anymore.
It's possible that cold boot and reboot work differently. And beware the danger of looking for patterns in essentially random data.
I can also confirm that update worked only for a short time. The device is no longer showing up properly after full power down.
I have tried forcing full USB power and power is a 65W adapter.
Not solved. Just going to return this pi and return to the pi 4. Pi5 also has issues with the CSI-2 adapter duo to lacking hardware encoding. I will try again after the tech is more developed.
Hello, just to share, I managed to get the keyboard and mouse to work over OTG using PiOS 32-bit, but not 64-bit.
I have a notebook-like dock from Nexdock, that uses a USB-C to provide power and share keyboard & mouse, with the video going by HDMI.
All I had to do was burn the OS on the SD, do the usual updates and upgrades, and add the following to the /boot/config.txt:
dtoverlay=dwc2,dr_mode=host,g_hid
Btw, the dock also has a USB port and micro SD card slot, both are working as well.
First I was trying the 64bits PiOS, but on dmesg I was getting the following error:
device descriptor read/64, error -32
Searching I found a StackExchange saying that this is an issue with OSs and some hardware/BIOS over 64-bit OS, so I tried 32-bit, and worked. Will try again in the future, but for now it's working fine, no issues after reboot.
Issue does not appear to be resolved.
Updated the EEPROM on a Raspberry Pi 5. The USB network device is now created on the Pi 5, which did not occur before the EEPROM update.
All looks fine from the Pi 5; USB device is created, is recognized in Network Manager, and can create a shared connection.
But the client hardware on the other end of the USB cable does not detect a USB Ethernet device. Same thing observed with both a Linux and Mac device.
Move the MicroSD card to a Pi 4, and it works perfectly.
Fully updated Raspbian OS. Managing with network manager.
Entry in cmdline.txt is "modules-load=dwc2,g_ether" Entry in config.txt is "dtoverlay=dwc2" /etc/modules contains "libcomposite" and "g_ether"
how to do the last step
Can we have a short discussion (and maybe testing) what the correct dr_mode config.txt settings per gadget would be?
AFAIK, there are three modes for (forced) dr_mode : otg, host and peripheral. In gadget mode I would expect "peripheral" to be the one to use, to connect keyboards and othe HIDs I would expect it to be"otg" or "host".
I may be wrong, but since I have seen them used arbitrarily or not at all in this thread, it would be nice to see what the correct setting would be and if helps with any of the observed oddities.
Also found a discussion on a similar topic that mentions deprecation and cmdline.txt vs config.txt, so it might be worth a second look:
Gadget mode = peripheral
Host controller = host
otg tells the driver to use the OTG pin to select between the two - it's safer to avoid this mode.
Just FYI. I can get the mass storage gadget to work on the RPi5 after an rpi-update, but only on 32bits OS. It does not work with 64bits OS.
I use
dtoverlay=dwc2
And my app can "insert" and "remove" multiple virtual thumb drives, multiple times.
USB mass storage gadget mode works on 64-bit operating systems e.g. here's a buildroot 64-bit mass-storage gadget.
https://github.com/raspberrypi/usbboot/tree/master/mass-storage-gadget64
I'm locking this bug because the issue reported issue is resolved and the forums are a more appropriate place for general topic discussions.