[PATCH 1/2] fwu: Make boottime check failures visible

[PATCH 1/2] fwu: Make boottime check failures visible

[Michal Simek]

On systems with FWU enabled but without the required DT changes the
boottime checks fail. The failures are only reported via log_debug()
which is compiled out by default, so the user has no idea what is going
on.

Use log_err() to make these failures visible.

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

 lib/fwu_updates/fwu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
index 2b11e5da061d..e9bb1b4fc656 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -759,7 +759,7 @@ static int fwu_boottime_checks(void)
 
 	ret = uclass_first_device_err(UCLASS_FWU_MDATA, &g_dev);
 	if (ret) {
-		log_debug("Cannot find fwu device\n");
+		log_err("Cannot find fwu device\n");
 		return ret;
 	}
 
@@ -771,7 +771,7 @@ static int fwu_boottime_checks(void)
 
 	ret = fwu_init();
 	if (ret) {
-		log_debug("fwu_init() failed\n");
+		log_err("fwu_init() failed\n");
 		return ret;
 	}
 
---
base-commit: ea62096437b39ff9038f7169e461bfe7863ee85a
branch: debian-sent3

-- 
2.43.0

[PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Michal Simek]

On systems with FWU enabled but without the required DT changes the FWU
metadata device is not found and fwu_boottime_checks() returns an error.
Being an initcall, that non-zero return aborts the boot flow

Return 0 instead so the boot continues. The preceding log_err() still
tells the user that the FWU device could not be found.

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

We have reached issue where testing team is using the same defconfig
to test both scenarios and difference is in DT itself.
I think it should be quite save to return 0 if any UCLASS_FWU_MDATA driver
is not detected. If there is issue with fwu structure error is correctly
propagated.
---
 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 e9bb1b4fc656..25eb5af572f3 100644
--- a/lib/fwu_updates/fwu.c
+++ b/lib/fwu_updates/fwu.c
@@ -760,7 +760,7 @@ static int fwu_boottime_checks(void)
 	ret = uclass_first_device_err(UCLASS_FWU_MDATA, &g_dev);
 	if (ret) {
 		log_err("Cannot find fwu device\n");
-		return ret;
+		return 0;
 	}
 
 	/* Don't have boot time checks on sandbox */
---
base-commit: ea62096437b39ff9038f7169e461bfe7863ee85a
branch: debian-sent3

-- 
2.43.0

Re: [PATCH 1/2] fwu: Make boottime check failures visible

[Ilias Apalodimas]

On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
>
> On systems with FWU enabled but without the required DT changes the
> boottime checks fail. The failures are only reported via log_debug()
> which is compiled out by default, so the user has no idea what is going
> on.
>
> Use log_err() to make these failures visible.
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>
>  lib/fwu_updates/fwu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> index 2b11e5da061d..e9bb1b4fc656 100644
> --- a/lib/fwu_updates/fwu.c
> +++ b/lib/fwu_updates/fwu.c
> @@ -759,7 +759,7 @@ static int fwu_boottime_checks(void)
>
>         ret = uclass_first_device_err(UCLASS_FWU_MDATA, &g_dev);
>         if (ret) {
> -               log_debug("Cannot find fwu device\n");
> +               log_err("Cannot find fwu device\n");
>                 return ret;
>         }
>
> @@ -771,7 +771,7 @@ static int fwu_boottime_checks(void)
>
>         ret = fwu_init();
>         if (ret) {
> -               log_debug("fwu_init() failed\n");
> +               log_err("fwu_init() failed\n");
>                 return ret;
>         }
>
> ---
> base-commit: ea62096437b39ff9038f7169e461bfe7863ee85a
> branch: debian-sent3
>
> --
> 2.43.0
>

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Ilias Apalodimas]

Hi Michal,

On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
>
> On systems with FWU enabled but without the required DT changes the FWU
> metadata device is not found and fwu_boottime_checks() returns an error.
> Being an initcall, that non-zero return aborts the boot flow
>
> Return 0 instead so the boot continues. The preceding log_err() still
> tells the user that the FWU device could not be found.

Won't that affect the board later on? E.g When you do capsule updates,
updating the metadata will fail

Thanks
/Ilias
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---
>
> We have reached issue where testing team is using the same defconfig
> to test both scenarios and difference is in DT itself.
> I think it should be quite save to return 0 if any UCLASS_FWU_MDATA driver
> is not detected. If there is issue with fwu structure error is correctly
> propagated.
> ---
>  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 e9bb1b4fc656..25eb5af572f3 100644
> --- a/lib/fwu_updates/fwu.c
> +++ b/lib/fwu_updates/fwu.c
> @@ -760,7 +760,7 @@ static int fwu_boottime_checks(void)
>         ret = uclass_first_device_err(UCLASS_FWU_MDATA, &g_dev);
>         if (ret) {
>                 log_err("Cannot find fwu device\n");
> -               return ret;
> +               return 0;
>         }
>
>         /* Don't have boot time checks on sandbox */
> ---
> base-commit: ea62096437b39ff9038f7169e461bfe7863ee85a
> branch: debian-sent3
>
> --
> 2.43.0
>

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Michal Simek]

On 7/2/26 09:41, Ilias Apalodimas wrote:
> Hi Michal,
> 
> On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
>>
>> On systems with FWU enabled but without the required DT changes the FWU
>> metadata device is not found and fwu_boottime_checks() returns an error.
>> Being an initcall, that non-zero return aborts the boot flow
>>
>> Return 0 instead so the boot continues. The preceding log_err() still
>> tells the user that the FWU device could not be found.
> 
> Won't that affect the board later on? E.g When you do capsule updates,
> updating the metadata will fail

Do you mean on systems without mdata?

Thanks,
Michal

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Ilias Apalodimas]

On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 7/2/26 09:41, Ilias Apalodimas wrote:
> > Hi Michal,
> >
> > On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
> >>
> >> On systems with FWU enabled but without the required DT changes the FWU
> >> metadata device is not found and fwu_boottime_checks() returns an error.
> >> Being an initcall, that non-zero return aborts the boot flow
> >>
> >> Return 0 instead so the boot continues. The preceding log_err() still
> >> tells the user that the FWU device could not be found.
> >
> > Won't that affect the board later on? E.g When you do capsule updates,
> > updating the metadata will fail
>
> Do you mean on systems without mdata?

Yes. if the config is enabled it will make the capsule update code
searching and updating metadata.

Cheers
/Ilias
>
> Thanks,
> Michal

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Michal Simek]

On 7/2/26 10:03, Ilias Apalodimas wrote:
> On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 7/2/26 09:41, Ilias Apalodimas wrote:
>>> Hi Michal,
>>>
>>> On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
>>>>
>>>> On systems with FWU enabled but without the required DT changes the FWU
>>>> metadata device is not found and fwu_boottime_checks() returns an error.
>>>> Being an initcall, that non-zero return aborts the boot flow
>>>>
>>>> Return 0 instead so the boot continues. The preceding log_err() still
>>>> tells the user that the FWU device could not be found.
>>>
>>> Won't that affect the board later on? E.g When you do capsule updates,
>>> updating the metadata will fail
>>
>> Do you mean on systems without mdata?
> 
> Yes. if the config is enabled it will make the capsule update code
> searching and updating metadata.

fwu mdata backend is not enabled hence not used. fwu just returns 0 in dump.
Updating metadata will never call any backend.

Some logs below.

Thanks,
Michal


ZYNQ GEM: f1a60000, mdio bus f1a60000, phyaddr 1, interface rgmii-id
eth0: ethernet@f1a60000
ZYNQ GEM: ed920000, mdio bus ed920000, phyaddr 0, interface 10gbase-r
, eth1: ethernet@ed920000
Cannot find fwu device
Cannot persist EFI variables without system partition
Missing TPMv2 device for EFI_TCG_PROTOCOL
Missing RNG device for EFI_RNG_PROTOCOL
Hit any key to stop autoboot: 0
versal2>
versal2> fwu
	FWU Metadata
crc32: 0x0
version: 0x0
size: 0x0
active_index: 0x0
previous_active_index: 0x0
	Image Info

Image Type Guid: 00000000-0000-0000-0000-000000000000
Location Guid: 00000000-0000-0000-0000-000000000000
Image Guid:  00000000-0000-0000-0000-000000000000
Image Acceptance: no
Image Guid:  00000000-0000-0000-0000-000000000000
Image Acceptance: no
versal2>
versal2> efidebug capsule esrt
========================================
ESRT: fw_resource_count=1
ESRT: fw_resource_count_max=1
ESRT: fw_resource_version=1
[entry 0]==============================
ESRT: fw_class=ED9E7FCF-47B3-40CD-B6E3-565F14676D82
ESRT: fw_type=system FW
ESRT: fw_version=0
ESRT: lowest_supported_fw_version=0
ESRT: capsule_flags=0
ESRT: last_attempt_version=0
ESRT: last_attempt_status=success
========================================

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Ilias Apalodimas]

Hi Michal

On Thu, 2 Jul 2026 at 12:10, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 7/2/26 10:03, Ilias Apalodimas wrote:
> > On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek@amd.com> wrote:
> >>
> >>
> >>
> >> On 7/2/26 09:41, Ilias Apalodimas wrote:
> >>> Hi Michal,
> >>>
> >>> On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
> >>>>
> >>>> On systems with FWU enabled but without the required DT changes the FWU
> >>>> metadata device is not found and fwu_boottime_checks() returns an error.
> >>>> Being an initcall, that non-zero return aborts the boot flow
> >>>>
> >>>> Return 0 instead so the boot continues. The preceding log_err() still
> >>>> tells the user that the FWU device could not be found.
> >>>
> >>> Won't that affect the board later on? E.g When you do capsule updates,
> >>> updating the metadata will fail
> >>
> >> Do you mean on systems without mdata?
> >
> > Yes. if the config is enabled it will make the capsule update code
> > searching and updating metadata.
>
> fwu mdata backend is not enabled hence not used. fwu just returns 0 in dump.
> Updating metadata will never call any backend.

The prints below are just from fwu and efidebug for the ESRT table.
Those will work.
But what happens if you try to run a capsule update?
Eg. efi_capsule_update_firmware() will call
fwu_plat_get_update_index() which will fail,. no ?

Thanks
/Ilias
>
> Some logs below.
>
> Thanks,
> Michal
>
>
> ZYNQ GEM: f1a60000, mdio bus f1a60000, phyaddr 1, interface rgmii-id
> eth0: ethernet@f1a60000
> ZYNQ GEM: ed920000, mdio bus ed920000, phyaddr 0, interface 10gbase-r
> , eth1: ethernet@ed920000
> Cannot find fwu device
> Cannot persist EFI variables without system partition
> Missing TPMv2 device for EFI_TCG_PROTOCOL
> Missing RNG device for EFI_RNG_PROTOCOL
> Hit any key to stop autoboot: 0
> versal2>
> versal2> fwu
>         FWU Metadata
> crc32: 0x0
> version: 0x0
> size: 0x0
> active_index: 0x0
> previous_active_index: 0x0
>         Image Info
>
> Image Type Guid: 00000000-0000-0000-0000-000000000000
> Location Guid: 00000000-0000-0000-0000-000000000000
> Image Guid:  00000000-0000-0000-0000-000000000000
> Image Acceptance: no
> Image Guid:  00000000-0000-0000-0000-000000000000
> Image Acceptance: no
> versal2>
> versal2> efidebug capsule esrt
> ========================================
> ESRT: fw_resource_count=1
> ESRT: fw_resource_count_max=1
> ESRT: fw_resource_version=1
> [entry 0]==============================
> ESRT: fw_class=ED9E7FCF-47B3-40CD-B6E3-565F14676D82
> ESRT: fw_type=system FW
> ESRT: fw_version=0
> ESRT: lowest_supported_fw_version=0
> ESRT: capsule_flags=0
> ESRT: last_attempt_version=0
> ESRT: last_attempt_status=success
> ========================================
>

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Michal Simek]

On 7/2/26 12:07, Ilias Apalodimas wrote:
> Hi Michal
> 
> On Thu, 2 Jul 2026 at 12:10, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 7/2/26 10:03, Ilias Apalodimas wrote:
>>> On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek@amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/2/26 09:41, Ilias Apalodimas wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
>>>>>>
>>>>>> On systems with FWU enabled but without the required DT changes the FWU
>>>>>> metadata device is not found and fwu_boottime_checks() returns an error.
>>>>>> Being an initcall, that non-zero return aborts the boot flow
>>>>>>
>>>>>> Return 0 instead so the boot continues. The preceding log_err() still
>>>>>> tells the user that the FWU device could not be found.
>>>>>
>>>>> Won't that affect the board later on? E.g When you do capsule updates,
>>>>> updating the metadata will fail
>>>>
>>>> Do you mean on systems without mdata?
>>>
>>> Yes. if the config is enabled it will make the capsule update code
>>> searching and updating metadata.
>>
>> fwu mdata backend is not enabled hence not used. fwu just returns 0 in dump.
>> Updating metadata will never call any backend.
> 
> The prints below are just from fwu and efidebug for the ESRT table.
> Those will work.
> But what happens if you try to run a capsule update?
> Eg. efi_capsule_update_firmware() will call
> fwu_plat_get_update_index() which will fail,. no ?

it fails on fwu_update_checks_pass() before fwu_plat_get_update_index().

versal2> efidebug capsule update -v 0x40000000
Capsule guid: 6dcbd5ed-e82d-4c44-bda1-7194199ad92a
Capsule flags: 0x18000
Capsule header size: 0x1c
Capsule image size: 0x41434
FWU checks failed. Cannot start update
Cannot handle a capsule at 0000000040000000

Thanks,
Michal

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Ilias Apalodimas]

On Thu, 2 Jul 2026 at 14:55, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 7/2/26 12:07, Ilias Apalodimas wrote:
> > Hi Michal
> >
> > On Thu, 2 Jul 2026 at 12:10, Michal Simek <michal.simek@amd.com> wrote:
> >>
> >>
> >>
> >> On 7/2/26 10:03, Ilias Apalodimas wrote:
> >>> On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek@amd.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 7/2/26 09:41, Ilias Apalodimas wrote:
> >>>>> Hi Michal,
> >>>>>
> >>>>> On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
> >>>>>>
> >>>>>> On systems with FWU enabled but without the required DT changes the FWU
> >>>>>> metadata device is not found and fwu_boottime_checks() returns an error.
> >>>>>> Being an initcall, that non-zero return aborts the boot flow
> >>>>>>
> >>>>>> Return 0 instead so the boot continues. The preceding log_err() still
> >>>>>> tells the user that the FWU device could not be found.
> >>>>>
> >>>>> Won't that affect the board later on? E.g When you do capsule updates,
> >>>>> updating the metadata will fail
> >>>>
> >>>> Do you mean on systems without mdata?
> >>>
> >>> Yes. if the config is enabled it will make the capsule update code
> >>> searching and updating metadata.
> >>
> >> fwu mdata backend is not enabled hence not used. fwu just returns 0 in dump.
> >> Updating metadata will never call any backend.
> >
> > The prints below are just from fwu and efidebug for the ESRT table.
> > Those will work.
> > But what happens if you try to run a capsule update?
> > Eg. efi_capsule_update_firmware() will call
> > fwu_plat_get_update_index() which will fail,. no ?
>
> it fails on fwu_update_checks_pass() before fwu_plat_get_update_index().
>
> versal2> efidebug capsule update -v 0x40000000
> Capsule guid: 6dcbd5ed-e82d-4c44-bda1-7194199ad92a
> Capsule flags: 0x18000
> Capsule header size: 0x1c
> Capsule image size: 0x41434
> FWU checks failed. Cannot start update
> Cannot handle a capsule at 0000000040000000

Ah yes, that ret 0; will never update boottime_check properly.

Thanks
/Ilias
>
> Thanks,
> Michal
>

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Michal Simek]

On 7/2/26 14:00, Ilias Apalodimas wrote:
> On Thu, 2 Jul 2026 at 14:55, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 7/2/26 12:07, Ilias Apalodimas wrote:
>>> Hi Michal
>>>
>>> On Thu, 2 Jul 2026 at 12:10, Michal Simek <michal.simek@amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/2/26 10:03, Ilias Apalodimas wrote:
>>>>> On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek@amd.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/2/26 09:41, Ilias Apalodimas wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Tue, 30 Jun 2026 at 16:18, Michal Simek <michal.simek@amd.com> wrote:
>>>>>>>>
>>>>>>>> On systems with FWU enabled but without the required DT changes the FWU
>>>>>>>> metadata device is not found and fwu_boottime_checks() returns an error.
>>>>>>>> Being an initcall, that non-zero return aborts the boot flow
>>>>>>>>
>>>>>>>> Return 0 instead so the boot continues. The preceding log_err() still
>>>>>>>> tells the user that the FWU device could not be found.
>>>>>>>
>>>>>>> Won't that affect the board later on? E.g When you do capsule updates,
>>>>>>> updating the metadata will fail
>>>>>>
>>>>>> Do you mean on systems without mdata?
>>>>>
>>>>> Yes. if the config is enabled it will make the capsule update code
>>>>> searching and updating metadata.
>>>>
>>>> fwu mdata backend is not enabled hence not used. fwu just returns 0 in dump.
>>>> Updating metadata will never call any backend.
>>>
>>> The prints below are just from fwu and efidebug for the ESRT table.
>>> Those will work.
>>> But what happens if you try to run a capsule update?
>>> Eg. efi_capsule_update_firmware() will call
>>> fwu_plat_get_update_index() which will fail,. no ?
>>
>> it fails on fwu_update_checks_pass() before fwu_plat_get_update_index().
>>
>> versal2> efidebug capsule update -v 0x40000000
>> Capsule guid: 6dcbd5ed-e82d-4c44-bda1-7194199ad92a
>> Capsule flags: 0x18000
>> Capsule header size: 0x1c
>> Capsule image size: 0x41434
>> FWU checks failed. Cannot start update
>> Cannot handle a capsule at 0000000040000000
> 
> Ah yes, that ret 0; will never update boottime_check properly.

I think the question is if this is acceptable or not.
Because none checked error code before
583efb504058 ("event: Check return value from event_notify_null()")
and then
353166279c32 ("fwu: Move boottime checks to EVT_POST_PREBOOT")
it checks it too.
It means in past fwu code error out but u-boot continue to work with above 
behavior.

Pretty much this patch is bringing back old behavior before these two patches 
have been applied to the repo.

Thanks,
Michal

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Ilias Apalodimas]

Hi Michal,

[...]

> >>>
> >>> The prints below are just from fwu and efidebug for the ESRT table.
> >>> Those will work.
> >>> But what happens if you try to run a capsule update?
> >>> Eg. efi_capsule_update_firmware() will call
> >>> fwu_plat_get_update_index() which will fail,. no ?
> >>
> >> it fails on fwu_update_checks_pass() before fwu_plat_get_update_index().
> >>
> >> versal2> efidebug capsule update -v 0x40000000
> >> Capsule guid: 6dcbd5ed-e82d-4c44-bda1-7194199ad92a
> >> Capsule flags: 0x18000
> >> Capsule header size: 0x1c
> >> Capsule image size: 0x41434
> >> FWU checks failed. Cannot start update
> >> Cannot handle a capsule at 0000000040000000
> >
> > Ah yes, that ret 0; will never update boottime_check properly.
>
> I think the question is if this is acceptable or not.
> Because none checked error code before
> 583efb504058 ("event: Check return value from event_notify_null()")
> and then
> 353166279c32 ("fwu: Move boottime checks to EVT_POST_PREBOOT")
> it checks it too.
> It means in past fwu code error out but u-boot continue to work with above
> behavior.

That's also a bug imho then.

>
> Pretty much this patch is bringing back old behavior before these two patches
> have been applied to the repo.

It doesn't make sense to update to or run a firmware that won't be
able to use capsule updates ever again.

Thanks
/Ilias
>
> Thanks,
> Michal
>

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Michal Simek]

On 7/2/26 14:24, Ilias Apalodimas wrote:
> Hi Michal,
> 
> [...]
> 
>>>>>
>>>>> The prints below are just from fwu and efidebug for the ESRT table.
>>>>> Those will work.
>>>>> But what happens if you try to run a capsule update?
>>>>> Eg. efi_capsule_update_firmware() will call
>>>>> fwu_plat_get_update_index() which will fail,. no ?
>>>>
>>>> it fails on fwu_update_checks_pass() before fwu_plat_get_update_index().
>>>>
>>>> versal2> efidebug capsule update -v 0x40000000
>>>> Capsule guid: 6dcbd5ed-e82d-4c44-bda1-7194199ad92a
>>>> Capsule flags: 0x18000
>>>> Capsule header size: 0x1c
>>>> Capsule image size: 0x41434
>>>> FWU checks failed. Cannot start update
>>>> Cannot handle a capsule at 0000000040000000
>>>
>>> Ah yes, that ret 0; will never update boottime_check properly.
>>
>> I think the question is if this is acceptable or not.
>> Because none checked error code before
>> 583efb504058 ("event: Check return value from event_notify_null()")
>> and then
>> 353166279c32 ("fwu: Move boottime checks to EVT_POST_PREBOOT")
>> it checks it too.
>> It means in past fwu code error out but u-boot continue to work with above
>> behavior.
> 
> That's also a bug imho then.
> 
>>
>> Pretty much this patch is bringing back old behavior before these two patches
>> have been applied to the repo.
> 
> It doesn't make sense to update to or run a firmware that won't be
> able to use capsule updates ever again.

It means that can be consider as misconfiguration. Which ends up today in 
forever loop (1/2 will at least tell now what it is happening).

, eth1: ethernet@ed920000
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device
Cannot find fwu device

But shouldn't be there different action? Go back to second image or reset for 
example?

Thanks,
Michal

Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device

[Ilias Apalodimas]

On Thu, 2 Jul 2026 at 15:40, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 7/2/26 14:24, Ilias Apalodimas wrote:
> > Hi Michal,
> >
> > [...]
> >
> >>>>>
> >>>>> The prints below are just from fwu and efidebug for the ESRT table.
> >>>>> Those will work.
> >>>>> But what happens if you try to run a capsule update?
> >>>>> Eg. efi_capsule_update_firmware() will call
> >>>>> fwu_plat_get_update_index() which will fail,. no ?
> >>>>
> >>>> it fails on fwu_update_checks_pass() before fwu_plat_get_update_index().
> >>>>
> >>>> versal2> efidebug capsule update -v 0x40000000
> >>>> Capsule guid: 6dcbd5ed-e82d-4c44-bda1-7194199ad92a
> >>>> Capsule flags: 0x18000
> >>>> Capsule header size: 0x1c
> >>>> Capsule image size: 0x41434
> >>>> FWU checks failed. Cannot start update
> >>>> Cannot handle a capsule at 0000000040000000
> >>>
> >>> Ah yes, that ret 0; will never update boottime_check properly.
> >>
> >> I think the question is if this is acceptable or not.
> >> Because none checked error code before
> >> 583efb504058 ("event: Check return value from event_notify_null()")
> >> and then
> >> 353166279c32 ("fwu: Move boottime checks to EVT_POST_PREBOOT")
> >> it checks it too.
> >> It means in past fwu code error out but u-boot continue to work with above
> >> behavior.
> >
> > That's also a bug imho then.
> >
> >>
> >> Pretty much this patch is bringing back old behavior before these two patches
> >> have been applied to the repo.
> >
> > It doesn't make sense to update to or run a firmware that won't be
> > able to use capsule updates ever again.
>
> It means that can be consider as misconfiguration. Which ends up today in
> forever loop (1/2 will at least tell now what it is happening).
>
> , eth1: ethernet@ed920000
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
> Cannot find fwu device
>
> But shouldn't be there different action? Go back to second image or reset for
> example?

At this point, either your metadata is gone, in which case you can
either try to recreate them and hope for the best or an update broke
the fwu mechanism indeed.
In theory the board will automatically revert to the secondary
partition after X reboots since no one is providing an acceptance
capsule (or variable) so reseting should be fine.

Cheers
/Ilias
>
> Thanks,
> Michal