Hi Jonas,
On 2026-07-13T10:02:41, Alexey Charkov <[email protected]> wrote:
> rockchip: mkimage: Print image information for all embedded images
>
> 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/rkcommon.c | 41 +++++++++++++++++++++++++++++++----------
> 1 file changed, 31 insertions(+), 10 deletions(-)
> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
> @@ -505,6 +503,29 @@ int rkcommon_verify_header(unsigned char *buf, int size,
> + for (i = 0; i < le16_to_cpu(hdr->num_images); i++) {
rkcommon_parse_header_v2() only checks the magic, so num_images comes
straight from the file and can be anything up to 65535, meaning this
loop can read well past the 4-entry images array for a malformed image.
Please can you clamp the loop bound to ARRAY_SIZE(hdr->images), as the
boot0/boot1 loops in patch 3 do?
> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
> @@ -505,6 +503,29 @@ int rkcommon_verify_header(unsigned char *buf, int size,
> + printf("Image %u: %u @ 0x%x\n",
> + le32_to_cpu(hdr->images[i].counter),
Just to check, is counter guaranteed to be set by all tools that
produce these images? It is documented as 'no use' in patch 1, so a
header with counter left at zero would list every image as 'Image 0'.
Printing i + 1 would be more robust, unless the vendor tools rely on
this field.
> diff --git a/tools/rkcommon.c b/tools/rkcommon.c
> @@ -540,15 +560,16 @@ void rkcommon_print_header(const void *buf, struct
> image_tool_params *params)
> + printf("Init Data: %d @ 0x%x\n", init_size,
> + le16_to_cpu(header0.init_offset) * RK_BLK_SIZE);
For IH_TYPE_RKSPI the data does not live at this flat offset in the
file - rkcommon_parse_header() has to use rkcommon_offset_to_spi() to
find it due to the 2K-in-4K padding. Since the image type is printed as
SD/MMC or SPI just above, should these offsets (and Boot Data below) be
passed through rkcommon_offset_to_spi() in the SPI case, so they match
the file layout? What do you think?
Regards,
Simon
