Re: u-boot crashes if mass-storage devices are connected via USB-C
On 2023-03-02 22:05:43 +0100, Marek Vasut wrote:
> On 3/2/23 19:51, Janne Grunau wrote:
> > On 2023-03-02 18:33:15 +0100, Marek Vasut wrote:
> > > 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
> > > > > > wrote:
> > > > > > >
> > > > > > > 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@b0228 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 010f 1300
> > > > 04008401)
> > > > | "Synchronous Abort" handler, esr 0x9605
> > > > | elr: 0003934c lr : 0003934c (reloc)
> > > > | elr: 010fcd24034c lr : 010fcd24034c
> > >
> > > 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 .
> >
> > Slightly different binary due to unrelated chnages:
> >
> > | scanning bus usb@70228 for devices... 1 USB Device(s) found
> > | scanning bus usb@b0228 for devices... 1 USB Device(s) found
> > | scanning bus usb@f0228 for devices... 1 USB Device(s) found
> > | scanning bus usb@130228 for devices... 2 USB Device(s) found
> > | scanning bus usb@70228 for devices... 1 USB Device(s) found
> > | scanning bus usb@b0228 for devices... Resetting EP 0...
> > | WARN halted endpoint, queueing URB anyway.
> > | Unexpected XHCI event TRB, skipping... (c92247b0 010f 1300
> > 02008400)
> > | "Synchronous Abort" handler, esr 0x9605
> > | elr: 00039d9c lr : 00039d9c (reloc)
> > | elr: 010fcd240d9c lr : 010fcd240d9c
> > | x0 : x1 : 03e8
> > | x2 : 0040 x3 : 003f
> > | x4 : 010fc9223040 x5 : 010fc921ef90
> > | x6 : 1800 x7 : 300c0300
> > | x8 : 0424 x9 : 0008
> > | x10: ffe8 x11: 0010
> > | x12: 0001 x13: 0001
> > | x14: 010fc91ba320 x15: 0021
> > | x16: 010fcd23addc x17: 0040
> > | x18: 010fc91e7d70 x19: 010fc9223040
> > | x20: 010fc9234b20 x21: 0002
> > | x22: 010fc9233790 x23: 0080
> > | x24: x25: 010fc91b9d00
> > | x26: 010fc91b9d00 x27: 010fc9233790
> > | x28: x29: 010fc91b99b0
> > |
> > | Code: 973c 52800401 aa1303e0 97a2 (b9400c00)
> >
> > objdump -lSD u-boot | grep -C 12 ' 39d9c'
> >
> > | Disassembly of section .text_rest:
> > | ...
> > |39d84: f9400c36ldr x22, [x1, #24]
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:544
> > | xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING);
> > |39d88: d281mov x1, #0x0
> > // #0
> > |39d8c: 973cbl 39a7c
> > | /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:546
> > | event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
> > |39d90: 52800401mov w1, #0x20
> > // #32
> > |39d94: aa1303e0mov x0, x19
> > |39d98: 97a2
Re: u-boot crashes if mass-storage devices are connected via USB-C
On 3/2/23 19:51, Janne Grunau wrote:
On 2023-03-02 18:33:15 +0100, Marek Vasut wrote:
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 wrote:
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@b0228 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 010f 1300 04008401)
| "Synchronous Abort" handler, esr 0x9605
| elr: 0003934c lr : 0003934c (reloc)
| elr: 010fcd24034c lr : 010fcd24034c
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 .
Slightly different binary due to unrelated chnages:
| scanning bus usb@70228 for devices... 1 USB Device(s) found
| scanning bus usb@b0228 for devices... 1 USB Device(s) found
| scanning bus usb@f0228 for devices... 1 USB Device(s) found
| scanning bus usb@130228 for devices... 2 USB Device(s) found
| scanning bus usb@70228 for devices... 1 USB Device(s) found
| scanning bus usb@b0228 for devices... Resetting EP 0...
| WARN halted endpoint, queueing URB anyway.
| Unexpected XHCI event TRB, skipping... (c92247b0 010f 1300 02008400)
| "Synchronous Abort" handler, esr 0x9605
| elr: 00039d9c lr : 00039d9c (reloc)
| elr: 010fcd240d9c lr : 010fcd240d9c
| x0 : x1 : 03e8
| x2 : 0040 x3 : 003f
| x4 : 010fc9223040 x5 : 010fc921ef90
| x6 : 1800 x7 : 300c0300
| x8 : 0424 x9 : 0008
| x10: ffe8 x11: 0010
| x12: 0001 x13: 0001
| x14: 010fc91ba320 x15: 0021
| x16: 010fcd23addc x17: 0040
| x18: 010fc91e7d70 x19: 010fc9223040
| x20: 010fc9234b20 x21: 0002
| x22: 010fc9233790 x23: 0080
| x24: x25: 010fc91b9d00
| x26: 010fc91b9d00 x27: 010fc9233790
| x28: x29: 010fc91b99b0
|
| Code: 973c 52800401 aa1303e0 97a2 (b9400c00)
objdump -lSD u-boot | grep -C 12 ' 39d9c'
| Disassembly of section .text_rest:
| ...
|39d84: f9400c36ldr x22, [x1, #24]
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:544
| xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING);
|39d88: d281mov x1, #0x0// #0
|39d8c: 973cbl 39a7c
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:546
| event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
|39d90: 52800401mov w1, #0x20 // #32
|39d94: aa1303e0mov x0, x19
|39d98: 97a2bl 39c20
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:547
| field = le32_to_cpu(event->trans_event.flags);
|39d9c: b9400c00ldr w0, [x0, #12]
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548
| BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
|39da0: b9494681ldr w1, [x20, #2372]
|39da4: 6b40603fcmp w1, w0, lsr #24
|39da8: 54000180b.eq39dd8 // b.none
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548 (discriminator
1)
|39dac: 9143adrpx3, 61000
|39db0: 913d0863add x3, x3, #0xf42
|39db4: 52804482mov w2, #0x224 //
#548
| /home/jann
Re: u-boot crashes if mass-storage devices are connected via USB-C
On 2023-03-02 18:33:15 +0100, Marek Vasut wrote:
> 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
> > > > wrote:
> > > > >
> > > > > 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@b0228 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 010f 1300
> > 04008401)
> > | "Synchronous Abort" handler, esr 0x9605
> > | elr: 0003934c lr : 0003934c (reloc)
> > | elr: 010fcd24034c lr : 010fcd24034c
>
> 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 .
Slightly different binary due to unrelated chnages:
| scanning bus usb@70228 for devices... 1 USB Device(s) found
| scanning bus usb@b0228 for devices... 1 USB Device(s) found
| scanning bus usb@f0228 for devices... 1 USB Device(s) found
| scanning bus usb@130228 for devices... 2 USB Device(s) found
| scanning bus usb@70228 for devices... 1 USB Device(s) found
| scanning bus usb@b0228 for devices... Resetting EP 0...
| WARN halted endpoint, queueing URB anyway.
| Unexpected XHCI event TRB, skipping... (c92247b0 010f 1300 02008400)
| "Synchronous Abort" handler, esr 0x9605
| elr: 00039d9c lr : 00039d9c (reloc)
| elr: 010fcd240d9c lr : 010fcd240d9c
| x0 : x1 : 03e8
| x2 : 0040 x3 : 003f
| x4 : 010fc9223040 x5 : 010fc921ef90
| x6 : 1800 x7 : 300c0300
| x8 : 0424 x9 : 0008
| x10: ffe8 x11: 0010
| x12: 0001 x13: 0001
| x14: 010fc91ba320 x15: 0021
| x16: 010fcd23addc x17: 0040
| x18: 010fc91e7d70 x19: 010fc9223040
| x20: 010fc9234b20 x21: 0002
| x22: 010fc9233790 x23: 0080
| x24: x25: 010fc91b9d00
| x26: 010fc91b9d00 x27: 010fc9233790
| x28: x29: 010fc91b99b0
|
| Code: 973c 52800401 aa1303e0 97a2 (b9400c00)
objdump -lSD u-boot | grep -C 12 ' 39d9c'
| Disassembly of section .text_rest:
| ...
|39d84: f9400c36ldr x22, [x1, #24]
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:544
| xhci_queue_command(ctrl, 0, udev->slot_id, ep_index, TRB_STOP_RING);
|39d88: d281mov x1, #0x0// #0
|39d8c: 973cbl 39a7c
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:546
| event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
|39d90: 52800401mov w1, #0x20 // #32
|39d94: aa1303e0mov x0, x19
|39d98: 97a2bl 39c20
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:547
| field = le32_to_cpu(event->trans_event.flags);
|39d9c: b9400c00ldr w0, [x0, #12]
| /home/janne/src/asahi/u-boot/drivers/usb/host/xhci-ring.c:548
| BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
|39da0: b9494681ldr w1, [x20, #2372]
|39da4: 6b40603fcmp w1, w0, lsr #24
|39da8: 54000180b.eq39dd8 // b.none
| /home/janne/src/asahi/u-boot
Re: u-boot crashes if mass-storage devices are connected via USB-C
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 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@b0228 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 010f 1300 04008401)
| "Synchronous Abort" handler, esr 0x9605
| elr: 0003934c lr : 0003934c (reloc)
| elr: 010fcd24034c lr : 010fcd24034c
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 .
Re: u-boot crashes if mass-storage devices are connected via USB-C
Sure. Please send some instructions my way on how to proceed. I know there is a u-boot manual, but I don't wanna mess up my mac mini m1 system. So I'd stick with instructions on your end. Ideally, the action is reversible. I always keep complete system backups, though. My current version is asahi-v2022.10-1 as far as I can tell. I'm used to git, so pulling and making would be the slightest issue. All the best and thanks, --- aka zDEFz On 01.03.2023 23:51, 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 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 ?
Re: u-boot crashes if mass-storage devices are connected via USB-C
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 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@b0228 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 010f 1300 04008401)
| "Synchronous Abort" handler, esr 0x9605
| elr: 0003934c lr : 0003934c (reloc)
| elr: 010fcd24034c lr : 010fcd24034c
| x0 : x1 : 03e8
| x2 : 0040 x3 : 003f
| x4 : 010fc92065c0 x5 : 010fc9208210
| x6 : 1800 x7 : 300c0300
| x8 : 0424 x9 : 0004
| x10: ffe8 x11: 0010
| x12: 0001 x13: 0001
| x14: 010fc91c6720 x15: 0021
| x16: 010fcd23a414 x17: 0040
| x18: 010fc91e7d70 x19: 010fc92065c0
| x20: 010fc9443630 x21: 0002
| x22: 010fc94406f0 x23: 0080
| x24: x25: 010fc91c6100
| x26: 010fc91c6100 x27: 010fc94406f0
| x28: x29: 010fc91c5db0
|
| Code: 973c 52800401 aa1303e0 97a2 (b9400c00) Resetting CPU ...
The usb2sata bridges can powered off individually. u-boot crashes with
just a single bridge with HDD powered on. Works if all bridges are off
or don't have a HDD connected.
The bridge reports under linux as
Bus 005 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s
bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA
6Gb/s bridge
best regards
Janne
Re: u-boot crashes if mass-storage devices are connected via USB-C
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 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 ?
Re: u-boot crashes if mass-storage devices are connected via USB-C
+Marek Vasut +Bin Meng +Mark Kettenis +Tom Rini On Wed, 1 Mar 2023 at 08:12, bluetail 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 > > Best regards, > bluetail > -- > aka zDEFz
