Odd error with cn9130, asix88179 and xhci

[Tom Rini]

On Wed, Nov 20, 2024 at 11:29:43AM +1300, Chris Packham wrote:
> 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 at 500000: Register 2000120 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> scanning bus usb3 at 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.

Hummmm. Since you note it seems to be when a threshold is crossed in BSS
size, add something to the BSS of a variable size that you control, and
after confirming that you can replicate the problem this way, grow it
just past the limit and compare u-boot.map files in the works/fails
cases to see just what's being moved around?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241122/bf800a67/attachment.sig>