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+as...@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@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 .