| Summary: | The size of the kernel image is too big | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Lisandro Damián Nicanor Pérez Meyer <perezmeyer> |
| Component: | meta-yocto | Assignee: | Michel Thebeau <michel.thebeau> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Medium+ | CC: | bruce.ashfield, dvhart, michel.thebeau, poky.bs.watcher, poky.watcher, richard.purdie, sgw |
| Version: | 1.3 | ||
| Target Milestone: | 1.4 M6 | ||
| Hardware: | Routerstationpro | ||
| OS: | mips | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Lisandro Damián Nicanor Pérez Meyer
2012-11-29 20:32:16 UTC
Some more test I did: - I modified the recipes to get the latest HEAD from the kernel repo, branch standard/routerstationpro. The result keeps being a huge image. - I cloned the aforementioned git repo, same branch, but in the commit used by default. Then I got the .config file from the work dir and rebuilt the kernel under a Debian mips chroot. Same result. I am now going to try using the .config file from denzil, do make oldconfig and build. I'll do it on the Debian chroot because I don't now how to modify the .config file from the recipes. I'll do some build tests here as well, I'm just struggling with some binutils build issues at the moment. Hi Bruce! Don't worry, please do continue with the binutils stuff :-) In the meantime I tested using the .config file from denzil, do make oldconfig and build inside the Debian chroot with qemu. I've got a 6.7 MB kernel, which is not bad. I haven't tested it yet, but at least I think it helps in seeing where the problem could be. Kinds regards, Lisandro. The .config angle might also be a bit of a wrong path, since the kernel version change between the branches would impact the default image, as would any BSP machine.conf changes. The kernel configuration is one angle (it's actually much better in the 3.4 BSP), but it could be more of a matter of the default MIPS kernel images are not stripped. > ll -h vmlinux-3.4.18+git34+8b0a93c0a224c9b91f90545b123b055b2e313bfc_2+574953480e9c2b2e1840297473c67bfe05a7b997-r4.3-routerstationpro-20121130135334.bin-orig -rw-r--r-- 1 bruce bruce 86M Nov 30 11:12 vmlinux-3.4.18+git34+8b0a93c0a224c9b91f90545b123b055b2e313bfc_2+574953480e9c2b2e1840297473c67bfe05a7b997-r4.3-routerstationpro-20121130135334.bin-orig > ../../../tmp/sysroots/x86_64-linux/usr/bin/mips32-poky-linux/mips-poky-linux-strip -s -R .comment vmlinux-3.4.18+git34+8b0a93c0a224c9b91f90545b123b055b2e313bfc_2+574953480e9c2b2e1840297473c67bfe05a7b997-r4.3-routerstationpro-20121130135334.bin-orig > ll -h vmlinux-3.4.18+git34+8b0a93c0a224c9b91f90545b123b055b2e313bfc_2+574953480e9c2b2e1840297473c67bfe05a7b997-r4.3-routerstationpro-20121130135334.bin-orig -rw-r--r-- 1 bruce bruce 8.0M Nov 30 11:14 vmlinux-3.4.18+git34+8b0a93c0a224c9b91f90545b123b055b2e313bfc_2+574953480e9c2b2e1840297473c67bfe05a7b997-r4.3-routerstationpro-20121130135334.bin-orig And we have a kernel image that is consistent with the rest of the builds. My routerstation pro isn't available right now, so I have no idea if this is bootable. But if we can confirm that this is still bootable, the BSP config can switch to vmlinux.strip as the default. Can we try a boot with a stripped vmlinux ? Sure, I'll try it in a few minutes! Boots perfectly. I think it would be nice to have the stripped image then :) Thanks for the test. I'll make this the default. Is this now in progress? Is it done? Thanks for the ping .. this is in progress. Changing the state. switching the default to the stripped image is not quite as simple as it first looked. patches accepted for the fix, but for now, I'm bumping this out to M4. Bruce, is this perhaps an M5? missed this one in my bumping of defects. I'll shoot for M5, but cycles may get in the way again. The status is still correct, and I'm still looking for the least impact/cleanest way to make this change be something that is out of the box with no extra steps. I'm looking for someone to complete this bug, the assignee should change once they've been found. I just realized that I misread the size of vmlinux.bin in arch/mips/boot/. The source code supports that this is the stripped vmlinux that this defect is looking for. 8337264 2013-03-21 16:36 vmlinux.bin Does that sound right? M It does sound right. So what remains ? Is the stripped image in the boot directory the one that is being linked in the exported directory ? Are we looking at a simple enough change to vmlinux.bin as the image type in the BSP configuration ? If that's it, there may well be some associated changes to the build, since the image type triggers different processing and is passed to the kernel build indirectly. What you said Bruce. I'm testing the following:
--- a/meta-yocto-bsp/conf/machine/routerstationpro.conf
+++ b/meta-yocto-bsp/conf/machine/routerstationpro.conf
@@ -6,8 +6,8 @@ require conf/machine/include/tune-mips32.inc
MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 serial"
-KERNEL_IMAGETYPE = "vmlinux"
-KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
+KERNEL_ALT_IMAGETYPE = "vmlinux"
+KERNEL_IMAGETYPE = "vmlinux.bin"
This carries vmlinux.bin into the deploy/images dir, instead of vmlinux.
It looks safe for kernel, because the image types get passed to linux like this:
kernel_do_compile() {
oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
Unless the order of `make vmlinux vmlinux.bin matters`. I don't think it does, but I'm not comfortable with make either.
Here is my test for kernel:
Before:
-rwxr-xr-x 1 mitch users 90230265 2013-03-22 10:23 ./vmlinux
-rwxr-xr-x 1 mitch users 8337264 2013-03-22 10:23 ./arch/mips/boot/vmlinux.bin
After swapping image types:
-rwxr-xr-x 1 mitch users 90230265 2013-03-22 08:58 ./vmlinux
-rwxr-xr-x 1 mitch users 8337264 2013-03-22 08:58 ./arch/mips/boot/vmlinux.bin
> If that's it, there may well be some associated changes to the build
I'll concentrate on what oe is doing for "vmlinux.bin" versus "vmlinux" before I submit another patch.
M
Bruce,
> Is the stripped image in the boot directory the one that is being
> linked in the exported directory ?
After swapping the IMAGETYPE and ALT_IMAGETYPE for rsp the links in tmp/deploy/images/ are correct.
The names get ".bin" added, i.e.; $ ls -l
images/vmlinux.bin-routerstationpro.bin -> vmlinux.bin--3.4.34[...]-routerstationpro-20130322180516.bin
The other observation I have is, after the image type swap, the vmlinux rpm gains the stripped vmlinux.bin while retaining vmlinux. Before versus After:
tmp/deploy/rpm/routerstationpro$ ls -l
--rw-r--r-- 1 mitch users 43395695 kernel-vmlinux-[...].routerstationpro.rpm
+-rw-r--r-- 1 mitch users 46895047 kernel-vmlinux-[...].routerstationpro.rpm
I didn't expect that and I don't have the reason yet.
But looks good so far.
M
I'd noted in email that arch/mips/boot/vmlinux.bin is looks like the stripped file we were looking for. But it doesn't load: RedBoot> load -m tftp -h 192.168.1.6 mthebeau/vmlinux.bin Unrecognized image type: 0x0 I was able to load the larger vmlinux and boot it. And as previously noted by , using tmp/sysroots/x86_64-linux/usr/bin/mips32-poky-linux/mips-poky-linux-strip would get a bootable image as well from the vmlinux. I'll try to figure out what the difference is between that and vmlinux.bin. M |