USB PD request makes gadgets not work with some hosts

[jclark]

Describe the bug

When connecting a Raspberry Pi 5 (or CM5) to some hosts (recent Apple devices) using a direct USB C cable connection and configuring the Pi as a USB ethernet gadget, the host does not recognize the ethernet gadget. This happens only in cases where the Pi sends a USB PD request to the host. If the EEPROM is configured not to send a USB PD request, then the host does recognize the gadget. The hosts where this happen include

• iPad Pro M4
• Mac mini M4
• MacBook Air M3

Steps to reproduce the behaviour

1. in /boot/firmware/config.txt, add a line dtoverlay=dwc2,dr_mode=peripheral
2. in /boot/firmware/cmdline.txt, append modules-load=dwc2,g_ether
3. add a link-local NM connection: nmcli con add type ethernet ifname usb0 con-name usb0 ipv4.method link-local
4. override the udev rule that makes gadget interfaces unmanaged: touch /etc/udev/rules.d/85-nm-unmanaged.rules
5. use a USB C cable to connect the USB C port on the Pi 5 to one of the hosts listed above

What I see on the Pi:

• the usb0 interface appears
• od -t u4 --endian=big /proc/device-tree/chosen/power/max_current shows 3000mA current has been negotiated
• ethtool usb0 shows no link detected
• NetworkManager does not activate the usb0 connection
• nmcli dev show usb0 shows carrier off

On the host no ethernet gadget shows up in Settings.

What I expect to see on the Pi:

• NetworkManager does activate the usb0 connection
• ethtool usb0 shows link detected
• usb0 gets a link local address

I also expect that the ethernet gadget shows up on the host and that I can ssh into the Pi using ssh raspberrypi.local

If I use rpi-eeprom-config -e to add PSU_MAX_CURRENT=3000, then I see what I expect to see.

Device (s)

Raspberry Pi 5, Raspberry Pi CM5

System

/etc/rpi-issue

Raspberry Pi reference 2024-07-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 48efb5fc5485fafdc9de8ad481eb5c09e1182656, stage4

Firmware

2024/12/19 11:57:13
Copyright (c) 2012 Broadcom
version ccf64a4f (release) (embedded)

Kernel

Linux raspberrypi 6.6.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux

Logs

When things work I see

[    2.595364] dwc2 1000480000.usb: bound driver g_ether
[    2.848187] dwc2 1000480000.usb: new device is high-speed
[    2.898746] dwc2 1000480000.usb: new device is high-speed
[    2.920452] dwc2 1000480000.usb: new address 1

When things don't work, I don't see the last three lines.

Additional context

Everything works OK on:

• iPad Mini Gen 7
• iPad 10th Gen

On these, /proc/device-tree/chosen/power/max_current shows a current of 1500mA. Everything also works if I put a USB PD powered hub between the host and the Pi.

I used a USB tester (a POWER-Z KM003C) with Windows software that allows the USB PD messages to be captured. With the iPad Mini, the iPad advertises some PDOs, but the Raspberry Pi never sends any PD requests (presumably because it is offering less than 5V3A). With the iPad Pro, the Raspberry Pi sends a request for 5V3A, which the iPad accepts. The iPad Pro then sends a whole bunch of messages (e.g. Get Sink Cap, Get Source Cap Extended, Get Sink Cap Extended, Get Revision, Get Source Info), which the Pi does not respond to. None of these messages got sent in the iPad Mini case. This suggests that a possible explanation is that the iPad is expecting a more complete USB PD implementation than the Pi provides.

[jclark]

I should also mention that I tried a wide variety of USB C cables, both with and without eMarkers.

The PSU_MAX_CURRENT workaround works with iPad Pro M4, MacBook Air M3 and the rear (Thunderbolt 4) ports of the Mac mini M4, but not with the front (USB C) ports of the Mac mini M4. This is all with the Pi 5.

Possibly related to #6289

[jclark]

Here's another report confirming that things don't work on the iPad Pro M4 https://github.com/verxion/RaspberryPi/issues/1

[NumberOneGit]

I’m experiencing the same issue with my CM5 and the official IO board. If you take the same properly set up CM5 module and test it on a CM4 board (assuming you have access to one), could you let me know whether that setup works properly? In my case, the CM5 works perfectly on the CM4 boards that I previously used for ethernet gadgets. I currently only have the IO board for CM5 as few (if any?) other options exist.

[jclark]

This problem can't possibly occur with the CM4 IO board, since it uses a 12V barrel connector for power rather than USB PD, and the connector for the dwc2 is MicroUSB which doesn't have the CC lines used for USB PD negotiation.

There's Waveshare PoE board for the CM5. I haven't tried, but it is highly likely to have the same problem.

[NumberOneGit]

To clarify, I was referring to CM4 3rd party carrier boards that use a USB2 connection that has a USB-C connector to supply power. I can get gadget mode to work successfully 100% of the time on a CM5 module when on one of these boards, and when trying the same setup with the CM5 official IO board I can’t get a connection to my M2 iPad Pro. With a proper cable E-marker cable I can make a gadget connection to my M3 Macbook Pro.

[jclark]

Which carrier board specifically?

[NumberOneGit]

Piunora and Seeed Studio Dual Gigabit Ethernet both work without issue on OTG on my iPad with a CM5. As mentioned, I can swap the same CM5 module from the official IO board to the CM4 boards and reliably get an OTG connection. I can only get an OTG connection on the same iPad on my official CM5 IO board by using a USB-C to A back to C adapter setup, with the female A port facing the CM5. The internal resistor in the USB-A setup explicitly defines the device/host relationship. I have adapters that claim to be PD rated so may not have the same power limitations that normal USB-A would have, but since my normal use case would not be with the RPi IO board, I haven’t tested this too much.

I think it would be good to resolve whether a hardware solution is required to ensure USB-C to USB-C device/host relationship can be established or if this can be sorted out via a firmware change but haven’t seen the Pi Foundation acknowledge this in posts. The issue seems to go back (link is for pi 5 not cm5): https://github.com/raspberrypi/bookworm-feedback/issues/77 The topic was marked as resolved but the reasoning was odd as the thread was not about mass storage gadget, but rather OTG functionality on a running OS.

[NumberOneGit]

@jclark Once I had an early boot UART connector on my CM5, I realized that the CM4 boards were only working because they have 5k1 to ground resistors on CC at the USB-C port. In parallel with the 5k1 resistors that serve this purpose within the SoC on CC lines (which didn’t exist in CM4), this breaks PD implementation and allows data role negotiation to proceed. So it was working reliably, but without PD power negotiation backing up your earlier assessment. Adding a breakout board that just adds 5k1 to ground on the CC input of the CM5 IO boards yields the same results.
Based on the final message of the topic I posted in the previous message, it seems like Pi Foundation expects topics like this to be on their main forum. If you were to post your findings there, maybe there could be traction on this issue.