Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
> Date: Thu, 28 Apr 2022 11:42:19 +0200 > From: Heinrich Schuchardt > > On 4/28/22 11:09, Mark Kettenis wrote: > >> We call efi_disk_init() after the MMC device is probed. Therefore > >> probing of the MCC device does not trigger EVT_DM_POST_PROBE. > >> > >> We have to move the efi_disk_init() call before initr_dm(). > >> > >> [PATCH 1/1] efi_loader: call efi_init_early() earlier > >> https://lists.denx.de/pipermail/u-boot/2022-April/482701.html > >> > >> With the patch GRUB now sees the MMC device but it is still not seeing > >> the partitions: > >> > >> grub rescue> ls > >> (hd0) (hd1) > >> > >> This is strange because devices and protocols look rather normal now: > > Do you have the fix for the raw disk support in your tree? I suspect > > that GRUB needs that to read the partition table. > > > > Do you relate to an existing patch or only to the bug that you reported? There is a patch now: https://patchwork.ozlabs.org/project/uboot/patch/20220428044916.52250-1-takahiro.aka...@linaro.org/ Cheers, Mark
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On 4/28/22 11:09, Mark Kettenis wrote: We call efi_disk_init() after the MMC device is probed. Therefore probing of the MCC device does not trigger EVT_DM_POST_PROBE. We have to move the efi_disk_init() call before initr_dm(). [PATCH 1/1] efi_loader: call efi_init_early() earlier https://lists.denx.de/pipermail/u-boot/2022-April/482701.html With the patch GRUB now sees the MMC device but it is still not seeing the partitions: grub rescue> ls (hd0) (hd1) This is strange because devices and protocols look rather normal now: Do you have the fix for the raw disk support in your tree? I suspect that GRUB needs that to read the partition table. Do you relate to an existing patch or only to the bug that you reported? Best regards Heinrich
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
> Date: Thu, 28 Apr 2022 08:45:51 +0200
> Content-Language: en-US
> From: Heinrich Schuchardt
> Cc: masami.hirama...@linaro.org, u-boot@lists.denx.de, s...@chromium.org,
> ilias.apalodi...@linaro.org, Tom Rini ,
> Mark Kettenis
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 4/28/22 06:52, AKASHI Takahiro wrote:
> > 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 4310
> > 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:00 29.8G 0 disk
> >>> ├─mmcblk0p1 179:101G 0 part /boot/efi
> >>> ├─mmcblk0p2 179:201G 0 part /boot
> >>> └─mmcblk0p3 179:30 27.8G 0 part /
> >>
> >> Okay.
> >>
> >>>
> >>> U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
> >>># 13MB on u-boot-sunxi.
> >>>setenv kernel_addr_r 0x4200
> >>>setenv fdt_addr_r 0x4300
> >>>setenv ramdisk_addr_r 0x4430
> >>> 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
>
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On 4/28/22 06:52, AKASHI Takahiro wrote:
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 4310
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:00 29.8G 0 disk
├─mmcblk0p1 179:101G 0 part /boot/efi
├─mmcblk0p2 179:201G 0 part /boot
└─mmcblk0p3 179:30 27.8G 0 part /
Okay.
U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
# 13MB on u-boot-sunxi.
setenv kernel_addr_r 0x4200
setenv fdt_addr_r 0x4300
setenv ramdisk_addr_r 0x4430
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 +) Allwinner Technology
=> echo $boot_targets
fel mmc0 usb0 pxe dhcp
=> dm tree
Class Index Probed DriverName
---
root 0 [ + ] root_driver root_driver
video 0 [ ] sunxi_de2 |-- sunxi_de2
display 0 [ ] sunxi_dw_hdmi |-- sunxi_dw_hdmi
simple_bus0 [ + ] simple_bus
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
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 4310
> > >> 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:00 29.8G 0 disk
> > ├─mmcblk0p1 179:101G 0 part /boot/efi
> > ├─mmcblk0p2 179:201G 0 part /boot
> > └─mmcblk0p3 179:30 27.8G 0 part /
>
> Okay.
>
> >
> > U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
> > # 13MB on u-boot-sunxi.
> > setenv kernel_addr_r 0x4200
> > setenv fdt_addr_r 0x4300
> > setenv ramdisk_addr_r 0x4430
> > 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}
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
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 4310
> >> 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:00 29.8G 0 disk
> ├─mmcblk0p1 179:101G 0 part /boot/efi
> ├─mmcblk0p2 179:201G 0 part /boot
> └─mmcblk0p3 179:30 27.8G 0 part /
Okay.
>
> U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
> # 13MB on u-boot-sunxi.
> setenv kernel_addr_r 0x4200
> setenv fdt_addr_r 0x4300
> setenv ramdisk_addr_r 0x4430
> 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 +) Allwinner Technology
>
> => echo $boot_targets
> fel mmc0 usb0 pxe dhcp
>
> => dm tree
> Class Index Probed DriverName
> ---
> root
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On Tue, Apr 26, 2022 at 07:18:13PM +0200, Mark Kettenis wrote:
> > Date: Tue, 26 Apr 2022 19:02:46 +0200
> > From: Heinrich Schuchardt
> >
> > 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 4310
> > >> 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:00 29.8G 0 disk
> > ├─mmcblk0p1 179:101G 0 part /boot/efi
> > ├─mmcblk0p2 179:201G 0 part /boot
> > └─mmcblk0p3 179:30 27.8G 0 part /
> >
> >
> > U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
> > # 13MB on u-boot-sunxi.
> > setenv kernel_addr_r 0x4200
> > setenv fdt_addr_r 0x4300
> > setenv ramdisk_addr_r 0x4430
> > 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}
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
> Date: Tue, 26 Apr 2022 19:02:46 +0200
> From: Heinrich Schuchardt
>
> 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 4310
> >> 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:00 29.8G 0 disk
> ├─mmcblk0p1 179:101G 0 part /boot/efi
> ├─mmcblk0p2 179:201G 0 part /boot
> └─mmcblk0p3 179:30 27.8G 0 part /
>
>
> U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
> # 13MB on u-boot-sunxi.
> setenv kernel_addr_r 0x4200
> setenv fdt_addr_r 0x4300
> setenv ramdisk_addr_r 0x4430
> 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
>
>
> U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) Allwinner Technology
>
> => echo $boot_targets
> fel mmc0 usb0 pxe dhcp
>
> => dm tree
> Class Index Probed DriverName
> ---
> root 0 [ + ] root_driver
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
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 4310
>> 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:00 29.8G 0 disk
├─mmcblk0p1 179:101G 0 part /boot/efi
├─mmcblk0p2 179:201G 0 part /boot
└─mmcblk0p3 179:30 27.8G 0 part /
U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) 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 0x4430 to allow for initrds larger than
# 13MB on u-boot-sunxi.
setenv kernel_addr_r 0x4200
setenv fdt_addr_r 0x4300
setenv ramdisk_addr_r 0x4430
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
U-Boot 2022.04 (Apr 26 2022 - 16:02:27 +) Allwinner Technology
=> echo $boot_targets
fel mmc0 usb0 pxe dhcp
=> dm tree
Class Index Probed DriverName
---
root 0 [ + ] root_driver root_driver
video 0 [ ] sunxi_de2 |-- sunxi_de2
display 0 [ ] sunxi_dw_hdmi |-- sunxi_dw_hdmi
simple_bus0 [ + ] simple_bus|-- soc
mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000
blk 0 [ + ] mmc_blk | | `-- m...@1c0f000.blk
phy 0 [ + ]
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On Tue, Apr 26, 2022 at 03:57:26PM +0200, Heinrich Schuchardt wrote: > On 4/26/22 01:44, AKASHI Takahiro wrote: > > On Mon, Apr 25, 2022 at 10:43:44PM +0200, Heinrich Schuchardt wrote: > > > On 4/19/22 03:05, AKASHI Takahiro wrote: > > > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > > > disk objects dynamically at runtime based on block device's probing. > > > > (See "issues" and "prerequisite" below.) > > > > > > > > [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > > > > > > For instance, > > > > => dm tree > > > >Class Index Probed DriverName > > > > --- > > > >root 0 [ + ] root_driver root_driver > > > >... > > > >pci 0 [ + ] pci_generic_ecam |-- pcie@1000 > > > >... > > > >ahci 0 [ ] ahci_pci | |-- ahci_pci > > > >scsi 0 [ ] ahci_scsi | | `-- ahci_scsi > > > >usb 0 [ ] xhci_pci | `-- xhci_pci > > > >... > > > > => efi devices > > > > Missing RNG device for EFI_RNG_PROTOCOL > > > > No EFI system partition > > > > Unable to find TPMv2 device > > > > Device Device Path > > > > > > > > 00013eee88d0 /VenHw(..) > > > > 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) > > > > 00013eeeb810 /VenHw(..)/MAC(525252525252,1) > > > > => scsi rescan > > > > > > > > > With the series binding block devices after initializing the UEFI > > > sub-system works fine. Also unbinding is reflected in the EFI devices. > > > > > > But this series breaks UEFI compliance. > > > > I don't think so. > > > > > All block devices must be probed > > > before booting. > > > > This (not enumerating all the devices) is also true even before my patch. > > > > > Without this GRUB will not be able to read the boot > > > partition with vmlinuz and initrd. > > > > I'm not sure what you expect here, but > > is it enough to define "preboot" variables with any number of > > enumerating commands, like "scsi rescan", "usb start" and so on? > > 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 4310 > 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 > Best regards > > Heinrich > > > > > > # Again, this method can also be applied even without my patch. > > > > -Takahiro Akashi > > > > > Will you provide the missing patch? > > > > > > Best regards > > > > > > Heinrich >
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On 4/26/22 01:44, AKASHI Takahiro wrote: On Mon, Apr 25, 2022 at 10:43:44PM +0200, Heinrich Schuchardt wrote: On 4/19/22 03:05, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" and "prerequisite" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk For instance, => dm tree Class Index Probed DriverName --- root 0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ ] ahci_pci | |-- ahci_pci scsi 0 [ ] ahci_scsi | | `-- ahci_scsi usb 0 [ ] xhci_pci | `-- xhci_pci ... => efi devices Missing RNG device for EFI_RNG_PROTOCOL No EFI system partition Unable to find TPMv2 device Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) => scsi rescan With the series binding block devices after initializing the UEFI sub-system works fine. Also unbinding is reflected in the EFI devices. But this series breaks UEFI compliance. I don't think so. All block devices must be probed before booting. This (not enumerating all the devices) is also true even before my patch. Without this GRUB will not be able to read the boot partition with vmlinuz and initrd. I'm not sure what you expect here, but is it enough to define "preboot" variables with any number of enumerating commands, like "scsi rescan", "usb start" and so on? 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 4310 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. But that function is missing now. Best regards Heinrich # Again, this method can also be applied even without my patch. -Takahiro Akashi Will you provide the missing patch? Best regards Heinrich
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On Mon, Apr 25, 2022 at 10:43:44PM +0200, Heinrich Schuchardt wrote: > On 4/19/22 03:05, AKASHI Takahiro wrote: > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > disk objects dynamically at runtime based on block device's probing. > > (See "issues" and "prerequisite" below.) > > > > [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > > For instance, > > => dm tree > > Class Index Probed DriverName > > --- > > root 0 [ + ] root_driver root_driver > > ... > > pci 0 [ + ] pci_generic_ecam |-- pcie@1000 > > ... > > ahci 0 [ ] ahci_pci | |-- ahci_pci > > scsi 0 [ ] ahci_scsi | | `-- ahci_scsi > > usb 0 [ ] xhci_pci | `-- xhci_pci > > ... > > => efi devices > > Missing RNG device for EFI_RNG_PROTOCOL > > No EFI system partition > > Unable to find TPMv2 device > > Device Device Path > > > > 00013eee88d0 /VenHw(..) > > 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) > > 00013eeeb810 /VenHw(..)/MAC(525252525252,1) > > => scsi rescan > > > With the series binding block devices after initializing the UEFI > sub-system works fine. Also unbinding is reflected in the EFI devices. > > But this series breaks UEFI compliance. I don't think so. > All block devices must be probed > before booting. This (not enumerating all the devices) is also true even before my patch. > Without this GRUB will not be able to read the boot > partition with vmlinuz and initrd. I'm not sure what you expect here, but is it enough to define "preboot" variables with any number of enumerating commands, like "scsi rescan", "usb start" and so on? # Again, this method can also be applied even without my patch. -Takahiro Akashi > Will you provide the missing patch? > > Best regards > > Heinrich
Re: [PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
On 4/19/22 03:05, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" and "prerequisite" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk For instance, => dm tree Class Index Probed DriverName --- root 0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ ] ahci_pci | |-- ahci_pci scsi 0 [ ] ahci_scsi | | `-- ahci_scsi usb 0 [ ] xhci_pci | `-- xhci_pci ... => efi devices Missing RNG device for EFI_RNG_PROTOCOL No EFI system partition Unable to find TPMv2 device Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) => scsi rescan With the series binding block devices after initializing the UEFI sub-system works fine. Also unbinding is reflected in the EFI devices. But this series breaks UEFI compliance. All block devices must be probed before booting. Without this GRUB will not be able to read the boot partition with vmlinuz and initrd. Will you provide the missing patch? Best regards Heinrich
[PATCH v5 00/12] efi_loader: more tightly integrate UEFI disks to driver model
With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" and "prerequisite" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk For instance, => dm tree Class Index Probed DriverName --- root 0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ ] ahci_pci | |-- ahci_pci scsi 0 [ ] ahci_scsi | | `-- ahci_scsi usb 0 [ ] xhci_pci | `-- xhci_pci ... => efi devices Missing RNG device for EFI_RNG_PROTOCOL No EFI system partition Unable to find TPMv2 device Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) => scsi rescan ... => efi devices Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) 00013eefb730 /VenHw(..)/Scsi(0,0) 00013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) => usb start ... => efi devices Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) 00013eefb730 /VenHw(..)/Scsi(0,0) 00013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) 00013ef01330 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0) 00013ef014b0 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013ef018f0 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) => dm tree ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ + ] ahci_pci | |-- ahci_pci scsi 0 [ + ] ahci_scsi | | `-- ahci_scsi blk 2 [ + ] scsi_blk | | `-- ahci_scsi.id0lun0 partition 0 [ + ] blk_partition | | |-- ahci_scsi.id0lun0:1 partition 1 [ + ] blk_partition | | `-- ahci_scsi.id0lun0:2 usb 0 [ + ] xhci_pci | `-- xhci_pci usb_hub 0 [ + ] usb_hub | `-- usb_hub usb_mass_s0 [ + ] usb_mass_storage | |-- usb_mass_storage blk 3 [ + ] usb_storage_blk | | `-- usb_mass_storage.lun0 partition 2 [ + ] blk_partition | | |-- usb_mass_storage.lun0:1 partition 3 [ + ] blk_partition | | `-- usb_mass_storage.lun0:2 ... => usb stop stopping USB.. => efi devices Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) 00013eefb730 /VenHw(..)/Scsi(0,0) 00013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) Issues: === * For removal case, we may need more consideration since removing handles unconditionally may end up breaking integrity of handles (as some may still be held and referenced to by a UEFI app). Prerequisite: = * my patch, "disk: don't compile in partition support for spl/tpl if not really necessary"[2] [2] https://lists.denx.de/pipermail/u-boot/2022-April/481745.html Patchs: === For easy understandings, patches may be categorized into separate groups of changes. Patch#1-#3: DM: add a new feature (DM tag) Patch#4-#10: UEFI: dynamically create/remove efi_disk's for a raw disk and its partitions Patch#11-#12: UEFI: use udevice read/write interfaces Change history: === v5 (Apr, 19, 2022) * modify patch#12 so that CONFIG_PARTITIONS can be treated as optional (patch#12) v4 (Apr, 15, 2022) * rebased on pre-2022.07-rc1 * removed already-merged patches * added patch#1 (for better error code) * merged v3's patch#19 to patch#7 to make bisect work * split v3's patch#13 into patch#8(create) and patch#10(delete) * move a function prototype out of "#ifdef CONFIG_PARTITIONS" (patch#4) * move function prototypes out of "#ifdef CONFIG_PARTITIONS" (patch#11) v3
