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.
Booting the Armbian installation using
=> 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.
Kind regards, Shantur