[Buildroot] kernel image size depends on toolchain?

[Buildroot] kernel image size depends on toolchain?

[Andreas Kuehn]

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

[Buildroot] kernel image size depends on toolchain?

[Peter Korsgaard]

>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:

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

[Buildroot] kernel image size depends on toolchain?

[Matthew Dombroski]

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

On Wed, Jun 11, 2008 at 7:40 PM, Andreas Kuehn <Andreas.Kuehn@gin.de> wrote:
> 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
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>

[Buildroot] kernel image size depends on toolchain?

[Andreas Kuehn]

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?



Peter Korsgaard wrote:
>>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:
> 
> 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?
> 

[Buildroot] kernel image size depends on toolchain?

[Andreas Kuehn]

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.



Matthew Dombroski wrote:
> Hi,
> Have you tried disabling the initrd stuff in the buildroot config?
> ~Matt
> 
> On Wed, Jun 11, 2008 at 7:40 PM, Andreas Kuehn <Andreas.Kuehn@gin.de> wrote:
>> 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
>> _______________________________________________
>> buildroot mailing list
>> buildroot at uclibc.org
>> http://busybox.net/mailman/listinfo/buildroot
>>
> 

[Buildroot] kernel image size depends on toolchain?

[Peter Korsgaard]

>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:

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

[Buildroot] kernel image size depends on toolchain?

[Andreas Kuehn]

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? --




Peter Korsgaard wrote:
>>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:
> 
> 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.
> 

[Buildroot] kernel image size depends on toolchain?

[Peter Korsgaard]

>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:

 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 <buytenh@wantstofly.org>
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.
    
    Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

-- 
Bye, Peter Korsgaard

[Buildroot] kernel image size depends on toolchain?

[Andreas Kuehn]

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?






Peter Korsgaard wrote:
>>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:
> 
>  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 <buytenh@wantstofly.org>
> 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.
>     
>     Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
>     Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 

[Buildroot] kernel image size depends on toolchain?

[Peter Korsgaard]

>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:

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:

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fa4ea9f..6c2d539 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -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

[Buildroot] kernel image size depends on toolchain? -Solved-

[Andreas Kuehn]

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  :-)




Peter Korsgaard wrote:
>>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:
> 
> 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:
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index fa4ea9f..6c2d539 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -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:
> 

[Buildroot] kernel image size depends on toolchain? -Solved-

[Peter Korsgaard]

>>>>> "Andreas" == Andreas Kuehn <Andreas.Kuehn@gin.de> writes:

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

[Buildroot] kernel image size depends on toolchain?

[Markus Heidelberg]

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

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

Markus