Bug 205889

Summary: CONFIG_PPC_85xx with CONFIG_CORENET_GENERIC outputs uImage instead of zImage
Product: Platform Specific/Hardware Reporter: Bradley Gamble (bradley.gamble)
Component: PPC-32Assignee: platform_ppc-32
Status: NEW ---    
Severity: normal CC: michael
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.5 Subsystem:
Regression: No Bisected commit-id:

Description Bradley Gamble 2019-12-17 15:37:36 UTC
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
Comment 1 Michael Ellerman 2019-12-18 11:37:03 UTC
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.
Comment 2 Bradley Gamble 2019-12-20 11:55:33 UTC
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.