Hi U-Boot,
We've hit a weird problem at $dayjob with a board using the Marvell CN9130 SoC and using the asix88179 USB-Eth adapter.
The problem is after enabling and unrelated feature in u-boot the asix88179 fails to receive data (I can confirm that the link partner does see packets in the transmit direction)
=> version U-Boot 2022.01 (Nov 08 2024 - 09:45:44 +0000) => usb start starting USB... Bus usb3@500000: Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb3@500000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => ping ${serverip} Waiting for Ethernet connection... unable to connect. Reset Ethernet Device Waiting for Ethernet connection... done. Using ax88179_eth device Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5 Rx: failed to receive: -5
Abort ping failed; host 10.37.233.65 is not alive => <INTERRUPT>
Debugging a little we can see that the -EIO is actually because xhci_bulk_tx() hits a timeout from xhci_wait_for_event().
We think this is triggered by the u-boot image size crossing some boundary (the problem seems to start when .bss_end crosses 0x00000000000f0000) although I've so far been unable to find specifically why that might be. As far as I can tell u-boot is being built relocatably and nothing is overlapping. I also considered that ATF might be preventing access to something but so far I see no evidence of this.
If I turn off some features to reduce the build size the problem goes away. That is actually how we've avoided the immediate issue, although that means the problem will likely come back and an inopportune time.
Does anyone have any ideas as to what the true root cause might be? I'm a bit stumped.
Thanks, Chris