[PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Michal Simek]

Hi,

the whole series is trying to address issues we have on platforms where usb
and ufs init are not done before efi initialization. This is happenin on
platforms where A/B update is enabled. FWU code is called early and do EFI
initialization before usb and ufs started that's why they are not visible.

We are workarounding it by starting usb/ufs from board file but this should
be more generic approach.

Thanks,
Michal

Changes in v2:
- new patch in series
- check return value

Michal Simek (3):
  event: Check return value from event_notify_null()
  event: Introduce EVT_POST_PREBOOT event
  fwu: Move boottime checks to EVT_POST_PREBOOT

 common/board_r.c      | 6 +++++-
 common/main.c         | 4 ++++
 include/event.h       | 9 +++++++++
 lib/fwu_updates/fwu.c | 2 +-
 test/dm/fwu_mdata.c   | 4 ++--
 5 files changed, 21 insertions(+), 4 deletions(-)

-- 
2.43.0

base-commit: 61ddd555f58ef5169c48b190423640d949e4aad1
branch: debian-sent3

[PATCH v2 1/3] event: Check return value from event_notify_null()

[Michal Simek]

event_notify_null() returns int but its return value is not
checked in run_main_loop() and in fwu_mdata tests.
Add proper error checking to all unchecked call sites.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

Changes in v2:
- new patch in series

 common/board_r.c    | 6 +++++-
 test/dm/fwu_mdata.c | 4 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 76f9fc090fbe..00f29385d80a 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -579,11 +579,15 @@ static int dm_announce(void)
 
 static int run_main_loop(void)
 {
+	int ret;
+
 #ifdef CONFIG_SANDBOX
 	sandbox_main_loop_init();
 #endif
 
-	event_notify_null(EVT_MAIN_LOOP);
+	ret = event_notify_null(EVT_MAIN_LOOP);
+	if (ret)
+		return ret;
 
 	/* main_loop() can return to retry autoboot, if so just run it again */
 	for (;;)
diff --git a/test/dm/fwu_mdata.c b/test/dm/fwu_mdata.c
index b7680632f95f..643b647af0a9 100644
--- a/test/dm/fwu_mdata.c
+++ b/test/dm/fwu_mdata.c
@@ -100,7 +100,7 @@ static int dm_test_fwu_mdata_read(struct unit_test_state *uts)
 	 * Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
 	 * to populate g_dev global pointer in that library.
 	 */
-	event_notify_null(EVT_MAIN_LOOP);
+	ut_assertok(event_notify_null(EVT_MAIN_LOOP));
 
 	ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, &dev));
 	ut_assertok(fwu_init());
@@ -127,7 +127,7 @@ static int dm_test_fwu_mdata_write(struct unit_test_state *uts)
 	 * Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
 	 * to populate g_dev global pointer in that library.
 	 */
-	event_notify_null(EVT_MAIN_LOOP);
+	ut_assertok(event_notify_null(EVT_MAIN_LOOP));
 
 	ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, &dev));
 
-- 
2.43.0

Re: [PATCH v2 1/3] event: Check return value from event_notify_null()

[Simon Glass]

On Wed, 18 Mar 2026 at 07:25, Michal Simek <michal.simek@amd.com> wrote:
>
> event_notify_null() returns int but its return value is not
> checked in run_main_loop() and in fwu_mdata tests.
> Add proper error checking to all unchecked call sites.
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---
>
> Changes in v2:
> - new patch in series
>
>  common/board_r.c    | 6 +++++-
>  test/dm/fwu_mdata.c | 4 ++--
>  2 files changed, 7 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>


>
> diff --git a/common/board_r.c b/common/board_r.c
> index 76f9fc090fbe..00f29385d80a 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -579,11 +579,15 @@ static int dm_announce(void)
>
>  static int run_main_loop(void)
>  {
> +       int ret;
> +
>  #ifdef CONFIG_SANDBOX
>         sandbox_main_loop_init();
>  #endif
>
> -       event_notify_null(EVT_MAIN_LOOP);
> +       ret = event_notify_null(EVT_MAIN_LOOP);
> +       if (ret)
> +               return ret;
>
>         /* main_loop() can return to retry autoboot, if so just run it again */
>         for (;;)
> diff --git a/test/dm/fwu_mdata.c b/test/dm/fwu_mdata.c
> index b7680632f95f..643b647af0a9 100644
> --- a/test/dm/fwu_mdata.c
> +++ b/test/dm/fwu_mdata.c
> @@ -100,7 +100,7 @@ static int dm_test_fwu_mdata_read(struct unit_test_state *uts)
>          * Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
>          * to populate g_dev global pointer in that library.
>          */
> -       event_notify_null(EVT_MAIN_LOOP);
> +       ut_assertok(event_notify_null(EVT_MAIN_LOOP));
>
>         ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, &dev));
>         ut_assertok(fwu_init());
> @@ -127,7 +127,7 @@ static int dm_test_fwu_mdata_write(struct unit_test_state *uts)
>          * Trigger lib/fwu_updates/fwu.c fwu_boottime_checks()
>          * to populate g_dev global pointer in that library.
>          */
> -       event_notify_null(EVT_MAIN_LOOP);
> +       ut_assertok(event_notify_null(EVT_MAIN_LOOP));
>
>         ut_assertok(uclass_first_device_err(UCLASS_FWU_MDATA, &dev));
>
> --
> 2.43.0
>

[PATCH v2 2/3] event: Introduce EVT_POST_PREBOOT event

[Michal Simek]

Add a new EVT_POST_PREBOOT event type which is fired in main_loop()
after the preboot command has been executed.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

Changes in v2:
- check return value

 common/main.c   | 4 ++++
 include/event.h | 9 +++++++++
 2 files changed, 13 insertions(+)

diff --git a/common/main.c b/common/main.c
index b0b6e74f5d3d..4b4504557f6e 100644
--- a/common/main.c
+++ b/common/main.c
@@ -19,6 +19,7 @@
 #include <net.h>
 #include <version_string.h>
 #include <efi_loader.h>
+#include <event.h>
 
 static void run_preboot_environment_command(void)
 {
@@ -53,6 +54,9 @@ void main_loop(void)
 	if (IS_ENABLED(CONFIG_USE_PREBOOT))
 		run_preboot_environment_command();
 
+	if (event_notify_null(EVT_POST_PREBOOT))
+		return;
+
 	if (IS_ENABLED(CONFIG_UPDATE_TFTP))
 		update_tftp(0UL, NULL, NULL);
 
diff --git a/include/event.h b/include/event.h
index 1d267f1d1054..3ce5f992b04e 100644
--- a/include/event.h
+++ b/include/event.h
@@ -153,6 +153,15 @@ enum event_t {
 	 */
 	EVT_MAIN_LOOP,
 
+	/**
+	 * @EVT_POST_PREBOOT:
+	 * This event is triggered in main_loop() after the preboot command
+	 * has run, so that devices initialised by preboot (e.g. USB, UFS)
+	 * are available to event handlers. Its parameter is NULL.
+	 * A non-zero return value causes the boot to fail.
+	 */
+	EVT_POST_PREBOOT,
+
 	/**
 	 * @EVT_OF_LIVE_BUILT:
 	 * This event is triggered immediately after the live device tree has been
-- 
2.43.0

Re: [PATCH v2 2/3] event: Introduce EVT_POST_PREBOOT event

[Simon Glass]

On Wed, 18 Mar 2026 at 07:25, Michal Simek <michal.simek@amd.com> wrote:
>
> Add a new EVT_POST_PREBOOT event type which is fired in main_loop()
> after the preboot command has been executed.
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---
>
> Changes in v2:
> - check return value
>
>  common/main.c   | 4 ++++
>  include/event.h | 9 +++++++++
>  2 files changed, 13 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>


>
> diff --git a/common/main.c b/common/main.c
> index b0b6e74f5d3d..4b4504557f6e 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -19,6 +19,7 @@
>  #include <net.h>
>  #include <version_string.h>
>  #include <efi_loader.h>
> +#include <event.h>
>
>  static void run_preboot_environment_command(void)
>  {
> @@ -53,6 +54,9 @@ void main_loop(void)
>         if (IS_ENABLED(CONFIG_USE_PREBOOT))
>                 run_preboot_environment_command();
>
> +       if (event_notify_null(EVT_POST_PREBOOT))
> +               return;
> +
>         if (IS_ENABLED(CONFIG_UPDATE_TFTP))
>                 update_tftp(0UL, NULL, NULL);
>
> diff --git a/include/event.h b/include/event.h
> index 1d267f1d1054..3ce5f992b04e 100644
> --- a/include/event.h
> +++ b/include/event.h
> @@ -153,6 +153,15 @@ enum event_t {
>          */
>         EVT_MAIN_LOOP,
>
> +       /**
> +        * @EVT_POST_PREBOOT:
> +        * This event is triggered in main_loop() after the preboot command
> +        * has run, so that devices initialised by preboot (e.g. USB, UFS)
> +        * are available to event handlers. Its parameter is NULL.
> +        * A non-zero return value causes the boot to fail.
> +        */
> +       EVT_POST_PREBOOT,
> +
>         /**
>          * @EVT_OF_LIVE_BUILT:
>          * This event is triggered immediately after the live device tree has been
> --
> 2.43.0
>

[PATCH v2 3/3] fwu: Move boottime checks to EVT_POST_PREBOOT

[Michal Simek]

Switch fwu_boottime_checks() from EVT_MAIN_LOOP to EVT_POST_PREBOOT
because there is no reason to call FWU so early. FWU triggers EFI
stack initialization before all devices are visible which prevents
the EFI stack from scanning these devices and adding them to EFI
variables.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

(no changes since v1)

 lib/fwu_updates/fwu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
index 37c613014d18..e82600a29a40 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -796,4 +796,4 @@ static int fwu_boottime_checks(void)
 
 	return 0;
 }
-EVENT_SPY_SIMPLE(EVT_MAIN_LOOP, fwu_boottime_checks);
+EVENT_SPY_SIMPLE(EVT_POST_PREBOOT, fwu_boottime_checks);
-- 
2.43.0

Re: [PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Casey Connolly]

Hi Michal,

On 18/03/2026 14:25, Michal Simek wrote:
> Hi,
> 
> the whole series is trying to address issues we have on platforms where usb
> and ufs init are not done before efi initialization. This is happenin on
> platforms where A/B update is enabled. FWU code is called early and do EFI
> initialization before usb and ufs started that's why they are not visible.

I guess I'm missing something here (but I'd very much appreciate an
explanation!) but isn't it actually necessary to set up the EFI
subsystem /before/ register block devices?

Since EFI sets up an event listener to react to new UCLASS_BLK devices
and create EFI device handles to represent them, it doesn't create
device handles for block devices that existed before the EFI subsystem
is up.

I ran into this issue when I wrote this patch:
https://gitlab.com/LinaroLtd/qcom-eco/u-boot/-/commit/e3616009a441358bf96bd2885d77fd46df710a9a

Kind regards,

> 
> We are workarounding it by starting usb/ufs from board file but this should
> be more generic approach.
> 
> Thanks,
> Michal
> 
> Changes in v2:
> - new patch in series
> - check return value
> 
> Michal Simek (3):
>   event: Check return value from event_notify_null()
>   event: Introduce EVT_POST_PREBOOT event
>   fwu: Move boottime checks to EVT_POST_PREBOOT
> 
>  common/board_r.c      | 6 +++++-
>  common/main.c         | 4 ++++
>  include/event.h       | 9 +++++++++
>  lib/fwu_updates/fwu.c | 2 +-
>  test/dm/fwu_mdata.c   | 4 ++--
>  5 files changed, 21 insertions(+), 4 deletions(-)
> 

-- 
// Casey (she/her)

Re: [PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Michal Simek]

On 3/20/26 00:56, Casey Connolly wrote:
> Hi Michal,
> 
> On 18/03/2026 14:25, Michal Simek wrote:
>> Hi,
>>
>> the whole series is trying to address issues we have on platforms where usb
>> and ufs init are not done before efi initialization. This is happenin on
>> platforms where A/B update is enabled. FWU code is called early and do EFI
>> initialization before usb and ufs started that's why they are not visible.
> 
> I guess I'm missing something here (but I'd very much appreciate an
> explanation!) but isn't it actually necessary to set up the EFI
> subsystem /before/ register block devices?
> 
> Since EFI sets up an event listener to react to new UCLASS_BLK devices
> and create EFI device handles to represent them, it doesn't create
> device handles for block devices that existed before the EFI subsystem
> is up.

This is solving different problem. This is related to FWU code/update capsule 
itself.

There are two options for automatic capsule applying.
The first one is in main_loop()


  62         if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY)) {
  63                 /* efi_init_early() already called */
  64                 if (efi_init_obj_list() == EFI_SUCCESS)
  65                         efi_launch_capsules();
  66         }

And second is in efi_init_obj_list()

385         /* Execute capsules after reboot */
386         if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK) &&
387             !IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY))
388                 ret = efi_launch_capsules();


And because everything passed on the first run when efi_init_obj_list() is 
called again it never calls efi_launch_capsules().

240         /* Initialize only once, but start every time if correctly initialized*/
241         if (efi_obj_list_initialized == OBJ_LIST_INITIALIZED)
242                 return efi_start_obj_list();

It means when you plug things later capsule update is never automatically called 
again.

These 3 patches happened based on my discussion with Ilias where we agreed that 
there is actually no reason to call FWU (which calls efi_init_obj_list() first) 
that early.
Calling it later postpone efi initialization which give us a room to do 
additional steps via preboot.


> I ran into this issue when I wrote this patch:
> https://gitlab.com/LinaroLtd/qcom-eco/u-boot/-/commit/e3616009a441358bf96bd2885d77fd46df710a9a

Then please send this patch out and your patch is likely solving different problem.

Thanks,
Michal

Re: [PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Wed, Mar 18, 2026 at 02:25:08PM +0100, Michal Simek wrote:

> Hi,
> 
> the whole series is trying to address issues we have on platforms where usb
> and ufs init are not done before efi initialization. This is happenin on
> platforms where A/B update is enabled. FWU code is called early and do EFI
> initialization before usb and ufs started that's why they are not visible.
> 
> We are workarounding it by starting usb/ufs from board file but this should
> be more generic approach.

This doesn't build on current next:
https://source.denx.de/u-boot/u-boot/-/jobs/1416493#L1001
common/event.c:56:1: error: static assertion failed: "event type_name size"
   56 | _Static_assert(ARRAY_SIZE(type_name) == EVT_COUNT, "event type_name size");
      | ^~~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:271: common/event.o] Error 1
make[1]: *** [Makefile:2201: common] Error 2
make[1]: *** Waiting for unfinished jobs....

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Michal Simek]

On 3/31/26 16:28, Tom Rini wrote:
> On Wed, Mar 18, 2026 at 02:25:08PM +0100, Michal Simek wrote:
> 
>> Hi,
>>
>> the whole series is trying to address issues we have on platforms where usb
>> and ufs init are not done before efi initialization. This is happenin on
>> platforms where A/B update is enabled. FWU code is called early and do EFI
>> initialization before usb and ufs started that's why they are not visible.
>>
>> We are workarounding it by starting usb/ufs from board file but this should
>> be more generic approach.
> 
> This doesn't build on current next:
> https://source.denx.de/u-boot/u-boot/-/jobs/1416493#L1001
> common/event.c:56:1: error: static assertion failed: "event type_name size"
>     56 | _Static_assert(ARRAY_SIZE(type_name) == EVT_COUNT, "event type_name size");
>        | ^~~~~~~~~~~~~~
> make[2]: *** [scripts/Makefile.build:271: common/event.o] Error 1
> make[1]: *** [Makefile:2201: common] Error 2
> make[1]: *** Waiting for unfinished jobs....
> 

I am able to replicate. Will send v3 with fixing this.

diff --git a/common/event.c b/common/event.c
index 8d7513eb10b6..936d5e36d691 100644
--- a/common/event.c
+++ b/common/event.c
@@ -49,6 +49,9 @@ const char *const type_name[] = {
         /* main loop events */
         "main_loop",

+       /* post preboot events */
+       "post preboot",
+
         /* livetree has been built */
         "of_live_init",
  };

Thanks,
Michal

Re: [PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Heinrich Schuchardt]

Am 31. März 2026 16:28:06 MESZ schrieb Tom Rini <trini@konsulko.com>:
>On Wed, Mar 18, 2026 at 02:25:08PM +0100, Michal Simek wrote:
>
>> Hi,
>> 
>> the whole series is trying to address issues we have on platforms where usb
>> and ufs init are not done before efi initialization. This is happenin on
>> platforms where A/B update is enabled. FWU code is called early and do EFI
>> initialization before usb and ufs started that's why they are not visible.
>> 
>> We are workarounding it by starting usb/ufs from board file but this should
>> be more generic approach.

If a block device is created after EFI initialization an event handler creates an EFI handle.

Do have an example for QEMU to reproduce the issue. 

I am on vacation till April 11th. But maybe Ilias could  look at it.

Best regards

Heinrich


>
>This doesn't build on current next:
>https://source.denx.de/u-boot/u-boot/-/jobs/1416493#L1001
>common/event.c:56:1: error: static assertion failed: "event type_name size"
>   56 | _Static_assert(ARRAY_SIZE(type_name) == EVT_COUNT, "event type_name size");
>      | ^~~~~~~~~~~~~~
>make[2]: *** [scripts/Makefile.build:271: common/event.o] Error 1
>make[1]: *** [Makefile:2201: common] Error 2
>make[1]: *** Waiting for unfinished jobs....
>

Re: [PATCH v2 0/3] fwu: Call EFI stack initialization after preboot

[Michal Simek]

On 3/31/26 17:00, Heinrich Schuchardt wrote:
> Am 31. März 2026 16:28:06 MESZ schrieb Tom Rini <trini@konsulko.com>:
>> On Wed, Mar 18, 2026 at 02:25:08PM +0100, Michal Simek wrote:
>>
>>> Hi,
>>>
>>> the whole series is trying to address issues we have on platforms where usb
>>> and ufs init are not done before efi initialization. This is happenin on
>>> platforms where A/B update is enabled. FWU code is called early and do EFI
>>> initialization before usb and ufs started that's why they are not visible.
>>>
>>> We are workarounding it by starting usb/ufs from board file but this should
>>> be more generic approach.
> 
> If a block device is created after EFI initialization an event handler creates an EFI handle.

But capsules are not automatically taken.

> Do have an example for QEMU to reproduce the issue.

Nope. Only on our HW.

> I am on vacation till April 11th. But maybe Ilias could  look at it.

Enjoy.

M