kernel image size depends on toolchain?

Its probably one of these "again" questions but I couldn't get a reasonable/sound answer.

I'm building an arm rootfs and an 2.6.23.14 kernel with the actual svn buildroot and uclibc. It works quite well but produces really large kernel images.

Created:      Tue Jun 10 11:45:43 2008
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    4528112 Bytes = 4421.98 kB = 4.32 MB

With an old toolchain I can achive regular sizes:

Created:      Tue Jun 10 13:44:26 2008
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1412792 Bytes = 1379.68 kB = 1.35 MB

Unfortunately, the old toolchain has a buggy uclibc and I need a new one. -- How can I fix that greedy kernel thing ? --

Thanks in advance...
akuehn

Hi,

 Andreas> Created:      Tue Jun 10 11:45:43 2008
 Andreas> Image Type:   ARM Linux Kernel Image (uncompressed)
 Andreas> Data Size:    4528112 Bytes = 4421.98 kB = 4.32 MB

Andreas> With an old toolchain I can achive regular sizes:

 Andreas> Created:      Tue Jun 10 13:44:26 2008
 Andreas> Image Type:   ARM Linux Kernel Image (uncompressed)
 Andreas> Data Size:    1412792 Bytes = 1379.68 kB = 1.35 MB

Strange. And you are sure you're using the exact same kernel config? Do both kernel images boot?

Bye, Peter Korsgaard

That is how I found that thing. It simply doesn't fit into my boot flash anymore.
And Yes, it is the same, not even a copy, .config file for both trys.

The reason why I need the "new" uclibc is, that I need access to the PIOs of my at91sam9261 and at91sam9263 controllers. And the "old" uclibc has this mmap bug that creates an page overflow error.

Is there a chance that something in the uclibc like the LARGEFILESUPPORT creates some static or incompressable data block?

Hi,

Andreas> That is how I found that thing. It simply doesn't fit into my boot Andreas> flash anymore.
Andreas> And Yes, it is the same, not even a copy, .config file for both trys.

Andreas> The reason why I need the "new" uclibc is, that I need access to the Andreas> PIOs of my at91sam9261 and at91sam9263 controllers. And the "old" Andreas> uclibc has this mmap bug that creates an page overflow error.

Andreas> Is there a chance that something in the uclibc like the Andreas> LARGEFILESUPPORT creates some static or incompressable data block?

That doesn't sound likely. Are the vmlinux files also different in sizes? Try comparing output of $CROSS-nm on the vmlinux files.

Bye, Peter Korsgaard

Here it comes...

old actual
-------------------------------------------------------------
linux/System.map 695909 695917

linux/vmlinux                           27876137    27875949
linux/vmlinux.o                         46429585    46507157
linux/arch/arm/boot/Image                2896464  3224138320
linux/arch/arm/boot/uImage               1412856     4528180
linux/arch/arm/boot/compressed/vmlinux   1480207     4594834
linux/arch/arm/boot/compressed/piggy.gz  1397310     4512806

Obviously, the Image file is a little out of shape.
Who created that monster? I take that as a proof that the toolchain hasn't been built properly. -- Any ideas? --

Andreas> Here it comes...
Andreas> old actual
Andreas> -------------------------------------------------------------
Andreas> linux/System.map 695909 695917

 Andreas> linux/vmlinux                           27876137    27875949
 Andreas> linux/vmlinux.o                         46429585    46507157

Andreas> linux/arch/arm/boot/Image 2896464 3224138320

So Image is around 3G. There afaik was a problem in arch/arm about some binutils versions creating huge images because of a new section. What binutils version are you using (old and new)?

Ahh, this seems to be it:

commit 1e621a8e3752367d4aae78a8ab00a18fb2793f34

Author: Lennert Buytenhek <[email protected]>
Date:   Fri Oct 12 14:38:54 2007 +0100

[ARM] 4600/1: fix kernel build failure with build-id-supporting binutils

Newer versions of binutils support --build-id, which adds an ELF note section called ".note.gnu.build-id" to the output. On the ARM kernel build, because there is no explicit mention of this section in the shipped ld script, this section is placed at vaddr 0x00000000 (whereas the normal kernel text/data typically starts at vaddr 0xc0008000), causing the output of objcopy (Image) to produce a 3G+ file.

This patch makes objcopy strip the .note.gnu.build-id section from the Image file along with all other note sections, which fixes the build.

Bye, Peter Korsgaard

Right from the .config file....

BR2_BINUTILS_VERSION="2.18"
BR2_EXTRA_BINUTILS_CONFIG_OPTIONS=""

I suppose version 2.18 is the "old" version?
Meanwhile, I changed to version 2.18.50.0.1 and did a complete rebuild with a well known result:

Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    4528100 Bytes = 4421.97 kB = 4.32 MB

I don't know where that commit you mentioned has gone to (where does that 1e621a8e3752367d4aae78a8ab00a18fb2793f34 belong to). Is it the kernel tree or the binutils and finally which version?

Hi,

Andreas> Right from the .config file....
Andreas> BR2_BINUTILS_VERSION="2.18"
Andreas> BR2_EXTRA_BINUTILS_CONFIG_OPTIONS=""

Andreas> I suppose version 2.18 is the "old" version? Meanwhile, I Andreas> changed to version 2.18.50.0.1 and did a complete rebuild Andreas> with a well known result:

Andreas> Image Type: ARM Linux Kernel Image (uncompressed)
Andreas> Data Size: 4528100 Bytes = 4421.97 kB = 4.32 MB

Andreas> I don't know where that commit you mentioned has gone to Andreas> (where does that 1e621a8e3752367d4aae78a8ab00a18fb2793f34 Andreas> belong to). Is it the kernel tree or the binutils and Andreas> finally which version?

It's from the kernel git tree. It's a simple oneliner, you could maybe patch it by hand in your Linux checkout:

index fa4ea9f..6c2d539 100644
@@ -12,7 +12,7 @@
 
 LDFLAGS_vmlinux        :=-p --no-undefined -X
 CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
-OBJCOPYFLAGS   :=-O binary -R .note -R .comment -S
+OBJCOPYFLAGS   :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
 GZFLAGS                :=-9
 #CFLAGS                +=-pipe
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:

Bye, Peter Korsgaard

Hi Peter!

Strike!

Created:      Wed Jun 11 16:51:42 2008
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1402212 Bytes = 1369.35 kB = 1.34 MB  <--<< Groovy !

You were right, that patch was missing.
Really great support.
Thank you

	akuehn  :-)

Hi,

 Andreas> Created:      Wed Jun 11 16:51:42 2008
 Andreas> Image Type:   ARM Linux Kernel Image (uncompressed)
 Andreas> Data Size:    1402212 Bytes = 1369.35 kB = 1.34 MB  <--<< Groovy !

Great!

Andreas> You were right, that patch was missing.
Andreas> Really great support.
Andreas> Thank you
Andreas> akuehn :-)

You're welcome.

Bye, Peter Korsgaard

Andreas Kuehn, 11.06.2008:

The kernel is not being linked against uClibc, so there is no influence.

Markus

Hi,
Have you tried disabling the initrd stuff in the buildroot config? ~Matt

Hey Matt!

In fact I was a little confused about your question but a found the flag
in the kernels .config file.

# CONFIG_BLK_DEV_INITRD is not set

And so, initrd is not active.