op-build
op-build copied to clipboard
open-power
Blackbird fails to build pnor with BOOTKERNEL image too large
I got following error when trying to build the firmware with GCC 11.3.0 (buildroot 2023.02-op-build):
ERROR: PnorUtils::checkSpaceConstraints: Image provided (/home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//zImage.epapr) has size (39321600) which is greater than allocated space (19660800) for section=BOOTKERNEL. Aborting! at /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/hostboot_build_images/PnorUtils.pm line 462.
The size is doubled that of the allocated space. I was thinking of increasing the physical size of BOOTKERNEL in the output/build/openpower-pnor-3e9fa97dd8ac5e92de1e71178d41529e6ef9d9f1/p9Layouts/defaultPnorLayout_64.xml but feeling something is not quite right.
So it's seems to me the XZ compression might have not worked as expected or some extra modules that might have occupied the space. The latter I could confirm not the case:
$ ls -lah output/target/lib64/modules/
total 0
drwxr-xr-x. 1 tle tle 38 Sep 17 12:56 .
drwxr-xr-x. 1 tle tle 634 Aug 29 20:13 ..
drwxr-xr-x. 1 tle tle 442 Sep 17 15:47 5.10.194-openpower1
The first hypothesis might be plausible. I've double checked the blackbird config and confirm BR2_LINUX_KERNEL_XZ=y and the kernel flag has set up in accordingly:
build/linux-headers-5.10.194/arch/powerpc/boot/Makefile
248:compressor-$(CONFIG_KERNEL_XZ) := xz
build/linux-headers-5.10.194/arch/powerpc/configs/skiroot_defconfig
1:CONFIG_KERNEL_XZ=y
build/linux-5.10.194/arch/powerpc/configs/skiroot_defconfig
1:CONFIG_KERNEL_XZ=y
build/linux-5.10.194/arch/powerpc/boot/Makefile
248:compressor-$(CONFIG_KERNEL_XZ) := xz
Any suggestion how to troubleshoot this issue? Many thanks
The size is double the allocated space
That is a side effect of the padding logic that runs. There is a dd command that pads up to the space but if it is a single byte too big then it jumps to the next multiplier. You can check the intermediate object sizes to see how close you really are.
As to the reasons for the size increase, the skiboot folks can probably help more with that.
I was thinking of increasing the physical size of BOOTKERNEL
In general that is probably fine. I don't think we're out of space in the layout. But it would be good to understand what is going on first.
@dcrowell77 great thanks for the guidance
That is a side effect of the padding logic that runs. There is a dd command that pads up to the space but if it is a single byte too big then it jumps to the next multiplier. You can check the intermediate object sizes to see how close you really are.
Could you please elaborate further on where the dd padding happens? I dig in the output and find out there are traces related to dd padding as in:
TRACE: cp /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.SECBOOT.temp.bin.ecc /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//SECBOOT.bin
TRACE: /home/tle/Work/op-build/output/host/usr/bin//crtSignedContainer.sh --scratchDir /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch/ --flags 0x80000000 --sign-project-FW-token BOOTKERN --protectedPayload /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//BOOTKERNEL.staged --out /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.BOOTKERNEL.temp.hdr.bin
--> crtSignedContainer.sh: Signing mode: local
--> crtSignedContainer.sh: Using existing cache dir: /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//SIGNTOOL_1694930479, created: Sun Sep 17 04:01:19 PM AEST 2023
--> crtSignedContainer.sh: Creating new cache subdir: /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//SIGNTOOL_1694930479/BOOTKERN
--> crtSignedContainer.sh: Generating signing requests...
--> crtSignedContainer.sh: No signatures available.
--> crtSignedContainer.sh: Container BOOTKERN build completed.
TRACE: dd if=/home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.BOOTKERNEL.temp.hdr.bin of=/home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.BOOTKERNEL.temp.pad.bin ibs=19660800 conv=sync
TRACE: cp /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.BOOTKERNEL.temp.pad.bin /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.BOOTKERNEL.temp.bin.ecc
TRACE: cp /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//rand-3832865813.BOOTKERNEL.temp.bin.ecc /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch//BOOTKERNEL.bin
TRACE: /home/tle/Work/op-build/output/host/usr/bin//crtSignedContainer.sh --scratchDir /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/openpower_pnor_scratch/ --flags 0x80000000 --sign-project-FW-token CAPP --protectedPayload /home/tle/Work/op-build/output/host/powerpc64le-buildroot-linux-gnu/sysroot/ope
Is that the right place^?
Btw, I also find out more interesting information about the zImage.epapr compiled with different GCC versions:
tle@shrimp-paste:~/Work/op-build$ ls -lah /home/tle/Work/op-build/output-gcc-11/images/
total 201M
drwxr-xr-x. 1 tle tle 222 Sep 18 09:32 .
drwxr-xr-x. 1 tle tle 518 Sep 17 23:22 ..
drwxr-xr-x. 1 tle tle 506 Sep 18 09:13 bnx2x
-rwxr-xr-x. 1 tle tle 104K Sep 17 23:29 cappucode.bin
drwxr-xr-x. 1 tle tle 120 Sep 18 09:13 cxgb4
-rwxr-xr-x. 1 tle tle 68K Sep 18 00:05 ima_catalog.bin
-rw-r--r--. 1 tle tle 81M Sep 18 09:31 rootfs.cpio
-rw-r--r--. 1 tle tle 15M Sep 18 09:31 rootfs.cpio.xz
-rw-r--r--. 1 tle tle 83M Sep 18 09:32 rootfs.tar
-rwxr-xr-x. 1 tle tle 2.5M Sep 18 09:17 skiboot.lid
-rw-r--r--. 1 tle tle 509K Sep 18 09:45 skiboot.lid.bin
-rw-r--r--. 1 tle tle 20M Sep 18 09:32 zImage.epapr
tle@shrimp-paste:~/Work/op-build$ ls -lah /home/tle/Work/op-build/output-gcc-8/images/
total 348M
drwxr-xr-x. 1 tle tle 318 Sep 17 01:48 .
drwxr-xr-x. 1 tle tle 474 Sep 17 01:54 ..
-rwxr-xr-x. 1 tle tle 64M Sep 17 01:48 blackbird.pnor
-rwxr-xr-x. 1 tle tle 28M Sep 17 01:48 blackbird.pnor.squashfs.tar
-rwxr-xr-x. 1 tle tle 104K Sep 17 00:58 cappucode.bin
-rw-r--r--. 1 tle tle 80M Sep 17 01:48 host_fw_debug.tar
-rwxr-xr-x. 1 tle tle 68K Sep 17 01:34 ima_catalog.bin
-rw-r--r--. 1 tle tle 72M Sep 17 01:32 rootfs.cpio
-rw-r--r--. 1 tle tle 13M Sep 17 01:33 rootfs.cpio.xz
-rw-r--r--. 1 tle tle 73M Sep 17 01:34 rootfs.tar
-rwxr-xr-x. 1 tle tle 2.5M Sep 17 00:58 skiboot.lid
-rw-r--r--. 1 tle tle 509K Sep 17 01:47 skiboot.lid.bin
-rw-r--r--. 1 tle tle 17M Sep 17 01:34 zImage.epapr
tle@shrimp-paste:~/Work/op-build$ ls -lah /home/tle/Work/op-build/output-gcc-9/images/
total 349M
drwxr-xr-x. 1 tle tle 318 Sep 17 10:18 .
drwxr-xr-x. 1 tle tle 452 Sep 17 01:54 ..
-rwxr-xr-x. 1 tle tle 64M Sep 17 10:18 blackbird.pnor
-rwxr-xr-x. 1 tle tle 28M Sep 17 10:18 blackbird.pnor.squashfs.tar
-rwxr-xr-x. 1 tle tle 104K Sep 17 02:23 cappucode.bin
-rw-r--r--. 1 tle tle 80M Sep 17 10:18 host_fw_debug.tar
-rwxr-xr-x. 1 tle tle 68K Sep 17 02:58 ima_catalog.bin
-rw-r--r--. 1 tle tle 72M Sep 17 10:04 rootfs.cpio
-rw-r--r--. 1 tle tle 13M Sep 17 10:05 rootfs.cpio.xz
-rw-r--r--. 1 tle tle 74M Sep 17 10:06 rootfs.tar
-rwxr-xr-x. 1 tle tle 2.5M Sep 17 02:23 skiboot.lid
-rw-r--r--. 1 tle tle 509K Sep 17 10:18 skiboot.lid.bin
-rw-r--r--. 1 tle tle 17M Sep 17 10:06 zImage.epapr
as you could see GCC 8 and 9 produces 17MiB zImage.epar whilst GCC 11 produces a 20MiB. I am going to try to compare the content of rootfs.tar to see what are responsible for the 3MiB
Yes, you found the place, specifically it is the "ibs=19660800" option. This is all part of the scripts under openpower-pnor.