U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


      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