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-32 | Assignee: | 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
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. 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. |