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