From: Michal Simek <michal.simek@amd.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: u-boot@lists.denx.de, git@amd.com,
Dario Binacchi <dario.binacchi@amarulasolutions.com>,
Kory Maincent <kory.maincent@bootlin.com>,
Padmarao Begari <padmarao.begari@amd.com>,
Simon Glass <sjg@chromium.org>,
Sughosh Ganu <sughosh.ganu@arm.com>,
Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device
Date: Thu, 2 Jul 2026 14:09:21 +0200 [thread overview]
Message-ID: <a9285398-9e71-4767-a34e-2dc767c11538@amd.com> (raw)
In-Reply-To: <CAC_iWj+VqjpWPDRVGvCYpWMg4hmjeS1YzPBZiMvvQqvRRLe+Vg@mail.gmail.com>
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
next prev parent reply other threads:[~2026-07-02 12:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 13:17 [PATCH 1/2] fwu: Make boottime check failures visible Michal Simek
2026-06-30 13:17 ` [PATCH 2/2] fwu: Gracefully handle missing FWU metadata device Michal Simek
2026-07-02 7:41 ` Ilias Apalodimas
2026-07-02 7:48 ` Michal Simek
2026-07-02 8:03 ` Ilias Apalodimas
2026-07-02 9:09 ` Michal Simek
2026-07-02 10:07 ` Ilias Apalodimas
2026-07-02 11:55 ` Michal Simek
2026-07-02 12:00 ` Ilias Apalodimas
2026-07-02 12:09 ` Michal Simek [this message]
2026-07-02 12:24 ` Ilias Apalodimas
2026-07-02 12:40 ` Michal Simek
2026-07-02 13:07 ` Ilias Apalodimas
2026-06-30 18:47 ` [PATCH 1/2] fwu: Make boottime check failures visible Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9285398-9e71-4767-a34e-2dc767c11538@amd.com \
--to=michal.simek@amd.com \
--cc=dario.binacchi@amarulasolutions.com \
--cc=git@amd.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kory.maincent@bootlin.com \
--cc=padmarao.begari@amd.com \
--cc=sjg@chromium.org \
--cc=sughosh.ganu@arm.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.