On 2024-11-14 22:08, Heinrich Schuchardt wrote: > Jonas Karlman <jo...@kwiboo.se> schrieb am Do., 14. Nov. 2024, 21:26: > >> Hi Heinrich, >> >> On 2024-11-13 20:55, Heinrich Schuchardt wrote: >>> Some hard devices need specific routines to scan for block devices, >>> e.g. NVMe (nvme scan), SCSI (scsi start). >>> >>> Invoke bootdev_hunt() to find all block devices. >>> >>> Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com> >>> --- >>> lib/efi_loader/efi_setup.c | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c >>> index aa59bc7779d..8e0ff16f3eb 100644 >>> --- a/lib/efi_loader/efi_setup.c >>> +++ b/lib/efi_loader/efi_setup.c >>> @@ -7,6 +7,7 @@ >>> >>> #define LOG_CATEGORY LOGC_EFI >>> >>> +#include <bootdev.h> >>> #include <efi_loader.h> >>> #include <efi_variable.h> >>> #include <log.h> >>> @@ -228,6 +229,13 @@ efi_status_t efi_init_obj_list(void) >>> * Probe block devices to find the ESP. >>> * efi_disks_register() must be called before efi_init_variables(). >>> */ >>> + if (CONFIG_IS_ENABLED(BOOTSTD)) { >>> + int r; >>> + >>> + r = bootdev_hunt(NULL, 0); >>> + if (r) >>> + log_debug("No boot device available\n"); >>> + } >>> ret = efi_disks_register(); >>> if (ret != EFI_SUCCESS) >>> goto out; >> >> This is causing significant slower boot when trying to boot using >> extlinux (or script) from mmc device on Rockchip, this will cause all >> slow devices to be initialized before a quick mmc boot, e.g. pci init, >> usb start and dhcp due to efi_mgr being the global bootmeth. >> > > Specifically DHCP is very slow and not needed here.
It is not just DHCP, each PCIe Link Fail add minimum one second timeout, and USB init also adds 5-10 seconds. So instead of 2-3 seconds until "Starting kernel ..." it takes around 30+ seconds with this. Without efi_mgr boot is quick: Net: eth1: ethernet@fe010000, eth0: ethernet@fe2a0000 Hit any key to stop autoboot: 0 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning bootdev 'mmc@fe2b0000.bootdev': 0 extlinux ready mmc 1 m...@fe2b0000.bootdev.part /extlinux/extlinux.conf ** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with extlinux 1: linux Retrieving file: /Image.gz Retrieving file: /initramfs.cpio.gz Uncompressing Kernel Image to 0 ## Flattened Device Tree blob at eded7d90 Booting using the fdt blob at 0xeded7d90 Working FDT set to eded7d90 Loading Ramdisk to ecb3b000, end ececfd3c ... OK Loading Device Tree to 00000000ecb23000, end 00000000ecb3afdf ... OK Working FDT set to ecb23000 Starting kernel ... > > Maybe Simon has an idea how to filter it out. We should filter on > UCLASS_BLK related here. > > Furthermore I don't know if global bootmeths are always have to run first > or if you could customize this. The commit c627cfc14c08 ("bootstd: Allow scanning for global bootmeths separately") changed to always prefer global bootmeths even if the ordering is different, see default order below. => bootmeth list Order Seq Name Description ----- --- ------------------ ------------------ 0 0 extlinux Extlinux boot from a block device 1 1 script Script boot from a block device glob 2 efi_mgr EFI bootmgr flow 3 3 efi EFI boot from an .efi file 4 4 pxe PXE boot from a network device glob 5 vbe_simple VBE simple ----- --- ------------------ ------------------ (6 bootmeths) The only way to not have efi_mgr as first option is with a custom bootmeths env var where it is excluded or fully disable EFI_BOOTMGR. This patch bring other existing issues to surface, e.g.: - BOOTP broadcast is send even when 2x Ethernet PHY auto negotiation timeout (no cable connected). - PCI controller is probed multiple times, and with a failed probe (Link Fail) it gets re-probed multiple times adding multiple timeouts for each pci controller, maybe not failing probe at Link Fail could mitigate part of the repeated pci controller probe. On this device, ROCK 3B, there is 2x Ethernet and 2x PCIe controllers that help add to the added boot delay with this patch. Regards, Jonas > > Best regards > > Heinrich > > > >> With this patch applied: >> >> U-Boot 2025.01-rc2 (Nov 14 2024 - 20:09:17 +0000) >> >> Model: Radxa ROCK 3B >> SoC: RK3568J >> DRAM: 8 GiB (effective 7.7 GiB) >> PMIC: RK809 (on=0x40, off=0x00) >> Core: 341 devices, 33 uclasses, devicetree: separate >> MMC: mmc@fe000000: 2, mmc@fe2b0000: 1, mmc@fe310000: 0 >> Loading Environment from nowhere... OK >> In: serial@fe660000 >> Out: serial@fe660000 >> Err: serial@fe660000 >> Net: eth1: ethernet@fe010000, eth0: ethernet@fe2a0000 >> Hit any key to stop autoboot: 0 >> Scanning for bootflows in all bootdevs >> Seq Method State Uclass Part Name >> Filename >> --- ----------- ------ -------- ---- ------------------------ >> ---------------- >> Scanning global bootmeth 'efi_mgr': >> pcie_dw_rockchip pcie@fe260000: PCIe-0 Link Fail >> pcie_dw_rockchip pcie@fe280000: PCIe-1 Link Fail >> ethernet@fe2a0000 Waiting for PHY auto negotiation to complete......... >> TIMEOUT ! >> phy_startup() failed: -110 >> FAILED: -110 >> ethernet@fe010000 Waiting for PHY auto negotiation to complete......... >> TIMEOUT ! >> phy_startup() failed: -110 >> FAILED: -110 >> BOOTP broadcast 1 >> BOOTP broadcast 2 >> BOOTP broadcast 3 >> BOOTP broadcast 4 >> BOOTP broadcast 5 >> BOOTP broadcast 6 >> BOOTP broadcast 7 >> BOOTP broadcast 8 >> BOOTP broadcast 9 >> BOOTP broadcast 10 >> BOOTP broadcast 11 >> BOOTP broadcast 12 >> BOOTP broadcast 13 >> BOOTP broadcast 14 >> BOOTP broadcast 15 >> BOOTP broadcast 16 >> BOOTP broadcast 17 >> >> Retry time exceeded; starting again >> pcie_dw_rockchip pcie@fe260000: PCIe-0 Link Fail >> pcie_dw_rockchip pcie@fe280000: PCIe-1 Link Fail >> pcie_dw_rockchip pcie@fe260000: PCIe-0 Link Fail >> pcie_dw_rockchip pcie@fe280000: PCIe-1 Link Fail >> scanning bus for devices... >> Bus usb@fd000000: Register 2000140 NbrPorts 2 >> Starting the controller >> USB XHCI 1.10 >> Bus usb@fd800000: USB EHCI 1.00 >> scanning bus usb@fd000000 for devices... 1 USB Device(s) found >> scanning bus usb@fd800000 for devices... 2 USB Device(s) found >> No boot device available >> Card did not respond to voltage select! : -110 >> Cannot persist EFI variables without system partition >> 0 efi_mgr ready (none) 0 <NULL> >> ** Booting bootflow '<NULL>' with efi_mgr >> Loading Boot0000 'mmc 1' failed >> Loading Boot0001 'mmc 0' failed >> EFI boot manager: Cannot load any image >> Boot failed (err=-14) >> Scanning bootdev 'mmc@fe2b0000.bootdev': >> 1 extlinux ready mmc 1 m...@fe2b0000.bootdev.part >> /extlinux/extlinux.conf >> ** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with extlinux >> 1: linux >> Retrieving file: /Image.gz >> Retrieving file: /initramfs.cpio.gz >> Uncompressing Kernel Image to 0 >> ## Flattened Device Tree blob at eded3690 >> Booting using the fdt blob at 0xeded3690 >> Working FDT set to eded3690 >> Loading Ramdisk to ecb0d000, end ecea1d3c ... OK >> Loading Device Tree to 00000000ecaf5000, end 00000000ecb0c6d7 ... OK >> Working FDT set to ecaf5000 >> >> Starting kernel ... >> >> I guess we can always disable efi_mgr on Rockchip, similar to sunxi, to >> restore pre stdboot behavior. >> >> Regards, >> Jonas >> >> >