dwc_otg: add handling of SPLIT transaction data toggle errors

[P33M]

Previously a data toggle error on packets from a USB1.1 device behind
a TT would result in the Pi locking up as the driver never handled
the associated interrupt. Patch adds basic retry mechanism and
interrupt acknowledgement to cater for either a chance toggle error or
for devices that have a broken initial toggle state (FT8U232/FT232BM).

Fixes lockup described in #241

[popcornmix]

Thanks, fix available through rpi-update for testing.

[ghost]

Hi All,

Sorry I would like to reopen this issue. Since commit of this code my RasPi will not reboot correctly. Basically it appears to gets stuck post loader, pre kernel stage, as syslog is clean, and the screen is stuck at the syslog message. The only way to recover is to power cycle. On the next boot the RasPi will come up clean. The firmware is the latest as of today. 26/3. I've reverted the two commits that have dealt with dwg_otg c4564d4 & f676910 (this one) and the reboot issue goes away. RasPi has a D-Link Dub-H4 attached.

Any ideas?

John

[P33M]

So to be clear it's f676910 that causes your raspi to hang on boot?

How are you building/installing the firmware? Can we get a picture of the hang?
Can you retry with a fresh raspbian SD card and a fresh rpi-update?
What happens if you boot with nothing connected to USB?

[ghost]

Yes, that is my belief.
The firmware is just copied from the git hub when I do a new build. They are from ~20th of March update. As I use the RasPi in a headless manner, I don't use any video extra's
md5sums of firmware:
c221dc09af38669475a10f5582085add start_cd.elf
5068149e113168b0d13bff31d0e88c40 fixup_cd.dat
d934c3d788ed3a03a65ec9988d8185bb bootcode.bin

The hangs are as follows....
usb1-1.3 2101:8500 #4 USB 2 Hub ( d-link hub)
usb1-1.3:1.0 2101:8501 #5 ( d-link hub)
usb1-1.3.2 413c:2003 #6 (dell usb keyboard )
(last line on screen)
usb1-1.3.3: new high_speed USB device number 7 using dwc_otg
( This is a Netgear WN111v2 WIFI dongle, and the only to get past it is to power off)
(When it reboots, it comes up clean, and the next line is:)
usb1-1.3.3 New USB device found, idVendor=0846, idProduct=9001

As it appears to be USB traffic issue, I've also tested a TP-Link WN422N
This time the lockup was:
1-1.3.2 new low-speed USB device number 6 using dwc_otg
(power off to recover)
I've also tested it without the WIFI dongle present, but still with the external hub and it hangs again at
1-1.3.2 new low-speed USB device number 6 using dwc_otg
(power off to recover)

When I use a kernel with the two commits (mentioned above) removed all appears to be fine.

[P33M]

So steps to reproduce so far:

1. Use kernel with two commits added - c4564d4 and f676910
2. Reboot the Pi after a successful usage session
3. system hangs during device probing - visible as no futher bootup messages on an attached monitor
4. If the system is power cycled the Pi then boots normally.

• Is the DUB-H4 externally powered?
• If it is, is the hub capable of backfeeding power up through its mini-B port to the pi?
• What is your TP1-TP2 voltage measured while booting?
• Which version causes the hang? Can you boot with kernel @ f676910 but not @ c4564d4?
• Are you copying all the associated kernel modules across to /lib/modules on the sd card with each kernel change?

Once we eliminate those variables, then:

• What is the minimum number of attached USB devices that causes a booting lockup? It does not appear to be tied to a specific USB device at present.