U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: Jonas Karlman <jonas@kwiboo.se>,
	Kever Yang <kever.yang@rock-chips.com>,
	Simon Glass <sjg@chromium.org>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de
Subject: Re: [PATCH 2/6] rockchip: mkimage: Print image information for all embedded images
Date: Wed, 5 Feb 2025 16:57:14 +0100	[thread overview]
Message-ID: <6827e64d-a7a5-4dfb-9a90-800aa1bd40be@cherry.de> (raw)
In-Reply-To: <20250129223641.1888833-3-jonas@kwiboo.se>

Hi Jonas,

On 1/29/25 11:36 PM, Jonas Karlman wrote:
> The v2 image format can embed up to 4 data files compared to the two
> init and boot data files using the older image format.
> 
> Add support for displaying more of the image header information that
> exists in the v2 image format, e.g. image load address and flag.
> 
> Example for v2 image format:
> 
>    > tools/mkimage -l rk3576_idblock_v1.09.107.img
>    Rockchip Boot Image (v2)
>    Image 1: 4096 @ 0x1000
>    - Load address: 0x3ffc0000
>    Image 2: 77824 @ 0x2000
>    - Load address: 0x3ff81000
>    Image 3: 262144 @ 0x15000
> 
> Example for older image format:
> 
>    > tools/mkimage -l u-boot-rockchip.bin
>    Rockchip RK32 (SD/MMC) Boot Image
>    Init Data: 20480 @ 0x800
>    Boot Data: 112640 @ 0x5800
> 
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
>   tools/rkcommon.c | 41 +++++++++++++++++++++++++++++++----------
>   1 file changed, 31 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
> index de3fd2d3f3c2..ad239917d2bd 100644
> --- 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.

>   	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?

> +			printf("- Load address: 0x%x\n", val);
> +
> +		val = le32_to_cpu(hdr->images[i].flag);
> +		if (val)
> +			printf("- Flag: 0x%x\n", val);

Matter of taste but the dashes were bothering me when parsing the output 
with my eyes, two spaces could work better. In any case, not a big deal 
to me.

> +	}
> +}
> +
>   void rkcommon_print_header(const void *buf, struct image_tool_params *params)
>   {
>   	struct header0_info header0;
> @@ -502,8 +523,7 @@ void rkcommon_print_header(const void *buf, struct image_tool_params *params)
>   			return;
>   		}
>   
> -		init_size = le16_to_cpu(header0_v2.images[0].size) * RK_BLK_SIZE;
> -		boot_size = le16_to_cpu(header0_v2.images[1].size) * RK_BLK_SIZE;
> +		rkcommon_print_header_v2(&header0_v2);
>   	} else {
>   		ret = rkcommon_parse_header(buf, &header0, &spl_info);
>   
> @@ -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.

Looking good otherwise,
Cheers,
Quentin

  reply	other threads:[~2025-02-05 15:57 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 [this message]
2025-02-05 19:36     ` Jonas Karlman
2025-02-06 14:23       ` Quentin Schulz
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=6827e64d-a7a5-4dfb-9a90-800aa1bd40be@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox