Linux kernel/Image Size: Difference between revisions
(→Vision) |
(→Design) |
||
| Line 3: | Line 3: | ||
== Design == | == Design == | ||
The majority of the work here will center around CONFIG options. There is a start of a kernel type variant already in the linux-yocto tree, called "small" which modifies the CONFIG for a smaller image. The output of this effort will mostly modify that mechanism. Major optional parameters, like disabling the block layer perhaps, will be created as peers to the "small" mechanism. These can be enabled in the recipe itself via: | |||
<pre> | |||
KERNEL_FEATURES += "small noblock" | |||
</pre> | |||
The approach will be to minimize the image as far as possible with existing infrastructure without creating very specialized hacks that must be continually maintained outside of mainline. If it turns out that we can make significant improvements to the sources or the configuration of the kernel to reduce image size, that development will be performed upstream-first, in the usual fashion. | |||
== Resources == | == Resources == | ||
* http://elinux.org/Kernel_Size_Tuning_Guide | * http://elinux.org/Kernel_Size_Tuning_Guide | ||
Revision as of 20:23, 22 June 2011
Vision
Reduce the flash and memory footprint of the linux-yocto generated kernel to boot with 8MB of memory and allow for a minimal image in under 8MB of flash. The uncompressed kernel image should come in around 1.5MB. Changes to the kernel shall not impact POSIX compliance.
Design
The majority of the work here will center around CONFIG options. There is a start of a kernel type variant already in the linux-yocto tree, called "small" which modifies the CONFIG for a smaller image. The output of this effort will mostly modify that mechanism. Major optional parameters, like disabling the block layer perhaps, will be created as peers to the "small" mechanism. These can be enabled in the recipe itself via:
KERNEL_FEATURES += "small noblock"
The approach will be to minimize the image as far as possible with existing infrastructure without creating very specialized hacks that must be continually maintained outside of mainline. If it turns out that we can make significant improvements to the sources or the configuration of the kernel to reduce image size, that development will be performed upstream-first, in the usual fashion.
Resources
- http://elinux.org/Kernel_Size_Tuning_Guide
- http://elinux.org/Kernel_Size_Tuning_Guide_Config_Option_Impact
- http://elinux.org/System_Size
- http://elinux.org/Linux_Tiny
Results
Initial Beagleboard (refresh v2 21-Jun-2011)
$ ls -la ./arch/arm/boot/uImage -rw-rw-r-- 1 dvhart dvhart 2738416 2011-06-20 23:19 ./arch/arm/boot/uImage $ size ./arch/arm/boot/vmlinux text data bss dec hex filename 5527685 338944 272776 6139405 5dae0d ./arch/arm/boot/vmlinux
