We are using an OMAP5432 ES2.0 on a uEVM board with the dwc3 OtG block
configured for xHCI host mode. When connecting to another board with a
similar block running in device mode with g_ether we re seeing
corrupted packets.
The ARP responses we get have an extra 2 bytes on the header, as shown
below and have 4 extra bytes on the end of the packet.
00:35:06.644708 ff:ff:d2:40:90:44 > 2e:00:ff:ff:ff:ff, ethertype Unknown
(0xd3c
0x0000: 0806 0001 0800 0604 0001 d240 9044 d3c0 ...........@.D..
0x0010: c0a8 0101 0000 0000 0000 c0a8 0103 dead ................
0x0020: beef ..
From what I can see of the xHCI specification, the transfer
buffers should support unaligned data. From tracing through
xhci_urb_enqueue the buffer being passed is edb07042 (phys adb07042).
Unfortunately we do not have enough information about the dwc3 core
to work out if there is an problem with unaligned buffers, or if we
are missing some configuration of either the host or the otg block
to ensure that it properly handles the alignment issues.
We are currently assuming that the issue is to do with the xHCI
on the DWC3 as the gadget side works with a Intel laptop using a
NEC controller to provide a reliable network link between g_ether
and laptop's Linux cdc-ethernet.
The only other issue we had was the xhci_reset() code causing the
whole OtG block to fail, so we have currently remove the issue of
the CMD_RESET from the xhci-hcd driver to allow the system to keep
going. If this is the issue then we will need to find some other
way of resetting the entire block (currently the otg block is
initialised by the dwc3 driver before it instantiates a xHCI
platform device to handle the host side)
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
