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 sjg@chromium.org:
Hi Heinrich,
On Thu, 17 Jun 2021 at 09:20, Heinrich Schuchardt xypron.glpk@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.glpk@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