On 7/2/26 15:07, Ilias Apalodimas wrote:
On Thu, 2 Jul 2026 at 15:40, Michal Simek <[email protected]> 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.
It just means that I should drop this patch right?
Thanks,
Michal
