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. Cheers /Ilias > > Thanks, > Michal
