New: CONFIG_PPC_85xx with CONFIG_CORENET_GENERIC outputs uImage instead of zImage

https://bugzilla.kernel.org/show_bug.cgi?id=205889

Bug ID: 205889
Summary: CONFIG_PPC_85xx with CONFIG_CORENET_GENERIC outputs
uImage instead of zImage
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.5
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Attempting a PowerPC Linux kernel build with the config options "CONFIG_PPC_85xx=y" and "CONFIG_CORENET_GENERIC=y" will output a file named "zImage", however this file is actually a "uImage" formatted file.

This can be replicated with this minimal defconfig:

    CONFIG_PPC_85xx=y
    CONFIG_CORENET_GENERIC=y

If I perform a build with one of these options I am given a valid zImage file:

    $ file arch/powerpc/boot/zImage
    arch/powerpc/boot/zImage: ELF 32-bit MSB executable, PowerPC or cisco 4500,
version 1 (SYSV), statically linked, not stripped

However performing the same build with both config options enabled gives an incorrectly formatted image:

    $ file arch/powerpc/boot/zImage
    arch/powerpc/boot/zImage: u-boot legacy uImage, Linux-5.5.0-rc2-gea200dec5,
Linux/PowerPC, OS Kernel Image (gzip), 1366142 bytes, Tue Dec 17 15:30:22 2019,
Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0x99D350A0, Data
CRC: 0xC9090D33

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=205889

Michael Ellerman ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Michael Ellerman ([email protected]) --- I think that's working as designed, if not expected.

CONFIG_CORENET_GENERIC selects CONFIG_DEFAULT_UIMAGE, which tells arch/powerpc/boot/Makefile to build a uImage.

The zImage is just a hardlinkg to the uImage.

You can see that using the -i flag to ls, eg:

$ ls -il arch/powerpc/boot/{uImage,zImage}
1300656 -rw-rw-r-- 2 michael michael 5356164 Dec 18 22:19
arch/powerpc/boot/uImage
1300656 -rw-rw-r-- 2 michael michael 5356164 Dec 18 22:19
arch/powerpc/boot/zImage

Notice the inode is the same, and the link count is 2.

I think the logic behind the link is that people might have scripts to copy zImage somewhere to boot it, and we didn't want to break that just because the target of the build is a uImage.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=205889

--- Comment #2 from Bradley Gamble ([email protected]) --- I understand the desire not to break scripts etc that may be used, but zImage and uImage files are different and may not both be bootable on the same device. I am currently able to work around the issue by stripping the first 64 bytes of the uImage to turn it back in to a zImage.

Is it possible to overcome the implicit link between the platform and enabling CONFIG_DEFAULT_UIMAGE? I have tried marking it as "not set" in my defconfig but it is still enabled.

You are receiving this mail because:
You are watching the assignee of the bug.