u-boot crashes if mass-storage devices are connected via USB-C

[Marek Vasut]

On 3/2/23 10:14, Janne Grunau wrote:
> On 2023-03-01 23:51:14 +0100, Marek Vasut wrote:
>> On 3/1/23 21:34, Simon Glass wrote:
>>> +Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini
>>>
>>> On Wed, 1 Mar 2023 at 08:12, bluetail <a-development+asahi at posteo.de> wrote:
>>>>
>>>> Hello. user kettenis aka "Mark Kettenis" guided me write my bug report
>>>> to this email. "bluetail: please report these usb bugs upstream; they're
>>>> almost certainly not hardware-specific"
>>>>
>>>> But before, jannau aka Janne Grunau asked me to give the version output
>>>> of  `pacman -Qi uboot-asahi` to which I replied 2022.10.asahi1-1.
>>>> Because I had the feeling that sometimes the reboot with a USB-C
>>>> connected device succeeds, depending how many bays are populated. But I
>>>> have no evidence for that.
>>>> I did try other USB Type C Cables, but without success of fixing the
>>>> underlying issue. The device works fine via USB Type A or C fine if
>>>> plugged in AFTER u-boot.
>>>> But, u-boot does not support USB Type A yet, which is why it wont break
>>>> my boot sequence with USB Type A.
>>>>
>>>> Essentially, I connect a mass-storage device to the USB-C port of a Mac
>>>> Mini 2020 (M1), and it leads to the issue in the attachment.
>>>> I was able to reproduce it with Icy Box IB-3810 and ICY BOX IB-3805.
>>>> Initially I thought this issue was only for some devices (also attached
>>>> here) https://github.com/AsahiLinux/u-boot/issues/4 but it appears this
>>>> might be a issue that is with many devices.
>>>>
>>>> If you need any more information, please feel free to ask. I am very
>>>> eager to have this issue fixed because it seems to be a very broad issue
>>>> with mass media storage in general.
>>>> uname-r returns 6.1.0-asahi-2-2-edge-ARCH
>> Would it be possible to check whether current u-boot/master works any better
> 
> Reproduced with b0eda49bc9b0 ("Merge tag 'u-boot-at91-fixes-2023.04-a'
> of https://source.denx.de/u-boot/custodians/u-boot-at91") and Icy Box
> IB-3804-C31 (same design as IB-3805/IB-3810 but just a single 4 port
> USB3 hub + 4 independent asmedia usb3 to sata converters).
> 
> | scanning bus usb at b02280000 for devices... Device NOT ready
> |    Request Sense returned 02 3A 00
> | Device NOT ready
> |    Request Sense returned 02 3A 00
> | Resetting EP 0...
> | WARN halted endpoint, queueing URB anyway.
> | Unexpected XHCI event TRB, skipping... (c9208350 0000010f 13000000 04008401)
> | "Synchronous Abort" handler, esr 0x96000005
> | elr: 000000000003934c lr : 000000000003934c (reloc)
> | elr: 0000010fcd24034c lr : 0000010fcd24034c

Could you decode the trace and check where exactly this exception occurred ?

It should be enough to run "aarch64-...-objdump -lSD u-boot | less" on 
the U-Boot which matches the one which generated the trace, and then 
look up the lr/elr address in that trace. That should point you to the 
exact place in code where the exception occurred .