[bisected] USB Ethernet Gadget cannot be detected since 0f315f8 [Zero W 1.1][dwc2]

[kakurasan]

Describe the bug Only when *.{bin,dat,elf} firmware files (in /boot) are newer than 32c2899, my PC or Pi 3B+ doesn't detect my Zero WH (USB Ethernet Gadget).

When I replace these files with 32c2899, my PC/3B+ successfully detects USB Ethernet Gadget (kernel 5.4.83+ from Raspberry Pi OS "2021-01-11" works). Without the old firmware files, it doesn't work. That's why I think this is a bug in firmware.

To reproduce

• Add dtoverlay=dwc2,dr_mode=peripheral to config.txt
• Connect Pi Zero WH (USB device port) to Linux PC using USB cable
• Boot Raspberry Pi OS (newer than "2017-06-21" release), load g_ether module, and setup networking
• Run dmesg on PC and check whether it detects USB Ethernet Gadget

Expected behaviour USB Ethernet Gadget is detected.

Actual behaviour USB Ethernet Gadget is not detected.

System

• Hardware
  • USB Gadget
    • Zero WH (Raspberry Pi Zero W Rev 1.1 from dmesg output)
    • JustBoom DAC Zero pHAT is installed
  • Host
    • x86_64 Linux PC or Raspberry Pi 3B+
• Software
  • Raspberry Pi OS, newer than "2017-06-21" release
  • Any newer firmware than 32c2899
  • Any kernel

Logs When problematic firmware is used, there is no related dmesg output.

Additional context The last "good" firmware files are:

$ sha256sum *.{bin,dat,elf}
cf8ab8989e0a93b160b9ae45becac7467e610c7f005a4d3a3bc27cf0adcc1d15  bootcode.bin
6867735c360f5d52c59ee8a87095dd219931c0c1cfa28f0e9c4b874eec654dca  fixup.dat
e1d9806959f686dd9322c9122a5d9a3961d972f82de8e8158f995604f50bd43c  fixup_cd.dat
42c74519076c09c295d5dd37a333266b308b7eab99e025de6bee90c35b344ada  fixup_db.dat
dd4498d4367731b7527cf970ce6c1860e0aa788b45c564674eadd16a257e7f07  fixup_x.dat
c26b36ff9a60d98d90fb258fa1a7d74516396f7f34bac3f889502c8d8c7ed686  start.elf
3b29721066d64e8c46309035a9eb21436c5739f7576b5beec61bfa0aca1a8542  start_cd.elf
1c603b4bce88fac78f79cfc668d0de7c48598205b502ab9f72cf42cd91e7442c  start_db.elf
ac0c67de2a889233384f7869cfe0cfd0dc512a74b548d4bf76870c0adff7dbf5  start_x.elf

"2017-06-21" release contains them and it works out of the box.

The first "problematic" firmware is 0f315f8 (firmware: Revert Change USB PHY settings to make device mode work correctly.).

[popcornmix]

@ghollingworth @timg236 This firmware changed an usb_mdio_write. The value in the "good" firmware was unconditionally set to the value that is now set when in USB_MODE_DEVICE.

Does this ring a bell? Is this caused by wrong type of cable?

[timg236]

I'm not familiar with this PHY but from the commit comments, it looks like it could by a combination of board + cable from the git history

I'm running g_ether on a Pi Zero and Pi 3B+ as a reference for Pi 4B. I don't have a PiZero W to hand, although, it might only impact some boards because g_ether on Pi Zero W is quite popular and lots of people will be running this on newer firmware.

[cleverca22]

This firmware changed an usb_mdio_write.

is there any information on why PHY is in use? why cant linux just manage the PHY directly?

[ghollingworth]

Because there is no driver and no documentation (yes even we don't have any documentation for this)!

The bug looks exactly the same as the one I was diagnosing and went away when I changed the USB cable for a good quality one. The single-ended impedance of the poor cable was 2x what the USB spec said it was supposed to be.

Even without this change I still found some Pi zeroes would not enumerate, so the change pointed at here is not a fix, only 'a fix for this particular device'

The issue is actually in the Pi 3's USB hub, it is detecting a disconnect shortly after a connection because a reflection from the Pi Zero makes the signal drop below the minimum level (which normally signifies a disconnect). The hub is supposed to ignore this within some time of the initial connection but clearly doesn't.

I was unable to reproduce this if I stuck a hub in the way or used a better quality USB cable.

[cleverca22]

semi-related, if i let the closed/official bootcode.bin do a network boot on a pi2, and then the custom start.elf doesnt change the PHY configs linux is able to do usb activity, but its silently corrupting all tcp packets coming over the network!

but i did find a set of phy configs elsewhere, that entirely eliminate that issue

that implies that its a problem between the phy and dwc? and that the phy was validating the checksums on the usb packets, but then corrupting on-route to the dwc?

Because there is no driver

a driver could be written for linux, but without the things rpi engineers have figured out, it would just be a big ugly ball of magic numbers with no reason behind their choices