bug - bootflow: grub efi crashes when bootflow selected explicitly
Hi all,
I am facing an issue with bootflow where grub efi crashes only when bootflow is selected manually.
Board - RockPro64 OS - Armbian Bookworm CLI U-boot : 2024.01-rc2 Built and installed in SPI Boot Device = USB drive connected to USB 2.0 port
Success scenario :
=> setenv boot_targets usb => setenv bootmeths efi => bootflow scan -lb
Grub loads and Linux boots Full Log - https://pastebin.com/KUFtUcha
Failure scenario Full Log : https://pastebin.com/GHyG2NDz
setenv boot_targets usb
=> setenv bootmeths efi => bootflow scan => bootflow list Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo efi/boot/bootaa64.efi --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid) => bootflow select 0 => bootflow boot ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi
Loading Linux 6.1.50-current-rockchip64 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... "Synchronous Abort" handler, esr 0x96000044, far 0x300905a65 elr: 000000000022d634 lr : 0000000000208e14 (reloc) elr: 00000000f3f47634 lr : 00000000f3f22e14 x0 : 0000000300905a4d x1 : 0000000000000000 x2 : 0000000000000000 x3 : 000000000207fff0 x4 : 00000000f3fd6470 x5 : 000000000207fff0 x6 : 0000ffff00000004 x7 : 00000000f1f9fad0 x8 : 7f7f7f7f7f7f7f7f x9 : 000000000000d02c x10: 00000000f1efee8c x11: 000000000000d020 x12: 00000000f1efef88 x13: 00000000ad400000 x14: 00000000f1efef2c x15: 00000000f1eff057 x16: 00000000f3f21fc0 x17: 00000000d017a1d0 x18: 00000000f1f11d70 x19: 00000000f1f21eb0 x20: 0000000000000000 x21: 00000000f1f27b80 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 00000000f3fc9ed7 x26: 00000000b0c36000 x27: 00000000f02cd000 x28: 00000000f03a210c x29: 00000000f1efee20
Code: f9400860 eb06001f 540004e0 f9400c66 (f9000c06) UEFI image [0x00000000f0da4000:0x00000000f0dbbfff] '/efi\boot\fbaa64.efi' UEFI image [0x00000000f0386000:0x00000000f07adfff] '/\EFI\debian\grubaa64.efi' UEFI image [0x00000000af4e0000:0x00000000b11dffff] Resetting CPU ...
resetting ...
I am unable to figure out what is the difference between the 2 ways of booting.
Thanks for your help.
Regards, Shantur
+Heinrich Schuchardt
Hi Shantur,
On Wed, 15 Nov 2023 at 05:59, Shantur Rathore i@shantur.com wrote:
Hi all,
I am facing an issue with bootflow where grub efi crashes only when bootflow is selected manually.
Board - RockPro64 OS - Armbian Bookworm CLI U-boot : 2024.01-rc2 Built and installed in SPI Boot Device = USB drive connected to USB 2.0 port
Success scenario :
=> setenv boot_targets usb => setenv bootmeths efi => bootflow scan -lb
Grub loads and Linux boots Full Log - https://pastebin.com/KUFtUcha
Failure scenario Full Log : https://pastebin.com/GHyG2NDz
setenv boot_targets usb
=> setenv bootmeths efi => bootflow scan => bootflow list Showing all bootflows Seq Method State Uclass Part Name Filename
0 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo efi/boot/bootaa64.efi
(1 bootflow, 1 valid) => bootflow select 0 => bootflow boot ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi
Loading Linux 6.1.50-current-rockchip64 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... "Synchronous Abort" handler, esr 0x96000044, far 0x300905a65 elr: 000000000022d634 lr : 0000000000208e14 (reloc) elr: 00000000f3f47634 lr : 00000000f3f22e14 x0 : 0000000300905a4d x1 : 0000000000000000 x2 : 0000000000000000 x3 : 000000000207fff0 x4 : 00000000f3fd6470 x5 : 000000000207fff0 x6 : 0000ffff00000004 x7 : 00000000f1f9fad0 x8 : 7f7f7f7f7f7f7f7f x9 : 000000000000d02c x10: 00000000f1efee8c x11: 000000000000d020 x12: 00000000f1efef88 x13: 00000000ad400000 x14: 00000000f1efef2c x15: 00000000f1eff057 x16: 00000000f3f21fc0 x17: 00000000d017a1d0 x18: 00000000f1f11d70 x19: 00000000f1f21eb0 x20: 0000000000000000 x21: 00000000f1f27b80 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 00000000f3fc9ed7 x26: 00000000b0c36000 x27: 00000000f02cd000 x28: 00000000f03a210c x29: 00000000f1efee20
Code: f9400860 eb06001f 540004e0 f9400c66 (f9000c06) UEFI image [0x00000000f0da4000:0x00000000f0dbbfff] '/efi\boot\fbaa64.efi' UEFI image [0x00000000f0386000:0x00000000f07adfff] '/\EFI\debian\grubaa64.efi' UEFI image [0x00000000af4e0000:0x00000000b11dffff] Resetting CPU ...
resetting ...
I am unable to figure out what is the difference between the 2 ways of booting.
Thanks for your help.
Thank you for the detailed report. Can you try series [1] in particular patch [2]
It has been sitting around for quite a while, unfortunately.
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=381851 [2] https://patchwork.ozlabs.org/project/uboot/patch/20231112130245.v4.5.If20602...
HI Simon,
Thanks for the speedy reply. I can confirm patch [2] fixes the problem - at least on the USB2.0 port on RockPro64. I see some issue with the USB disk being unable to provide its size on the USB3.0 port but that might not be linked to bootflow.
PS - Also tested with https://patchwork.ozlabs.org/project/uboot/list/?series=382070
Regards, Shantur
On Wed, Nov 15, 2023 at 1:12 PM Simon Glass sjg@chromium.org wrote:
+Heinrich Schuchardt
Hi Shantur,
On Wed, 15 Nov 2023 at 05:59, Shantur Rathore i@shantur.com wrote:
Hi all,
I am facing an issue with bootflow where grub efi crashes only when bootflow is selected manually.
Board - RockPro64 OS - Armbian Bookworm CLI U-boot : 2024.01-rc2 Built and installed in SPI Boot Device = USB drive connected to USB 2.0 port
Success scenario :
=> setenv boot_targets usb => setenv bootmeths efi => bootflow scan -lb
Grub loads and Linux boots Full Log - https://pastebin.com/KUFtUcha
Failure scenario Full Log : https://pastebin.com/GHyG2NDz
setenv boot_targets usb
=> setenv bootmeths efi => bootflow scan => bootflow list Showing all bootflows Seq Method State Uclass Part Name Filename
0 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo efi/boot/bootaa64.efi
(1 bootflow, 1 valid) => bootflow select 0 => bootflow boot ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi
Loading Linux 6.1.50-current-rockchip64 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... "Synchronous Abort" handler, esr 0x96000044, far 0x300905a65 elr: 000000000022d634 lr : 0000000000208e14 (reloc) elr: 00000000f3f47634 lr : 00000000f3f22e14 x0 : 0000000300905a4d x1 : 0000000000000000 x2 : 0000000000000000 x3 : 000000000207fff0 x4 : 00000000f3fd6470 x5 : 000000000207fff0 x6 : 0000ffff00000004 x7 : 00000000f1f9fad0 x8 : 7f7f7f7f7f7f7f7f x9 : 000000000000d02c x10: 00000000f1efee8c x11: 000000000000d020 x12: 00000000f1efef88 x13: 00000000ad400000 x14: 00000000f1efef2c x15: 00000000f1eff057 x16: 00000000f3f21fc0 x17: 00000000d017a1d0 x18: 00000000f1f11d70 x19: 00000000f1f21eb0 x20: 0000000000000000 x21: 00000000f1f27b80 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 00000000f3fc9ed7 x26: 00000000b0c36000 x27: 00000000f02cd000 x28: 00000000f03a210c x29: 00000000f1efee20
Code: f9400860 eb06001f 540004e0 f9400c66 (f9000c06) UEFI image [0x00000000f0da4000:0x00000000f0dbbfff] '/efi\boot\fbaa64.efi' UEFI image [0x00000000f0386000:0x00000000f07adfff] '/\EFI\debian\grubaa64.efi' UEFI image [0x00000000af4e0000:0x00000000b11dffff] Resetting CPU ...
resetting ...
I am unable to figure out what is the difference between the 2 ways of booting.
Thanks for your help.
Thank you for the detailed report. Can you try series [1] in particular patch [2]
It has been sitting around for quite a while, unfortunately.
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=381851 [2] https://patchwork.ozlabs.org/project/uboot/patch/20231112130245.v4.5.If20602...
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
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
Hi Simon,
Is this the blue port on top of the USB-C connector?
Yes, that's correct. For my drive I needed - https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
Which version of Armbian / download link?
https://redirect.armbian.com/rockpro64/Bookworm_current
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Sorry, I meant to ask if anything specific to USB. I see it loads efi from the network or disk and calls bootefi with the loaded address. I don't know deep boot / efi stuff, just trying to compare how it's loading efi differently than fatload in this case.
Kind regards, Shantur
Hi Shantur,
On Wed, 15 Nov 2023 at 08:23, Shantur Rathore i@shantur.com wrote:
Hi Simon,
Is this the blue port on top of the USB-C connector?
Yes, that's correct. For my drive I needed - https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
Which version of Armbian / download link?
https://redirect.armbian.com/rockpro64/Bookworm_current
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Sorry, I meant to ask if anything specific to USB. I see it loads efi from the network or disk and calls bootefi with the loaded address. I don't know deep boot / efi stuff, just trying to compare how it's loading efi differently than fatload in this case.
There is nothing special about USB in boootstd, so far as I know.
But until we figure out this bug, it is hard to be sure.
Regards, Simon
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
As I understand it, - Just before starting kernel EFI binary calls usb-uclass->usb_stop() - This starts removing all devices in my case ( 6x usb_hub, 2x partition, 1x blk, 2x bootdev, 1x usb_maas_storage) - While removing bootdev, it ends up calling bootdev-uclass -> bootdev_pre_unbind -> bootdev_clear_bootflows which calls bootflow->bootflow_remove and bootflow_free
I don't know why this buf cannot be freed, is it because the EFI binary in the buffer is still being used ( efi/boot/bootaa64.efi ) ? But commenting this line out fixes the crash and linux boots happily.
Fixing this properly is above my pay grade as of now.
Kind regards, Shantur
On Wed, Nov 15, 2023 at 3:58 PM Simon Glass sjg@chromium.org wrote:
Hi Shantur,
On Wed, 15 Nov 2023 at 08:23, Shantur Rathore i@shantur.com wrote:
Hi Simon,
Is this the blue port on top of the USB-C connector?
Yes, that's correct. For my drive I needed - https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
Which version of Armbian / download link?
https://redirect.armbian.com/rockpro64/Bookworm_current
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Sorry, I meant to ask if anything specific to USB. I see it loads efi from the network or disk and calls bootefi with the loaded address. I don't know deep boot / efi stuff, just trying to compare how it's loading efi differently than fatload in this case.
There is nothing special about USB in boootstd, so far as I know.
But until we figure out this bug, it is hard to be sure.
Regards, Simon
Hi Shantur,
On Wed, 15 Nov 2023 at 15:13, Shantur Rathore i@shantur.com wrote:
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
As I understand it,
- Just before starting kernel EFI binary calls usb-uclass->usb_stop()
- This starts removing all devices in my case ( 6x usb_hub, 2x
partition, 1x blk, 2x bootdev, 1x usb_maas_storage)
- While removing bootdev, it ends up calling bootdev-uclass ->
bootdev_pre_unbind -> bootdev_clear_bootflows which calls bootflow->bootflow_remove and bootflow_free
I don't know why this buf cannot be freed, is it because the EFI binary in the buffer is still being used ( efi/boot/bootaa64.efi ) ? But commenting this line out fixes the crash and linux boots happily.
Fixing this properly is above my pay grade as of now.
Great, thank you! I will send a patch.
Regards, Simon
Kind regards, Shantur
On Wed, Nov 15, 2023 at 3:58 PM Simon Glass sjg@chromium.org wrote:
Hi Shantur,
On Wed, 15 Nov 2023 at 08:23, Shantur Rathore i@shantur.com wrote:
Hi Simon,
Is this the blue port on top of the USB-C connector?
Yes, that's correct. For my drive I needed - https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
Which version of Armbian / download link?
https://redirect.armbian.com/rockpro64/Bookworm_current
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Sorry, I meant to ask if anything specific to USB. I see it loads efi from the network or disk and calls bootefi with the loaded address. I don't know deep boot / efi stuff, just trying to compare how it's loading efi differently than fatload in this case.
There is nothing special about USB in boootstd, so far as I know.
But until we figure out this bug, it is hard to be sure.
Regards, Simon
Am 15. November 2023 23:15:46 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Shantur,
On Wed, 15 Nov 2023 at 15:13, Shantur Rathore i@shantur.com wrote:
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
As I understand it,
- Just before starting kernel EFI binary calls usb-uclass->usb_stop()
- This starts removing all devices in my case ( 6x usb_hub, 2x
partition, 1x blk, 2x bootdev, 1x usb_maas_storage)
- While removing bootdev, it ends up calling bootdev-uclass ->
bootdev_pre_unbind -> bootdev_clear_bootflows which calls bootflow->bootflow_remove and bootflow_free
I don't know why this buf cannot be freed, is it because the EFI binary in the buffer is still being used ( efi/boot/bootaa64.efi ) ?
EFI binaries should never be started from memory allocated with malloc. efi_load_image() should be invoked which allocates EFI memory via efi_allocate_pages(). The handle created has to be passed to efi_start_image().
But commenting this line out fixes the crash and linux boots happily.
Fixing this properly is above my pay grade as of now.
Great, thank you! I will send a patch.
Free() typically crashes in U-Boot when freeing the same memory twice.
Best regards
Heinrich
Regards, Simon
Kind regards, Shantur
On Wed, Nov 15, 2023 at 3:58 PM Simon Glass sjg@chromium.org wrote:
Hi Shantur,
On Wed, 15 Nov 2023 at 08:23, Shantur Rathore i@shantur.com wrote:
Hi Simon,
Is this the blue port on top of the USB-C connector?
Yes, that's correct. For my drive I needed - https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
Which version of Armbian / download link?
https://redirect.armbian.com/rockpro64/Bookworm_current
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Sorry, I meant to ask if anything specific to USB. I see it loads efi from the network or disk and calls bootefi with the loaded address. I don't know deep boot / efi stuff, just trying to compare how it's loading efi differently than fatload in this case.
There is nothing special about USB in boootstd, so far as I know.
But until we figure out this bug, it is hard to be sure.
Regards, Simon
On 11/15/23 23:46, Heinrich Schuchardt wrote:
Am 15. November 2023 23:15:46 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Shantur,
On Wed, 15 Nov 2023 at 15:13, Shantur Rathore i@shantur.com wrote:
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
Unfortunately the description of the field bflow->buf is deceptively wrong:
@buf: Bootflow file contents (allocated)
The EFI bootflow never allocates this buffer but uses the address $kernel_addr_r without allocation.
We must not call free on an address that we never allocated via malloc().
Doesn't this also explain the error you experienced before writing
[PATCH v4 05/12] usb: Avoid unbinding devices in use by bootflows https://lore.kernel.org/u-boot/CAHc5_t3v23k_Xbws5o-g9iQfoQ7fhpKScf89XDaaAgo+...
Best regards
Heinrich
As I understand it,
- Just before starting kernel EFI binary calls usb-uclass->usb_stop()
- This starts removing all devices in my case ( 6x usb_hub, 2x
partition, 1x blk, 2x bootdev, 1x usb_maas_storage)
- While removing bootdev, it ends up calling bootdev-uclass ->
bootdev_pre_unbind -> bootdev_clear_bootflows which calls bootflow->bootflow_remove and bootflow_free
I don't know why this buf cannot be freed, is it because the EFI binary in the buffer is still being used ( efi/boot/bootaa64.efi ) ?
EFI binaries should never be started from memory allocated with malloc. efi_load_image() should be invoked which allocates EFI memory via efi_allocate_pages(). The handle created has to be passed to efi_start_image().
But commenting this line out fixes the crash and linux boots happily.
Fixing this properly is above my pay grade as of now.
Great, thank you! I will send a patch.
Free() typically crashes in U-Boot when freeing the same memory twice.
Best regards
Heinrich
Regards, Simon
Kind regards, Shantur
On Wed, Nov 15, 2023 at 3:58 PM Simon Glass sjg@chromium.org wrote:
Hi Shantur,
On Wed, 15 Nov 2023 at 08:23, Shantur Rathore i@shantur.com wrote:
Hi Simon,
Is this the blue port on top of the USB-C connector?
Yes, that's correct. For my drive I needed - https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@s...
Which version of Armbian / download link?
https://redirect.armbian.com/rockpro64/Bookworm_current
Yes it is scanning first, before reading the efi app, etc.
I have the same hardware so may be able to dig into this.
Sorry, I meant to ask if anything specific to USB. I see it loads efi from the network or disk and calls bootefi with the loaded address. I don't know deep boot / efi stuff, just trying to compare how it's loading efi differently than fatload in this case.
There is nothing special about USB in boootstd, so far as I know.
But until we figure out this bug, it is hard to be sure.
Regards, Simon
Hi Heinrich,
On Wed, 15 Nov 2023 at 18:25, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/15/23 23:46, Heinrich Schuchardt wrote:
Am 15. November 2023 23:15:46 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Shantur,
On Wed, 15 Nov 2023 at 15:13, Shantur Rathore i@shantur.com wrote:
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
Unfortunately the description of the field bflow->buf is deceptively wrong:
@buf: Bootflow file contents (allocated)
The EFI bootflow never allocates this buffer but uses the address $kernel_addr_r without allocation.
We must not call free on an address that we never allocated via malloc().
Doesn't this also explain the error you experienced before writing
[PATCH v4 05/12] usb: Avoid unbinding devices in use by bootflows https://lore.kernel.org/u-boot/CAHc5_t3v23k_Xbws5o-g9iQfoQ7fhpKScf89XDaaAgo+...
Yes that is indeed the bug report from Shantur. I just sent a patch.
I still would like the USB patch to go in though, as it is wrong to unbind devices before boot. We have a special device_remove() flag for handling this and it should be used with all devices, including USB.
[..]
Regards, Simon
Hi Heinrich,
On Wed, 15 Nov 2023 at 15:47, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 15. November 2023 23:15:46 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Shantur,
On Wed, 15 Nov 2023 at 15:13, Shantur Rathore i@shantur.com wrote:
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
As I understand it,
- Just before starting kernel EFI binary calls usb-uclass->usb_stop()
- This starts removing all devices in my case ( 6x usb_hub, 2x
partition, 1x blk, 2x bootdev, 1x usb_maas_storage)
- While removing bootdev, it ends up calling bootdev-uclass ->
bootdev_pre_unbind -> bootdev_clear_bootflows which calls bootflow->bootflow_remove and bootflow_free
I don't know why this buf cannot be freed, is it because the EFI binary in the buffer is still being used ( efi/boot/bootaa64.efi ) ?
EFI binaries should never be started from memory allocated with malloc. efi_load_image() should be invoked which allocates EFI memory via efi_allocate_pages(). The handle created has to be passed to efi_start_image().
This is a mess at present, as you are probably aware. EFI has hack to look at loaded images and try to patch up its tables.
With bootstd we will be able to do this properly.
But note that memory allocation in U-Boot is done via malloc() and lmb. We don't call efi_allocate_pages() except in the EFI code.
But commenting this line out fixes the crash and linux boots happily.
Fixing this properly is above my pay grade as of now.
Great, thank you! I will send a patch.
Free() typically crashes in U-Boot when freeing the same memory twice.
Indeed. In this case it was not even allocated.
Regards, Simon
On 11/16/23 02:39, Simon Glass wrote:
Hi Heinrich,
On Wed, 15 Nov 2023 at 15:47, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 15. November 2023 23:15:46 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Shantur,
On Wed, 15 Nov 2023 at 15:13, Shantur Rathore i@shantur.com wrote:
Hi Simon,
I have figured out the cause of the crash. It happens here - https://github.com/u-boot/u-boot/blob/master/boot/bootflow.c#L470 while doing - free(bflow->buf)
As I understand it,
- Just before starting kernel EFI binary calls usb-uclass->usb_stop()
- This starts removing all devices in my case ( 6x usb_hub, 2x
partition, 1x blk, 2x bootdev, 1x usb_maas_storage)
- While removing bootdev, it ends up calling bootdev-uclass ->
bootdev_pre_unbind -> bootdev_clear_bootflows which calls bootflow->bootflow_remove and bootflow_free
I don't know why this buf cannot be freed, is it because the EFI binary in the buffer is still being used ( efi/boot/bootaa64.efi ) ?
EFI binaries should never be started from memory allocated with malloc. efi_load_image() should be invoked which allocates EFI memory via efi_allocate_pages(). The handle created has to be passed to efi_start_image().
This is a mess at present, as you are probably aware. EFI has hack to look at loaded images and try to patch up its tables.
The UEFI implementation has to follow the specification.
With bootstd we will be able to do this properly.
But note that memory allocation in U-Boot is done via malloc() and lmb. We don't call efi_allocate_pages() except in the EFI code.
lmb as used today does not keep track of allocations. It creates a memory map on the fly which is discarded after usage.
It would be great to unify lmb and the EFI page based allocation. Next we need to properly allocate memory for loading files and require freeing the memory before loading a second file into the same location.
The memory available in malloc() is much too small (default 4 MiB) to handle large files like kernels. malloc() does not keep track of different memory types that we need in the EFI case.
Best regards
Heinrich
But commenting this line out fixes the crash and linux boots happily.
Fixing this properly is above my pay grade as of now.
Great, thank you! I will send a patch.
Free() typically crashes in U-Boot when freeing the same memory twice.
Indeed. In this case it was not even allocated.
Regards, Simon
Hi Shantur,
On Wed, 15 Nov 2023 at 07:12, Shantur Rathore i@shantur.com wrote:
HI Simon,
Thanks for the speedy reply. I can confirm patch [2] fixes the problem - at least on the USB2.0 port on RockPro64. I see some issue with the USB disk being unable to provide its size on the USB3.0 port but that might not be linked to bootflow.
PS - Also tested with https://patchwork.ozlabs.org/project/uboot/list/?series=382070
OK, good. Can you please reply on the patch(es) with a Tested-by tag?
Regards, SImon
Regards, Shantur
On Wed, Nov 15, 2023 at 1:12 PM Simon Glass sjg@chromium.org wrote:
+Heinrich Schuchardt
Hi Shantur,
On Wed, 15 Nov 2023 at 05:59, Shantur Rathore i@shantur.com wrote:
Hi all,
I am facing an issue with bootflow where grub efi crashes only when bootflow is selected manually.
Board - RockPro64 OS - Armbian Bookworm CLI U-boot : 2024.01-rc2 Built and installed in SPI Boot Device = USB drive connected to USB 2.0 port
Success scenario :
=> setenv boot_targets usb => setenv bootmeths efi => bootflow scan -lb
Grub loads and Linux boots Full Log - https://pastebin.com/KUFtUcha
Failure scenario Full Log : https://pastebin.com/GHyG2NDz
setenv boot_targets usb
=> setenv bootmeths efi => bootflow scan => bootflow list Showing all bootflows Seq Method State Uclass Part Name Filename
0 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo efi/boot/bootaa64.efi
(1 bootflow, 1 valid) => bootflow select 0 => bootflow boot ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi
Loading Linux 6.1.50-current-rockchip64 ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... "Synchronous Abort" handler, esr 0x96000044, far 0x300905a65 elr: 000000000022d634 lr : 0000000000208e14 (reloc) elr: 00000000f3f47634 lr : 00000000f3f22e14 x0 : 0000000300905a4d x1 : 0000000000000000 x2 : 0000000000000000 x3 : 000000000207fff0 x4 : 00000000f3fd6470 x5 : 000000000207fff0 x6 : 0000ffff00000004 x7 : 00000000f1f9fad0 x8 : 7f7f7f7f7f7f7f7f x9 : 000000000000d02c x10: 00000000f1efee8c x11: 000000000000d020 x12: 00000000f1efef88 x13: 00000000ad400000 x14: 00000000f1efef2c x15: 00000000f1eff057 x16: 00000000f3f21fc0 x17: 00000000d017a1d0 x18: 00000000f1f11d70 x19: 00000000f1f21eb0 x20: 0000000000000000 x21: 00000000f1f27b80 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 00000000f3fc9ed7 x26: 00000000b0c36000 x27: 00000000f02cd000 x28: 00000000f03a210c x29: 00000000f1efee20
Code: f9400860 eb06001f 540004e0 f9400c66 (f9000c06) UEFI image [0x00000000f0da4000:0x00000000f0dbbfff] '/efi\boot\fbaa64.efi' UEFI image [0x00000000f0386000:0x00000000f07adfff] '/\EFI\debian\grubaa64.efi' UEFI image [0x00000000af4e0000:0x00000000b11dffff] Resetting CPU ...
resetting ...
I am unable to figure out what is the difference between the 2 ways of booting.
Thanks for your help.
Thank you for the detailed report. Can you try series [1] in particular patch [2]
It has been sitting around for quite a while, unfortunately.
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=381851 [2] https://patchwork.ozlabs.org/project/uboot/patch/20231112130245.v4.5.If20602...
participants (3)
-
Heinrich Schuchardt -
Shantur Rathore -
Simon Glass