Hi Shantur,
On Wed, 15 Nov 2023 at 07:50, Shantur Rathore <i...@shantur.com> wrote:
>
> Hi Simon,
>
> I did some testing on the USB 3.0 port and it seems like bootflow
> causes something to happen to the USB.
> It seems to be only reproducible on the USB3.0 port.
>
> I am using an AMicro AM8180 NVME to USB adapter on the USB3.0 port
> of RockPro64.
Is this the blue port on top of the USB-C connector?
>
> Booting the Armbian installation using
Which version of Armbian / download link?
>
> => fatload usb 0:1 ${kernel_addr_r} EFI/boot/bootaa64.efi
> 979672 bytes read in 6 ms (155.7 MiB/s)
> => bootefi ${kernel_addr_r}
>
> works 100%, no issues with USB whatsoever.
>
> Booting same with
>
> => setenv boot_targets usb
> => setenv bootmeths efi
> => bootflow scan -lb
> Scanning for bootflows in all bootdevs
> Seq Method State Uclass Part Name Filename
> --- ----------- ------ -------- ---- ------------------------
> ----------------
> Scanning bootdev 'usb_mass_storage.lun0.bootdev':
> 0 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo
> efi/boot/bootaa64.efi
> ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi
>
> And I see issues with USB device not communicating properly like
>
> [ 50.182144] sd 0:0:0:0: [sda] tag#29 uas_eh_abort_handler 0 uas-tag
> 24 inflight: CMD OUT
> [ 50.182957] sd 0:0:0:0: [sda] tag#29 CDB: opcode=0x2a 2a 00 03 4e
> e9 78 00 00 08 00
> [ 55.270116] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
> stop endpoint command
> [ 55.284476] xhci-hcd xhci-hcd.2.auto: xHCI host controller not
> responding, assume dead
> [ 55.285494] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>
> This is 100% reproducible.
>
> Is bootflow doing something different to USB than normal fatload +
> bootefi, I see internally it uses bootefi as well.
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Regards,
Simon
