The TAC gets stuck in bootloader when connected via USB to some PCs

[hnez]

When connected to some host computers via the USB-C port the LXA TAC will stop the automatic boot process without an obvious reason (no key presses were performed):

…
state: Using bucket 0@0x00000000
malloc space: 0xcfdfe5e0 -> 0xdfbfcbbf (size 254 MiB)
eth0: got preset MAC address: 18:74:e2:a0:01:a0
eth1: got preset MAC address: 18:74:e2:a0:01:a1
eth2: got preset MAC address: 18:74:e2:a0:01:a2
found force-builtin environment, using defaultenv
multi_bind: creating Fastboot function
multi_bind: creating ACM function
g_multi gadget0: Multifunction Composite Gadget
g_multi gadget0: g_multi ready
dwc2 49000000.usb-otg@49000000.of: bound driver g_multi
dwc2 49000000.usb-otg@49000000.of: new address 1

Hit m for menu or any to stop autoboot:    3g_multi gadget0: high-speed config #1: Multifunction Composite Gadget
ERROR: dwc2 49000000.usb-otg@49000000.of: dwc2_ep_enable: No suitable fifo found

eth0: 1000Mbps full duplex link detected
barebox@Linux Automation Test Automation Controller (TAC) Gen 3:/ 

This is likely due to the host performing a couple of probes via USB:

Mar 26 11:04:04 havel kernel: usb 5-2: USB disconnect, device number 39
Mar 26 11:04:07 havel kernel: usb 5-2: new high-speed USB device number 40 using xhci_hcd
Mar 26 11:04:08 havel kernel: usb 5-2: New USB device found, idVendor=1d6b, idProduct=0104, bcdDevice= 6.02
Mar 26 11:04:08 havel kernel: usb 5-2: New USB device strings: Mfr=0, Product=2, SerialNumber=3
Mar 26 11:04:08 havel kernel: usb 5-2: Product: Linux Automation Test Automation Controller (TAC) Gen 3
Mar 26 11:04:08 havel kernel: usb 5-2: SerialNumber: unset
Mar 26 11:04:08 havel kernel: cdc_acm 5-2:1.1: ttyACM0: USB ACM device
Mar 26 11:04:08 havel mtp-probe[972661]: checking bus 5, device 40: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb5/5-2"
Mar 26 11:04:08 havel mtp-probe[972661]: bus: 5, device: 40 was not an MTP device
Mar 26 11:04:08 havel mtp-probe[972666]: checking bus 5, device 40: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.4/usb5/5-2"
Mar 26 11:04:08 havel mtp-probe[972666]: bus: 5, device: 40 was not an MTP device
Mar 26 11:04:08 havel Thunar[972665]: thunar-volman: Unsupported USB device type "usb".
Mar 26 11:04:08 havel Thunar[972678]: thunar-volman: Unsupported USB device type "cdc_acm".
Mar 26 11:04:08 havel Thunar[972685]: thunar-volman: Unsupported USB device type "cdc_acm".
Mar 26 11:04:08 havel Thunar[972690]: thunar-volman: Unsupported USB device type "(null)".

Just connecting the TAC to a host should not prevent it from booting.

[a3f]

This reminds me a bit of https://lore.barebox.org/barebox/20190920075813.22471-4-ahmad@a3f.at/
Maybe some service is writing a character into the ttyACM console? It would be interesting to add some logging to find out what's written. If that's the cause, using e.g. ctrl+c as boot abort character will probably work around this.

[hnez]

Hi @a3f,

thanks for chiming in on this. We have already tried out using ctrl+c as only boot abort character but that alone did not seem to do the trick.
I guess we'll just need a bit more debug output from barebox to determine what interrupted the boot.

[a3f]

thanks for chiming in on this. We have already tried out using ctrl+c as only boot abort character but that alone did not seem to do the trick.

Could it be the same issue described in #125 (comment) or do you already have (hardware) pull-ups?

I guess we'll just need a bit more debug output from barebox to determine what interrupted the boot.

I just Cc'd you on a series to add CONFIG_EVENT_EVBUG, which should aid with debugging this.

[hnez]

It turns out that fwupd has a plugin that probes fastboot devices to check if they need updating. The fastboot getvar calls it does trigger the barebox boot abort logic.

There is a patch on the barebox mailing list that should fix this.
We likely want to apply that to meta-lxatac and drive the mainlining of said patch forward.

Thank you to @lichtfeind for investigating this issue and @a3f for remembering the patch and also @bith3ad for writing the patch in the first place.