Can we just (temporarily) revert f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot")
until this issue is resolved properly? Because, currently it seems like the commit breaking the things was introduced at some point and cannot be fixed within a reasonable amount of time since it seems that the issue is related to the EFI implementation design. сб, 26 июн. 2021 г. в 21:31, Simon Glass <s...@chromium.org>: > > Hi Heinrich, > > On Thu, 17 Jun 2021 at 09:20, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > Up to now when devices became available after executing the UEFI > > sub-system initialization where not available for EFI applications. > > > > With the patch block devices are added to the UEFI object list whenever > > they are probed. > > > > Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de> > > --- > > drivers/core/device.c | 7 +++ > > include/efi_loader.h | 6 +++ > > lib/efi_driver/Makefile | 1 + > > lib/efi_driver/efi_dm_integration.c | 36 +++++++++++++++ > > lib/efi_loader/efi_disk.c | 72 +++++++++++++++++------------ > > 5 files changed, 93 insertions(+), 29 deletions(-) > > create mode 100644 lib/efi_driver/efi_dm_integration.c > > > > diff --git a/drivers/core/device.c b/drivers/core/device.c > > index cb960f8ec4..7355a5c2a9 100644 > > --- a/drivers/core/device.c > > +++ b/drivers/core/device.c > > @@ -14,6 +14,7 @@ > > #include <asm/global_data.h> > > #include <asm/io.h> > > #include <clk.h> > > +#include <efi_loader.h> > > #include <fdtdec.h> > > #include <fdt_support.h> > > #include <malloc.h> > > @@ -579,6 +580,12 @@ int device_probe(struct udevice *dev) > > if (dev->parent && device_get_uclass_id(dev) == UCLASS_PINCTRL) > > pinctrl_select_state(dev, "default"); > > > > + if (CONFIG_IS_ENABLED(EFI_LOADER)) { > > + ret = efi_post_probe_device(dev); > > + if (ret) > > + goto fail_uclass; > > + } > > Huge flashing NAK on this. > > Way back in the early days I mentioned that UEFI should not have its > own tables but should use driver model directly. It was discussed but > 'do it later' was the answer. > > To the extend that UEFI needs extra info to be tacked onto devices we > should figure out a consistent way to do it. > > What I proposed 5-ish years ago is lots in the mists of time, but it > is something like: > > - use driver model for *everything* > - use struct udevice everywhere > - avoid using parallel tables > - things on the UEFI side then become dynamic rather than static > - so there is no need for fixups > - figure out what extra info is needed and come up with a generic way > to attach it to devices > > So this is definitely not the right approach. > > Regards, > Simon -- With best regards, Matwey V. Kornilov