From: Michal Simek <michal.simek@amd.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>,
u-boot@lists.denx.de, git@xilinx.com
Cc: Sughosh Ganu <sughosh.ganu@linaro.org>,
Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Jerome Forissier <jerome.forissier@linaro.org>,
Mattijs Korpershoek <mkorpershoek@baylibre.com>,
Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH v2] cmd: fwu: Dump custom fields from mdata structure
Date: Thu, 10 Apr 2025 09:48:13 +0200 [thread overview]
Message-ID: <bca32b70-0f59-43aa-9ddc-12d0caefacd3@amd.com> (raw)
In-Reply-To: <c13c5226-60cf-4860-bdff-62eb9bae09f4@gmx.de>
On 4/8/25 16:14, Heinrich Schuchardt wrote:
> On 21.03.25 11:25, Michal Simek wrote:
>> The commit cb9ae40a16f0 ("tools: mkfwumdata: add logic to append vendor
>> data to the FWU metadata") added support for adding vendor data to mdata
>> structure but it is not visible anywhere that's why extend fwu command to
>> dump it.
>>
>> Tested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
>> Reviewed-by: Sughosh Ganu <sughosh.ganu@linaro.org>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>> ---
>>
>> Changes in v2:
>> - Extend print message
>> - Cover hexdump dependencies
>>
>> RFC:
>> https://lore.kernel.org/
>> r/75c697a4f819bb5e8649ed658c5a559fb8cd1fd9.1717599342.git.michal.simek@amd.com
>>
>> ---
>> cmd/Kconfig | 1 +
>> cmd/fwu_mdata.c | 25 +++++++++++++++++++++++++
>> 2 files changed, 26 insertions(+)
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index 642cc1116e87..1f8aa2521a8e 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -185,6 +185,7 @@ config CMD_UFETCH
>> config CMD_FWU_METADATA
>> bool "fwu metadata read"
>> depends on FWU_MULTI_BANK_UPDATE
>> + imply HEXDUMP if FWU_MDATA_V2
>> help
>> Command to read the metadata and dump it's contents
>>
>> diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
>> index 9c048d69a131..5b5a2e4d1cda 100644
>> --- a/cmd/fwu_mdata.c
>> +++ b/cmd/fwu_mdata.c
>> @@ -7,6 +7,7 @@
>> #include <dm.h>
>> #include <fwu.h>
>> #include <fwu_mdata.h>
>> +#include <hexdump.h>
>> #include <log.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>> @@ -45,6 +46,30 @@ static void print_mdata(struct fwu_data *data)
>> img_info->accepted == 0x1 ? "yes" : "no");
>> }
>> }
>> +
>> + if (data->version == 2) {
>
> Should this be >= 2 ? Or do we intend to drop custom field support in
> future?
>
>> + struct fwu_mdata *mdata = data->fwu_mdata;
>> + struct fwu_fw_store_desc *desc;
>> + void *end;
>> + u32 diff;
>> +
>> + /*
>> + * fwu_mdata defines only header that's why taking it as array
>> + * which exactly point to image description location
>> + */
>> + desc = (struct fwu_fw_store_desc *)&mdata[1];
>> +
>> + /* Number of entries is taken from for loop - variable i */
>> + end = &desc->img_entry[i];
>> + debug("mdata %p, desc %p, end %p\n", mdata, desc, end);
>> +
>> + diff = data->metadata_size - ((void *)end - (void *)mdata);
>> + if (diff) {
>> + printf("Custom fields covered by CRC len: 0x%x\n", diff);
>
> The print label is a bit hard to understand. Do you mean:
>
> "Length of custom fields in bytes: 0x%x\n"
That's long description of len. But we need to know what actually is shown which
is that custom fields convered by CRC.
>
> Wouldn't print_hex_dump_bytes() already provide an address column
> conveying that information?
Length information is visible via hexdump and no issue to remove it from print
above.
Thanks,
Michal
prev parent reply other threads:[~2025-04-10 7:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 10:25 [PATCH v2] cmd: fwu: Dump custom fields from mdata structure Michal Simek
2025-04-08 8:18 ` Michal Simek
2025-04-08 14:00 ` Tom Rini
2025-04-08 14:14 ` Heinrich Schuchardt
2025-04-10 7:48 ` Michal Simek [this message]
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=bca32b70-0f59-43aa-9ddc-12d0caefacd3@amd.com \
--to=michal.simek@amd.com \
--cc=git@xilinx.com \
--cc=ibai.erkiaga-elorza@amd.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jerome.forissier@linaro.org \
--cc=mkorpershoek@baylibre.com \
--cc=sjg@chromium.org \
--cc=sughosh.ganu@linaro.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox