Bug 12411 - Kernel zImage is actually a uImage
Summary: Kernel zImage is actually a uImage
Status: RESOLVED INVALID
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2019.08.2
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-16 14:53 UTC by Bradley Gamble
Modified: 2019-12-17 15:38 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bradley Gamble 2019-12-16 14:53:01 UTC
I am currently building the Linux kernel with Buildroot and have been outputting a working, bootable uImage file without issue.
A snippet of my config file:

    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_CUSTOM_VERSION=y
    BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.1.9"
    BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
    BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/board/linux-config/platform_defconfig"
    BR2_LINUX_KERNEL_DTS_SUPPORT=y
    BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="$(BR2_EXTERNAL)/board/device-tree/platform.dts"

I wanted to instead output a zImage file. I added the following line to the config:
    BR2_LINUX_KERNEL_ZIMAGE=y

After a full rebuild (for snity) a zImage file is output to the "./output/images/" directory, however the file is not actually a zImage:
    $ file zImage 
    zImage: u-boot legacy uImage, Linux-5.1.9, Linux/PowerPC, OS Kernel Image (gzip), 4304978 bytes, Mon Dec 16 14:39:07 2019, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0x43D672C7, Data CRC: 0x4FF108C3

I am able to manually truncate the first 64 bytes which will give me a working zImage file, however I expected Buildroot to give me an actual zImage file, not requiring any manual modification.
Comment 1 Thomas Petazzoni 2019-12-16 15:28:51 UTC
Thanks for your bug report! Could you provide some simple Buildroot configuration that we can actually build that reproduces the issue ?

Indeed, I just built the following configuration:

BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2019.05.1.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_4_9=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v5"
# BR2_PACKAGE_BUSYBOX is not set
# BR2_TARGET_ROOTFS_TAR is not set

And it does produce a zImage, as expected:

$ file output/images/zImage 
output/images/zImage: Linux kernel ARM boot executable zImage (little-endian)

But it seems like your issue is on PowerPC. So I suspect PowerPC produces a uImage by default, and then we copy it to zImage. Again, if you could provide a Buildroot configuration that we can build, to reproduce and fix the problem, that would be very useful. Thanks!
Comment 2 Bradley Gamble 2019-12-17 15:38:59 UTC
Looks like this is actually a bug specific to the Linux kernel rather than Buildroot - I've created a separate a bug in their Bugzilla stream with more details.
https://bugzilla.kernel.org/show_bug.cgi?id=205889