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

[Michal Simek]

On 7/2/26 15:07, Ilias Apalodimas wrote:
> On Thu, 2 Jul 2026 at 15:40, Michal Simek <michal.simek at 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 at 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.

It just means that I should drop this patch right?

Thanks,
Michal