Kernel image size
in [Embedded]
|
Prev: Suggested features for CASE to protect shared stores againstconflicting accesses
Next: New Microchip PIC32 Microcontrollers have Lots of Everything (2 CAN 2.0b, Ethernet, lots more)
From: Nobby Anderson on 20 Nov 2009 19:10 I've recently upgraded a ppc405 build for a Virtex 4 device from kernel 2.6.15 (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has increased from about 900k to 1.4M. As far as I can tell I've pretty much the same config options set. The 2.6.15 kernel was straight from the kernel mainline with some xilinx drivers hacked in, the .31 is straight from git.xilinx.com with nothing additional hacked in but does use for example the lltemac driver. Is that the sort of size increase I should expect, or is it likely I'm missing something? It's nearly a 50% increase, which seems excessive! Nobby
From: Didi on 21 Nov 2009 01:53 On Nov 21, 2:10 am, Nobby Anderson <no...(a)invalid.invalid> wrote: > I've recently upgraded a ppc405 build for a Virtex 4 device from kernel 2..6.15 > (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has increased > from about 900k to 1.4M. As far as I can tell I've pretty much the same > config options set. The 2.6.15 kernel was straight from the kernel mainline > with some xilinx drivers hacked in, the .31 is straight from git.xilinx.com > with nothing additional hacked in but does use for example the lltemac > driver. > > Is that the sort of size increase I should expect, or is it likely I'm > missing something? It's nearly a 50% increase, which seems excessive! > > Nobby Not that I can help on this, but I am curious on a related note; what does this kernel do? My DPS (not for the 405, just for 5200B and for the 824x so far) "kernel", dps.syst, contains things up to and including the filesystem - it has to spawn a shell to have command line functionality. dps.syst is 106100 bytes long; shell is apr. 42k. This without windows, graphics and tcp/ip; it takes another apr. 500k to add these. So I am just curious to see what other people do. Dimiter P.S. Here is a new product with the mpc5200b, it runs all of the above and some more: http://tgi-sci.com/tgi/nmcatb.htm . ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
From: Nobby Anderson on 21 Nov 2009 06:28 Didi <dp(a)tgi-sci.com> wrote: > On Nov 21, 2:10�am, Nobby Anderson <no...(a)invalid.invalid> wrote: >> I've recently upgraded a ppc405 build for a Virtex 4 device from kernel 2.6.15 >> (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has increased >> from about 900k to 1.4M. �As far as I can tell I've pretty much the same >> config options set. �The 2.6.15 kernel was straight from the kernel mainline >> with some xilinx drivers hacked in, the .31 is straight from git.xilinx.com >> with nothing additional hacked in but does use for example the lltemac >> driver. >> >> Is that the sort of size increase I should expect, or is it likely I'm >> missing something? �It's nearly a 50% increase, which seems excessive! >> >> Nobby > > Not that I can help on this, but I am curious on a related note; > what does this kernel do? My DPS (not for the 405, just for 5200B and > for the 824x so far) "kernel", dps.syst, contains things up to > and including the filesystem - it has to spawn a shell to have > command line functionality. dps.syst is 106100 bytes long; shell > is apr. 42k. > This without windows, graphics and tcp/ip; it takes another apr. > 500k to add these. > So I am just curious to see what other people do. Not sure I understand what you're getting at - re-reading my post I realise that I failed to mention that it was a Linux kernel which was a bit stupid of me! Anyway, we use Linux on them because it means we can run the same app on small embedded systems up to large fast hardware on a variety of architectures. I'm just curious as to why it's increased 50% in size from the .15 to the ..31 releases and wonder if anyone else has noticed this. Probably not the best group to ask on, but then embedded folk usually care more about size than others. Nobby
From: D Yuniskis on 21 Nov 2009 08:05 Nobby Anderson wrote: > I've recently upgraded a ppc405 build for a Virtex 4 device from kernel 2.6.15 > (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has increased > from about 900k to 1.4M. As far as I can tell I've pretty much the same > config options set. The 2.6.15 kernel was straight from the kernel mainline > with some xilinx drivers hacked in, the .31 is straight from git.xilinx.com > with nothing additional hacked in but does use for example the lltemac > driver. > > Is that the sort of size increase I should expect, or is it likely I'm > missing something? It's nearly a 50% increase, which seems excessive! DEBUG build? Not stripped?
From: Nobody on 21 Nov 2009 13:22
On Fri, 20 Nov 2009 18:10:06 -0600, Nobby Anderson wrote: > I've recently upgraded a ppc405 build for a Virtex 4 device from kernel 2.6.15 > (arch/ppc) to 2.6.31 (arch/powerpc) and the size of the image has increased > from about 900k to 1.4M. As far as I can tell I've pretty much the same > config options set. The 2.6.15 kernel was straight from the kernel mainline > with some xilinx drivers hacked in, the .31 is straight from git.xilinx.com > with nothing additional hacked in but does use for example the lltemac > driver. > > Is that the sort of size increase I should expect, or is it likely I'm > missing something? It's nearly a 50% increase, which seems excessive! A lot has happened between those two: 2.6.15 03-Jan-2006 2.6.15.7 28-Mar-2006 .... 2.6.31 09-Sep-2009 2.6.31.6 10-Nov-2009 Newer kernels occasionally get new features which are enabled by default, and would need to be explicitly disabled. Individual drivers often have tables of known devices, and workarounds for broken hardware. The size of both tends to increase over time. Compilation options can make a lot of difference. An kernel built for embedded use probably won't use the default switches. If you're building these kernels from source, you can examine the number and size of the object files which are built. More files tends to indicate more features (drivers, modules), consistently larger files would indicate compilation switches, inconsistently larger files would indicate specific components acquiring new features. |