tools/mkimage: dumpimage rejects valid legacy uImages after custom magic patch #25287

Describe the bug

Hi!

While working with the OpenWrt image tools I noticed that the OpenWrt-built dumpimage rejects valid legacy uImages, even though the matching mkimage binary reads the same image correctly

I tracked this down to tools/mkimage/patches/030-allow-to-use-different-magic.patch

The patch adds a magic field to struct image_tool_params and changes the legacy uImage check in tools/default_image.c from:

if (be32_to_cpu(hdr->ih_magic) != IH_MAGIC)

to:

if (be32_to_cpu(hdr->ih_magic) != params->magic)

mkimage.c initializes it correctly:

static struct image_tool_params params = {
    ...
    .magic = IH_MAGIC,
};

but dumpimage.c still has:

static struct image_tool_params params;

so params.magic stays zero

OpenWrt version

r36385-c1111ed5d6

OpenWrt release

SNAPSHOT

OpenWrt target/subtarget

ramips/mt7621

Device

TP-Link Archer MR500 v1 (EU)

Image kind

Self-built image

Steps to reproduce

I noticed this while testing the OpenWrt host image tools on a locally built ramips/mt7621 image.

The extracted kernel is a valid legacy uImage. Its magic, header CRC and data CRC were also verified independently.

Using the OpenWrt-built U-Boot 2026.07 host tools:

mkimage -l kernel.bin
mkimage -T kernel -l kernel.bin

Both commands succeed

Then run:

dumpimage -l kernel.bin

and:

dumpimage -T kernel -l kernel.bin

The issue is reproducible after a clean rebuild of the OpenWrt tools/mkimage host package as well

Actual behaviour

mkimage accepts the image and reports:

Image Name:   MIPS OpenWrt Linux-6.18.52
Image Type:   MIPS Linux Kernel Image (lzma compressed)
Data Size:    3561279 Bytes
Load Address: 80001000
Entry Point:  80001000

However, dumpimage -l kernel.bin fails with:

Truncated file
dumpimage: cannot detect image type

and forcing the image type:

dumpimage -T kernel -l kernel.bin

fails with:

dumpimage: verify_header failed for Default Image support with exit code -9

-9 corresponds to FDT_ERR_BADMAGIC

Expected behaviour

dumpimage should accept the same valid legacy uImage that mkimage accepts

It should also be possible to extract the payload successfully with:

dumpimage -T kernel -p 0 -o payload kernel.bin

Additional info

Tested with:

OpenWrt revision: c1111ed5d69678613b7a47aa76f8e6209f0da56d
U-Boot host tools: 2026.07
Host: x86_64 Linux

The test image was independently checked and has:

magic:       0x27051956
header CRC:  valid
data CRC:    valid
payload:     3561279 bytes

I also verified that the kernel extracted from the firmware is byte-for-byte identical to the kernel artifact produced by the OpenWrt build.

The issue was reproduced again after cleaning and rebuilding the OpenWrt U-Boot host tools, so it does not appear to be caused by a stale binary.

The apparent cause is the OpenWrt custom-magic patch.

tools/default_image.c checks:

if (be32_to_cpu(hdr->ih_magic) != params->magic)

but dumpimage.c leaves params.magic uninitialized, while mkimage.c initializes it to IH_MAGIC.

As a test, I changed the declaration in dumpimage.c to:

static struct image_tool_params params = {
    .magic = IH_MAGIC,
};

and rebuilt the same U-Boot host tools.

After that, all of these commands succeeded:

dumpimage -T kernel -l kernel.bin                -> OK
dumpimage -T kernel -p 0 -o payload kernel.bin  -> OK
dumpimage -l kernel.bin                          -> OK

The extracted payload was exactly 3561279 bytes, matching the uImage header.

After testing, I restored the original source and rebuilt again, confirming that the original dumpimage behaviour returned

Diffconfig

CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt7621=y
CONFIG_TARGET_ramips_mt7621_DEVICE_tplink_mr500-v1-eu=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_CCACHE_DIR="/home/max/.cache/openwrt-ccache"
CONFIG_DEFAULT_kmod-usb-net-rndis=y
# CONFIG_FEED_luci is not set
# CONFIG_FEED_packages is not set
# CONFIG_FEED_routing is not set
# CONFIG_FEED_telephony is not set
# CONFIG_FEED_video is not set
CONFIG_PACKAGE_kmod-usb-net-rndis=y

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.