Pi Connection via USB fails before x86 raspbian boot

I'm building a system, which needs GPIO access on a x86 machine.
The GPIO access works great. However, it falls apart once reboots come into play:

Plugging the PIZero in, lsusb shows Broadcom Corp.
If rpiboot loaded the OS on the PiZero and the PI is connected to an USB port that remains powered after shutdown, a reboot does not break anything. You can still use pigs for instance, after the x86 raspbian booted.
However, if power is cut or if the Pi is connected without loading the OS via RPIboot prior, then the linux kernel fails to boot properly and throws
device descriptor read/64, error -110
a couple of times with the last error being
device not accepting address 4
and all devices on that USB controller are blocked until the RPI is removed (Mouse / Keyboard are not active on Raspbian desktop).
It does not show up in lsusb and obviously rpiboot fails to find anything. Unplugging and plugging the usb back in solves this beheviour.
If it is still connected and a shutdown is initiated in that state, then the shutdown does not finish and remains stuck until the RPi is disconnected, with the same errors being thrown.

This issue may be a firmware bug and may be related to this issue with similar symptoms: raspberrypi/linux#2684

I want to make an automated system, currently physical interaction is required if the system is unplugged from the wall.
Leaving a Post-it on the machine saying "please unplug und plug back in that USB cord in case the system is moved or unplugged" is not an option ;]

[maxnet]

Suspect it is related to a bug in the Pi zero's bootrom (the one described here: https://www.raspberrypi.org/documentation/hardware/computemodule/cm-emmc-flashing.md )
If your computer reacts badly to that, to the point that other USB devices on the same controller are not enumerated and practically rendered non-functional, I am afraid I do not have a real fix for that.

However as a workaround you do can put the gpioexpander files on SD card instead of booting from USB.
This repository only contains the source code, binaries can be found here: https://github.com/raspberrypi/usbbootgui
Press "clone or download" -> "download .zip" -> put contents of the directory gpioexpander/output (including overlays subdirectory) on an empty FAT formatted SD card and just leave that in the Pi zero.

on an empty FAT formatted SD card and just leave that in the Pi zero.

Just what I had in mind as well. I just pray to the gods, that the Pi Zero will boot faster than x86 Raspbian and not cause complications.
Just for context:

If your computer reacts badly to that, to the point that other USB devices on the same controller are not enumerated and practically rendered non-functional, I am afraid I do not have a real fix for that.

Let's pretend it does not react "badly" (maybe for some other user), is there a fix, as your post might suggest?
At least for the non-functional part, the mouse and keyboard still show up in lsusb, they just dont't work until the PI is removed and I got told in IRC, that tthe non-functional part is correct behavior:
it happens because hardware signals that it is a USB device, but then there is no code to respond to USB requests so the host side times out, and possibly disables the root port, which disables all devices on the bus

[maxnet]

Just what I had in mind as well. I just pray to the gods, that the Pi Zero will boot faster than x86 Raspbian
and not cause complications.

Should boot pretty fast, and does not write to SD card, so you should not have the normal problems you can get with Raspbian.

Let's pretend it does not react "badly" (maybe for some other user), is there a fix, as your post might suggest?

The issue does not happen on my computer, so think it may be specific to USB controller used in your computer.
The action taken (whether it disables root port or not etc) in case a wrong packet is received may or may not be fixable in the USB controller's Linux driver.
But I cannot help with that.

[maxnet]

it happens because hardware signals that it is a USB device, but then there is no code to respond to USB
requests so the host

There does is code (contained in the bootrom in the SoC) that responds to USB requests.
But the response it sends has a bug.

The issue does not happen on my computer, so think it may be specific to USB controller used in your computer.

Interesting, so may a PCIe USB controller solve the problem?
Both USB2.0 and 3.0 ports (which are different controllers) have the same problem.

Or could it be the AMD 970 chipset that's at fault and since they all go through the chipset (and would explain why the USB 2.0 and 3.0 controller both fail... mobo diagram on page 8 http://download.gigabyte.eu/FileList/Manual/mb_manual_ga-970a-ud3_v.1.2_e.pdf)

[maxnet]

Interesting, so may a PCIe USB controller solve the problem?

No idea.
Do not have any.

Or could it be the AMD 970 chipset that's at fault and since they all go through the chipset

At fault is a bit of a big word.
The bootcode is the one at fault. It should not sent invalid responses.
But how forgiving USB controllers or their drivers are with misbehaving USB devices can differ yes.

I tried it out with a PCI USB controller... and it worked!
No more errors, all detected on boot, verified it in mutliple ways.

The controller that didn't work are the AMD Chipset's USB 2.0 controllers "AMD SB7x0/SB8x0/SB9x0 EHCI / OHCI Controller"
I have another controller inside, the "Etron EJ168 USB 3.0 Host Controller" that didn't work either.

The PCI (not PCIe) card with "VT6202 USB 1.1 Controller" and "VIA USB2.0 controller (rev51)" made it work.

So.. Either those both controller don't work with the forgiving of USB errors or there is something about the AMD 970 chipset, that screws me over.

[maxnet]

Do the controllers that have problems use the same driver by any chance?
Look for "kernel driver in use" in lspci -v

Do the controllers that have problems use the same driver by any chance?
Look for "kernel driver in use" in lspci -v

No. But here is the strange thing: The PCI card's driver is also the same 0.o

Of the non working one's:
AMD USB OHCI: ohci-pci
AMD USB EHCI: ehci-pci
Etron USB 3.0: xhci_hcd

Working PCI Via card:
USB2.0: ehci-pci
VIA UHCI USB 1.1: uhci_hcd

The PCI card (not pcie) exposes 3 controllers: two USB 1.1 and one USB 2.0's. But since I get USB 2.0 speed's from those ports I presume, that the USB2.0 controller is used and thus the ehci-pci driver is the same(?) as used by the non-working ports.

[maxnet]

Managed to reproduce your problem on an AMD box.

On boot it seems it stops to enumerate devices the moment it gets to the Pi zero.

A keyboard at usb 1-2 does is detected, but once it gets to usb 1-3 that has the Pi zero it fails, and then also the other devices at higher USB port numbers are not enumerated.

[    1.514657] usb 1-2: New USB device found, idVendor=046d, idProduct=c326
[    1.514659] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    1.514660] usb 1-2: Product: USB Keyboard
[    1.514661] usb 1-2: Manufacturer: Logitech
[    1.554487] usbcore: registered new interface driver usbhid
[    1.554488] usbhid: USB HID core driver
[    1.557203] input: Logitech USB Keyboard as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-2/1-2:1.0/0003:046D:C326.0001/input/input2
[    1.616138] hid-generic 0003:046D:C326.0001: input,hidraw0: USB HID v1.10 Keyboard [Logitech USB Keyboard] on usb-0000:03:00.0-2/input0
[    1.616292] input: Logitech USB Keyboard as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-2/1-2:1.1/0003:046D:C326.0002/input/input3
[    1.676162] hid-generic 0003:046D:C326.0002: input,hiddev0,hidraw1: USB HID v1.10 Device [Logitech USB Keyboard] on usb-0000:03:00.0-2/input1
[    1.716082] usb 1-3: new full-speed USB device number 3 using xhci_hcd
[    7.072299] usb 1-3: device descriptor read/64, error -110

The keyboard at lower USB port number does continue to work though, so I don't think it disabled root port, like the person you spoke to on IRC suggested.
But something else is wrong.
Not my area of expertise though.

[ali1234]

I'm the person from IRC :)

For me this bug does disable the root port (it makes my mouse and keyboard and everything else stop working, and dmesg confirms it if I ssh in.)

The known issue you linked to seems not quite right for this reason: If I have a kernel/root fs that doesn't touch USB then the USB will stay in this "bad" state even if it is unplugged and plugged in again after restarting the host. So it can't be caused by one bad packet from the bootcode as it is no longer running.

However if I start a USB service and then stop it, the error goes away, again even if I unplug, restart the host, and plug it in again.

To me this suggests that the USB hardware is being put into the active state and then hangs the bus because there is no software to handle requests. But then if you enable and disable a service, linux will correctly put the hardware into the inactive state so that this doesn't happen any more. So for this reason I strongly suspect that the bootcode is leaving the USB hardware in the active state before booting the kernel, instead of resetting it back to the inactive state, and also the Linux driver doesn't handle properly the case where the hardware is set active at boot time (it should disable it until there is a service is bound.)