From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 85F6FC433F5 for ; Thu, 28 Apr 2022 04:53:11 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 751C883D77; Thu, 28 Apr 2022 06:53:09 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="VG+sp4p4"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DF8B983DA3; Thu, 28 Apr 2022 06:53:07 +0200 (CEST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 998498343B for ; Thu, 28 Apr 2022 06:53:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pl1-x62f.google.com with SMTP id d15so3351427plh.2 for ; Wed, 27 Apr 2022 21:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=AcLVymFuPqmXeUqjgH2mf144mitp8Pwo5Va1elPt1vc=; b=VG+sp4p4j75TZms0m5sNjYjHlcLUHrqrlopsXLS01mCZdmZ7305ay/6CViSSXiV+Cs j3Zb73qx+TRQc6jkGsomKTo87vUx/3QPcCIT5jaDmdWQ8UCa0k+O8oIF7GBTdEhzT26k q7YhpSlFQuCP4AulSPFXt8edOI8l0r76OvFvJEhO9nzpWB0ZPrhJKXGaykqQz+bv20Ox NAWmjNkkbwgsZHa3dBm6LEQBJzwkP/5WbZ1KbW9GlJLMYifDr4UdI0GPq+1gufFNlLRG 8C0RPEixp3B/vjOQDPHY3yf6hqQDfsghZmAoa8XNNyyHMQY3MaObvl9MpXV/tYRrAqme wJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=AcLVymFuPqmXeUqjgH2mf144mitp8Pwo5Va1elPt1vc=; b=yg0vd3NfcI71TkIP8taMZcvhun+kJKb0RRHAN5a7QdnCZ7PoHf+cTFrsQTHsOXhWmS saV1DOWlMkt7amlklzojmsM359QvZtYPYIwUcWU08l/CQPCgJYvAZqT02e2DuAfab9Cg /qnPKCbbaDK/YJG11JT5OkdQ1bMv2Hjikr92wq/ZW9wxjNH/prZUIpBbLMioGiOVbUHt 2Nl4OcVX7Fkkfm0aNT/ZadSxsn4vZPqeYTOFn05a1nTs3W/nqLhLHv+KZv0zs+R8F7Hy PP8DHD40hPVZ7+ZgqquCN4VmV+OisgiNhUuue8HLnjb26IpwiaetSQSLYhfPQHbApOvQ vg2A== X-Gm-Message-State: AOAM531yUlrvslheQCmuDEElKoMOJ3mvXhB8uyC1o0txoPRPGK81RpGa b/tE/+xpLLIfAIJvhky8eLxxKQ== X-Google-Smtp-Source: ABdhPJw/8Jgl5W99g6mnsMlilxG8VWIaa3G4kvqmEhYAQMDdmwGYJjMNcw568hWdGKaFt21K3Pkeqw== X-Received: by 2002:a17:902:b189:b0:14d:6f87:7c25 with SMTP id s9-20020a170902b18900b0014d6f877c25mr32258700plr.31.1651121581913; Wed, 27 Apr 2022 21:53:01 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:d8b3:f603:ee7d:d13]) by smtp.gmail.com with ESMTPSA id s13-20020a17090a760d00b001cd4989ff70sm4702001pjk.55.2022.04.27.21.52.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 21:53:01 -0700 (PDT) Date: Thu, 28 Apr 2022 13:52:56 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt , masami.hiramatsu@linaro.org, u-boot@lists.denx.de, sjg@chromium.org, ilias.apalodimas@linaro.org, Tom Rini Subject: Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model Message-ID: <20220428045256.GA52309@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , masami.hiramatsu@linaro.org, u-boot@lists.denx.de, sjg@chromium.org, ilias.apalodimas@linaro.org, Tom Rini References: <20220419010517.47175-1-takahiro.akashi@linaro.org> <20220425234421.GA35191@laputa> <4e897c5c-1c49-70ed-2668-40e8d932d5ea@gmx.de> <20220426144418.GA62529@laputa> <3e6309ed-7899-aa91-b0fb-a46ea3fa4743@gmx.de> <20220427032609.GA34649@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220427032609.GA34649@laputa> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Wed, Apr 27, 2022 at 12:26:09PM +0900, AKASHI Takahiro wrote: > Heinrich, > > On Tue, Apr 26, 2022 at 07:02:46PM +0200, Heinrich Schuchardt wrote: > > On 4/26/22 16:44, AKASHI Takahiro wrote: > > > On Tue, Apr 26, 2022 at 03:57:26PM +0200, Heinrich Schuchardt wrote: > > >> On 4/26/22 01:44, AKASHI Takahiro wrote: > > >> I expect that boards that booted with previous versions of U-Boot using > > >> the respective defconfig still boot. But they don't. Here is one example > > >> (orangepi_pc_defconfig): > > >> > > >> Found U-Boot script /boot.scr.uimg > > >> 189 bytes read in 2 ms (91.8 KiB/s) > > >> ## Executing script at 43100000 > > >> 22979 bytes read in 8 ms (2.7 MiB/s) > > >> 98304 bytes read in 8 ms (11.7 MiB/s) > > >> Booting /EFI\debian\grubarm.efi > > >> Welcome to GRUB! > > >> > > >> error: disk `,msdos2' not found. > > >> grub rescue> > > >> > > >> In U-Boot v2022.04 function efi_disk_register() ensured that all block > > >> devices and their partitions were added as EFI handles. > > > Not the all block devices, but the block devices which have already > > > enumerated when efi_init_obj_list() is called. > > > > > >> But that > > >> function is missing now. > > > What (boot) device are you using here? > > > > > > Please show me the values of env variables, particularly, "boot_targets". > > > > > > Please show me the content of boot.scr.uimg, too. > > > > > > Please show me the output from > > > => dm tree > > > => efidebug devices > > > for 2022.04 and 2022.07-rc1. > > > > > > -Takahiro Akashi > > > > > > > > > > > > > > > I am booting from mmc. Boot.scr just loads the device-tree from mmc- > > > > mmcblk0 179:0 0 29.8G 0 disk > > ├─mmcblk0p1 179:1 0 1G 0 part /boot/efi > > ├─mmcblk0p2 179:2 0 1G 0 part /boot > > └─mmcblk0p3 179:3 0 27.8G 0 part / > > Okay. > > > > > U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +0000) Allwinner Technology > > ------------------------------------------------------------------ > > > > grub> ls > > (hd0) (hd0,msdos1) (hd1) (hd1,msdos3) (hd1,msdos2) (hd1,msdos1) > > > > hd0 is a USB stick > > hd1 is the SD card > > > > boot.scr > > -------- > > > > # > > # flash-kernel: bootscr.sunxi > > # > > > > # boot script for Allwinner SunXi-based devices > > > > # Mainline u-boot v2014.10 introduces a new default environment and > > # a new common bootcmd handling for all platforms, which is not fully > > # compatible with the old-style environment used by u-boot-sunxi. > > # This script therefore needs to check in which environment it > > # is running and set some variables accordingly. > > > > # On u-boot-sunxi, this script assumes that ${device} and ${partition} > > # are set. > > > > # The new-style environment predefines ${boot_targets}, the old-style > > # environment does not. > > if test -n "${boot_targets}" > > then > > echo "Mainline u-boot / new-style environment detected." > > # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and > > # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}. > > # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01. > > if test -z "${device}"; then setenv device "${devtype}"; fi > > if test -z "${partition}${distro_bootpart}"; then setenv partition > > "${devnum}:${bootpart}"; fi > > if test -z "${partition}"; then setenv partition > > "${devnum}:${distro_bootpart}"; fi > > else > > echo "U-boot-sunxi / old-style environment detected." > > # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and > > # ramdisk_addr_r, so they have to be manually set. Use the values > > # from mainline u-boot v2014.10, except for ramdisk_addr_r, > > # which is set to 0x44300000 to allow for initrds larger than > > # 13MB on u-boot-sunxi. > > setenv kernel_addr_r 0x42000000 > > setenv fdt_addr_r 0x43000000 > > setenv ramdisk_addr_r 0x44300000 > > fi > > > > if test -n "${console}"; then > > setenv bootargs "${bootargs} console=${console}" > > fi > > > > setenv bootargs ${bootargs} quiet > > > > > > if test -z "${image_locations}"; then > > setenv image_locations ${prefix} > > fi > > if test -z "${image_locations}"; then > > setenv image_locations /boot/ / > > fi > > > > if test -z "${fk_kvers}"; then > > setenv fk_kvers '5.16.0-4-armmp-lpae' > > fi > > > > if test -n "${fdtfile}"; then > > setenv fdtpath dtbs/${fk_kvers}/${fdtfile} > > else > > setenv fdtpath dtb-${fk_kvers} > > fi > > > > for pathprefix in ${image_locations} > > do > > if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers} > > then > > load ${device} ${partition} ${kernel_addr_r} > > ${pathprefix}vmlinuz-${fk_kvers} \ > > && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} \ > > && load ${device} ${partition} ${ramdisk_addr_r} > > ${pathprefix}initrd.img-${fk_kvers} \ > > && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." \ > > && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} > > fi > > done > > Nothing special done here. > > > > > U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +0000) Allwinner Technology > > > > => echo $boot_targets > > fel mmc0 usb0 pxe dhcp > > > > => dm tree > > Class Index Probed Driver Name > > ----------------------------------------------------------- > > root 0 [ + ] root_driver root_driver > > video 0 [ ] sunxi_de2 |-- sunxi_de2 > > display 0 [ ] sunxi_dw_hdmi |-- sunxi_dw_hdmi > > simple_bus 0 [ + ] simple_bus |-- soc > > mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000 > > blk 0 [ + ] mmc_blk | | `-- mmc@1c0f000.blk > > phy 0 [ + ] sun4i_usb_phy | |-- phy@1c19400 > > usb 0 [ + ] ehci_generic | |-- usb@1c1a000 > > usb_hub 0 [ + ] usb_hub | | `-- usb_hub > > usb 1 [ + ] ohci_generic | |-- usb@1c1a400 > > usb_hub 1 [ + ] usb_hub | | `-- usb_hub > > usb 2 [ + ] ehci_generic | |-- usb@1c1b000 > > usb_hub 2 [ + ] usb_hub | | `-- usb_hub > > usb 3 [ + ] ohci_generic | |-- usb@1c1b400 > > usb_hub 3 [ + ] usb_hub | | `-- usb_hub > > usb 4 [ + ] ehci_generic | |-- usb@1c1c000 > > usb_hub 4 [ + ] usb_hub | | `-- usb_hub > > usb_mass_s 0 [ + ] usb_mass_storage | | `-- > > usb_mass_storage > > blk 1 [ ] usb_storage_blk | | `-- > > usb_mass_storage.lun0 > > usb 5 [ + ] ohci_generic | |-- usb@1c1c400 > > usb_hub 5 [ + ] usb_hub | | `-- usb_hub > > usb 6 [ + ] ehci_generic | |-- usb@1c1d000 > > usb_hub 6 [ + ] usb_hub | | `-- usb_hub > > usb 7 [ + ] ohci_generic | |-- usb@1c1d400 > > usb_hub 7 [ + ] usb_hub | | `-- usb_hub > > clk 0 [ + ] sun8i_h3_ccu | |-- clock@1c20000 > > reset 0 [ + ] sunxi_reset | | `-- reset > > gpio 0 [ + ] gpio_sunxi | |-- pinctrl@1c20800 > > gpio 1 [ + ] gpio_sunxi | | |-- PA > > gpio 2 [ + ] gpio_sunxi | | |-- PB > > gpio 3 [ + ] gpio_sunxi | | |-- PC > > gpio 4 [ + ] gpio_sunxi | | |-- PD > > gpio 5 [ + ] gpio_sunxi | | |-- PE > > gpio 6 [ + ] gpio_sunxi | | |-- PF > > gpio 7 [ + ] gpio_sunxi | | |-- PG > > gpio 8 [ + ] gpio_sunxi | | |-- PH > > gpio 9 [ + ] gpio_sunxi | | `-- PI > > ethernet 0 [ + ] eth_sun8i_emac | |-- ethernet@1c30000 > > watchdog 0 [ + ] sunxi_wdt | |-- watchdog@1c20ca0 > > sysreset 0 [ ] wdt_reboot | | `-- watchdog@1c20ca0 > > serial 0 [ + ] ns16550_serial | |-- serial@1c28000 > > clk 1 [ + ] clk_sun6i_rtc | |-- rtc@1f00000 > > clk 2 [ ] sun6i_a31_r_ccu | |-- clock@1f01400 > > reset 1 [ ] sunxi_reset | | `-- reset > > i2c 0 [ ] i2c_mvtwsi | |-- i2c@1f02400 > > gpio 10 [ + ] gpio_sunxi | `-- pinctrl@1f02c00 > > gpio 11 [ + ] gpio_sunxi | `-- PL > > clk 3 [ + ] fixed_clock |-- osc24M_clk > > clk 4 [ ] fixed_clock `-- osc32k_clk > > > > > > > > U-Boot 2022.07-rc1 (Apr 26 2022 - 07:00:52 +0000) Allwinner Technology > > > > => echo $boot_targets > > fel mmc0 usb0 pxe dhcp > > > > => dm tree > > Class Index Probed Driver Name > > ----------------------------------------------------------- > > root 0 [ + ] root_driver root_driver > > video 0 [ ] sunxi_de2 |-- sunxi_de2 > > display 0 [ ] sunxi_dw_hdmi |-- sunxi_dw_hdmi > > simple_bus 0 [ + ] simple_bus |-- soc > > mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000 > > blk 0 [ + ] mmc_blk | | |-- mmc@1c0f000.blk > > A block device detected here. > > > partition 0 [ + ] blk_partition | | | |-- > > mmc@1c0f000.blk:1 > > partition 1 [ + ] blk_partition | | | |-- > > mmc@1c0f000.blk:2 > > partition 2 [ + ] blk_partition | | | `-- > > mmc@1c0f000.blk:3 > > Apparently, there are three partition devices, > then we should definitely have corresponding efi_disk objects > as an efi_loader hook is registered against *POST_PROBE* event > (of a *block* device). > > In my patch c822c1a50bd7 ("mmc: call device_probe() after scanning"), > device_probe() has already been installed to mmc_blk_probe(). > > Thinking of those circumstances, the natural guess is a *probe* function > for "mmc@1c0f000.blk" device has never been called in your use case > (even when loading an image from a specific partition, /boot/efi?). > > To confirm this, you may simply try the followings: > => mmc list > ... > => mmc dev 0 (<- the device number from 'mmc list') > => efi devices > > Then you will find three more efi_disk objects now that the parent > block device is *probed*. > > > bootdev 0 [ ] mmc_bootdev | | `-- > > mmc@1c0f000.bootdev > > phy 0 [ + ] sun4i_usb_phy | |-- phy@1c19400 > > usb 0 [ + ] ehci_generic | |-- usb@1c1a000 > > usb_hub 0 [ + ] usb_hub | | `-- usb_hub > > usb 1 [ + ] ohci_generic | |-- usb@1c1a400 > > usb_hub 1 [ + ] usb_hub | | `-- usb_hub > > usb 2 [ + ] ehci_generic | |-- usb@1c1b000 > > usb_hub 2 [ + ] usb_hub | | `-- usb_hub > > usb 3 [ + ] ohci_generic | |-- usb@1c1b400 > > usb_hub 3 [ + ] usb_hub | | `-- usb_hub > > usb 4 [ + ] ehci_generic | |-- usb@1c1c000 > > usb_hub 4 [ + ] usb_hub | | `-- usb_hub > > usb_mass_s 0 [ + ] usb_mass_storage | | `-- > > usb_mass_storage > > blk 1 [ + ] usb_storage_blk | | |-- > > usb_mass_storage.lun0 > > partition 3 [ + ] blk_partition | | | `-- > > usb_mass_storage.lun0:1 > > bootdev 3 [ ] usb_bootdev | | `-- > > usb_mass_storage.lun0.bootdev > > usb 5 [ + ] ohci_generic | |-- usb@1c1c400 > > usb_hub 5 [ + ] usb_hub | | `-- usb_hub > > usb 6 [ + ] ehci_generic | |-- usb@1c1d000 > > usb_hub 6 [ + ] usb_hub | | `-- usb_hub > > usb 7 [ + ] ohci_generic | |-- usb@1c1d400 > > usb_hub 7 [ + ] usb_hub | | `-- usb_hub > > clk 0 [ + ] sun8i_h3_ccu | |-- clock@1c20000 > > reset 0 [ + ] sunxi_reset | | `-- reset > > pinctrl 0 [ + ] sunxi-pinctrl | |-- pinctrl@1c20800 > > gpio 0 [ + ] gpio_sunxi | | |-- pinctrl@1c20800 > > gpio 1 [ + ] gpio_sunxi | | | |-- PA > > gpio 2 [ + ] gpio_sunxi | | | |-- PB > > gpio 3 [ + ] gpio_sunxi | | | |-- PC > > gpio 4 [ + ] gpio_sunxi | | | |-- PD > > gpio 5 [ + ] gpio_sunxi | | | |-- PE > > gpio 6 [ + ] gpio_sunxi | | | |-- PF > > gpio 7 [ + ] gpio_sunxi | | | `-- PG > > pinconfig 0 [ ] pinconfig | | |-- csi-pins > > pinconfig 1 [ ] pinconfig | | |-- emac-rgmii-pins > > pinconfig 2 [ ] pinconfig | | |-- i2c0-pins > > pinconfig 3 [ ] pinconfig | | |-- i2c1-pins > > pinconfig 4 [ ] pinconfig | | |-- i2c2-pins > > pinconfig 5 [ + ] pinconfig | | |-- mmc0-pins > > pinconfig 6 [ ] pinconfig | | |-- mmc1-pins > > pinconfig 7 [ ] pinconfig | | |-- mmc2-8bit-pins > > pinconfig 8 [ ] pinconfig | | |-- spdif-tx-pin > > pinconfig 9 [ ] pinconfig | | |-- spi0-pins > > pinconfig 10 [ ] pinconfig | | |-- spi1-pins > > pinconfig 11 [ + ] pinconfig | | |-- uart0-pa-pins > > pinconfig 12 [ ] pinconfig | | |-- uart1-pins > > pinconfig 13 [ ] pinconfig | | |-- > > uart1-rts-cts-pins > > pinconfig 14 [ ] pinconfig | | |-- uart2-pins > > pinconfig 15 [ ] pinconfig | | |-- > > uart2-rts-cts-pins > > pinconfig 16 [ ] pinconfig | | |-- uart3-pins > > pinconfig 17 [ ] pinconfig | | |-- > > uart3-rts-cts-pins > > pinconfig 18 [ ] pinconfig | | |-- ahci_pwr_pin@0 > > pinconfig 19 [ ] pinconfig | | |-- usb0_vbus_pin@0 > > pinconfig 20 [ ] pinconfig | | |-- usb1_vbus_pin@0 > > pinconfig 21 [ ] pinconfig | | `-- usb2_vbus_pin@0 > > ethernet 0 [ + ] eth_sun8i_emac | |-- ethernet@1c30000 > > bootdev 1 [ ] eth_bootdev | | `-- > > ethernet@1c30000.bootdev > > watchdog 0 [ + ] sunxi_wdt | |-- watchdog@1c20ca0 > > sysreset 0 [ ] wdt_reboot | | `-- watchdog@1c20ca0 > > serial 0 [ + ] ns16550_serial | |-- serial@1c28000 > > clk 1 [ + ] clk_sun6i_rtc | |-- rtc@1f00000 > > clk 2 [ + ] sun6i_a31_r_ccu | |-- clock@1f01400 > > reset 1 [ ] sunxi_reset | | `-- reset > > i2c 0 [ ] i2c_mvtwsi | |-- i2c@1f02400 > > pinctrl 1 [ + ] sunxi-pinctrl | `-- pinctrl@1f02c00 > > gpio 8 [ + ] gpio_sunxi | |-- pinctrl@1f02c00 > > gpio 9 [ + ] gpio_sunxi | | `-- PL > > pinconfig 22 [ ] pinconfig | |-- r-ir-rx-pin > > pinconfig 23 [ ] pinconfig | |-- r-i2c-pins > > pinconfig 24 [ ] pinconfig | `-- r-pwm-pin > > clk 3 [ + ] fixed_clock |-- osc24M_clk > > clk 4 [ ] fixed_clock |-- osc32k_clk > > bootstd 0 [ ] bootstd_drv `-- bootstd > > bootmeth 0 [ ] bootmeth_distro |-- distro > > bootmeth 1 [ ] bootmeth_efi |-- efi > > bootmeth 2 [ ] bootmeth_pxe |-- pxe > > bootdev 2 [ ] system_bootdev `-- system-bootdev > > > > grub rescue> ls > > (hd0) > > > > Grub does not see any partition at all. > > > > Loading a device from a partition does not create a handle for the device: > > Actually, loading an image does *not* invoke a probe function at all > under the current implementation (of either "part" command, > scan_dev_for_boot_part or even mmc drivers?). > > I think that this is weird as the purpose of "probe" is to activate > the device, or "probe - make a device ready for use" according to > doc/develop/driver-model/design.rst > > So my conclusion is that the current implementation has already broken > the driver model even before my patch was applied. > -> Simon, you should have a comment here? > > That said, fixing a problem is a different matter. > Probably, we will have to modify "part" command or mmc drivers themselves. Can you figure out an easy way to reproduce the issue? (either on sandbox or qemu-arm) Otherwise, it is difficult for me to investigate it. -Takahiro Akashi > -Takahiro Akashi > > > => efidebug devices > > ** Unable to read file ubootefi.var ** > > Failed to load EFI variables > > Device Device Path > > ======== ==================== > > 79f80f08 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) > > 7dffc7ec /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D) > > 79f7f1f8 > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0) > > 79f7f2a0 > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0x0c449046,0x800,0x800) > > 79fdc188 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(0281431d5371,1) > > => bootefi $kernel_addr_r > > Booting /helloworld.efi > > invalid image type: 0 > > Hello, world! > > => efidebug devices > > Device Device Path > > ======== ==================== > > 79f80f08 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b) > > 7dffc7ec /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D) > > 79f7f1f8 > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0) > > 79f7f2a0 > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0x0c449046,0x800,0x800) > > 79fdc188 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(0281431d5371,1) > > => > > > > So the current state is a complete mess. > > > > Best regards > > > > Heinrich