bug - bootflow: grub efi crashes when bootflow selected explicitly
Shantur Rathore
i at shantur.com
Wed Nov 15 15:50:05 CET 2023
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
More information about the U-Boot
mailing list