From: Quentin Schulz <quentin.schulz@cherry.de>
To: Jonas Karlman <jonas@kwiboo.se>
Cc: Kever Yang <kever.yang@rock-chips.com>,
Simon Glass <sjg@chromium.org>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
Tom Rini <trini@konsulko.com>,
u-boot@lists.denx.de
Subject: Re: [PATCH 2/6] rockchip: mkimage: Print image information for all embedded images
Date: Thu, 6 Feb 2025 15:23:15 +0100 [thread overview]
Message-ID: <e607e512-4443-4f2b-b67e-fb42ec496e96@cherry.de> (raw)
In-Reply-To: <5caa2b45-ce86-44f2-aced-ff6df88f1635@kwiboo.se>
Hi Jonas,
On 2/5/25 8:36 PM, Jonas Karlman wrote:
> Hi Quentin,
>
> On 2025-02-05 16:57, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 1/29/25 11:36 PM, Jonas Karlman wrote:
[...]
>>> --- a/tools/rkcommon.c
>>> +++ b/tools/rkcommon.c
>>> @@ -331,8 +331,6 @@ static void rkcommon_set_header0_v2(void *buf, struct image_tool_params *params)
>>> uint8_t *image_ptr = NULL;
>>> int i;
>>>
>>> - printf("Image Type: Rockchip %s boot image\n",
>>> - rkcommon_get_spl_hdr(params));
>>
>> Not sure this change is related? It's also not replaced by anything if
>> I'm not mistaken, hence why I'm wondering why it's in this patch.
>
> Following was meant as a replacement for this, in rkcommon_print_header_v2():
>
> printf("Rockchip Boot Image (v2)\n");
>
> The old printf() was incorrectly done at set_header, not in print_header,
> that is called after set_header or when you try to "mkimage -l <file>".
>
Ah, I see, thanks.
So this is a bugfix because it doesn't show with mkimage -l, separate
commit then.
>>
>>> memset(buf, '\0', RK_INIT_OFFSET * RK_BLK_SIZE);
>>> hdr->magic = cpu_to_le32(RK_MAGIC_V2);
>>> hdr->boot_flag = cpu_to_le32(HASH_SHA256);
>>> @@ -486,6 +484,29 @@ int rkcommon_verify_header(unsigned char *buf, int size,
>>> return -ENOENT;
>>> }
>>>
>>> +static void rkcommon_print_header_v2(const struct header0_info_v2 *hdr)
>>> +{
>>> + uint32_t val;
>>> + int i;
>>> +
>>> + printf("Rockchip Boot Image (v2)\n");
>>> +
>>> + for (i = 0; i < le16_to_cpu(hdr->num_images); i++) {
>>> + printf("Image %u: %u @ 0x%x\n",
>>> + le32_to_cpu(hdr->images[i].counter),
>>> + le16_to_cpu(hdr->images[i].size) * RK_BLK_SIZE,
>>> + le16_to_cpu(hdr->images[i].offset) * RK_BLK_SIZE);
>>> +
>>> + val = le32_to_cpu(hdr->images[i].address);
>>> + if (val != 0xFFFFFFFF)
>>
>> Can you explain why this value is explicitly excluded? I know this is
>> the 4GiB boundary but why does it matter?
>
> It is used as the default value, unknown why, see:
>
> @address: load address (default as 0xFFFFFFFF)
>
> Can probably add a code comment here as well.
>
Or maybe a constant to highlight the relation between both. Though one
would need to give it an appropriate name... Here comes the most
difficult part of SW development.
[...]
>>> @@ -521,15 +541,16 @@ void rkcommon_print_header(const void *buf, struct image_tool_params *params)
>>> boot_size = le16_to_cpu(header0.init_boot_size) * RK_BLK_SIZE -
>>> init_size;
>>>
>>> - printf("Image Type: Rockchip %s (%s) boot image\n",
>>> - spl_info->spl_hdr,
>>> + printf("Rockchip %s (%s) Boot Image\n", spl_info->spl_hdr,
>>> (image_type == IH_TYPE_RKSD) ? "SD/MMC" : "SPI");
>>
>> Please keep "Image Type:" this is what's used for other SoC vendors
>> also, I assume some tooling could be parsing it.
>
> Sure, will restore the "Image Type:" prefix here and for "Rockchip Boot
> Image (v2)" above. Should probably also adjust "tools: mkimage: Add
> Amlogic Boot Image type" [1] to do the same.
>
Could even have another callback e.g. get_image_type() which returns a
const char* to print after "Image Type: " and move that to
tools/mkimage.c to have consistent behavior for that part. Probably
over-engineering this though :) (I think we'd need to update imagetool too).
Cheers,
Quentin
next prev parent reply other threads:[~2025-02-06 14:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 22:36 [PATCH 0/6] rockchip: mkimage: Improve support for v2 image format Jonas Karlman
2025-01-29 22:36 ` [PATCH 1/6] rockchip: mkimage: Split size_and_off and size_and_nimage Jonas Karlman
2025-02-05 15:40 ` Quentin Schulz
2025-02-05 18:50 ` Jonas Karlman
2025-01-29 22:36 ` [PATCH 2/6] rockchip: mkimage: Print image information for all embedded images Jonas Karlman
2025-02-05 15:57 ` Quentin Schulz
2025-02-05 19:36 ` Jonas Karlman
2025-02-06 14:23 ` Quentin Schulz [this message]
2025-01-29 22:36 ` [PATCH 3/6] rockchip: mkimage: Print boot0 and boot1 parameters Jonas Karlman
2025-02-05 16:04 ` Quentin Schulz
2025-02-05 16:42 ` Jonas Karlman
2025-02-05 16:48 ` Quentin Schulz
2025-02-05 19:15 ` Jonas Karlman
2025-01-29 22:36 ` [PATCH 4/6] rockchip: mkimage: Add option to change image offset alignment Jonas Karlman
2025-02-05 16:29 ` Quentin Schulz
2025-02-05 16:58 ` Jonas Karlman
2025-01-29 22:36 ` [PATCH 5/6] rockchip: mkimage: Add support for up to 4 input files Jonas Karlman
2025-02-05 16:43 ` Quentin Schulz
2025-02-05 19:00 ` Jonas Karlman
2025-02-06 14:36 ` Quentin Schulz
2025-01-29 22:36 ` [PATCH 6/6] rockchip: mkimage: Add option for image load address and flag Jonas Karlman
2025-02-05 16:51 ` Quentin Schulz
2025-02-05 19:54 ` Jonas Karlman
2025-02-06 14:30 ` Quentin Schulz
2025-05-06 7:38 ` [PATCH 0/6] rockchip: mkimage: Improve support for v2 image format Kever Yang
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=e607e512-4443-4f2b-b67e-fb42ec496e96@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=jonas@kwiboo.se \
--cc=kever.yang@rock-chips.com \
--cc=philipp.tomsich@vrull.eu \
--cc=sjg@chromium.org \
--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.