[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 at 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 at amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/2/26 10:03, Ilias Apalodimas wrote:
>>>>> On Thu, 2 Jul 2026 at 10:49, Michal Simek <michal.simek at 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 at 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