Skip to contentSkip to conversation

New: Kernel zImage is actually a uImage

Buildroot bugzilla at busybox.net 1 participant 3 messages Dec 16, 2019 – Dec 17, 2019

lore
Share & tools
lore
#0 lore raw

https://bugs.busybox.net/show_bug.cgi?id=12411

Bug ID: 12411
Summary: Kernel zImage is actually a uImage
Product: buildroot
Version: 2019.08.2
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: bradley.gamble at ncipher.com
CC: buildroot at uclibc.org
Target Milestone: ---

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.

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#1 lore raw

[Buildroot] [Bug 12411] Kernel zImage is actually a uImage

https://bugs.busybox.net/show_bug.cgi?id=12411

--- Comment #1 from Thomas Petazzoni <[email protected]> --- 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!

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#2 lore raw

[Buildroot] [Bug 12411] Kernel zImage is actually a uImage

In reply to bugzilla at busybox.net

https://bugs.busybox.net/show_bug.cgi?id=12411

Bradley Gamble <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #2 from Bradley Gamble <[email protected]> --- 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

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.