Linux kernel/Image Size

From Yocto Project
Jump to: navigation, search



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 on a reasonably fully featured target board, such as the Intel n450 Embedded Development board. The uncompressed kernel image should come in around 1.5MB. Changes to the kernel shall not impact POSIX compliance. In addition to an example small BSP, a document shall be published describing how to apply the work done here to an arbitrary BSP.

This project is focused on the kernel image. A related project, the goal of which is to reduce the size of the entire image including the root filesystem, is documented as Minimal_Image.


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"

Note that small will not address hardware configurations, but will instead address kernel features (such as tracing, networking, filesystems, IO schedulers, etc.) and kernel build options (printk, hash table sizes, etc.). Any hardware enabling must be done the BSP. BSPs may provide small variants as well to disable hardware features. In keeping with the goals of the [/Linux_Kernel/Boot_Time:Boot Time] effort, the kernel image must have all required hardware support for boot built-in.

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. As a rule of thumb, new configuration options must save more than 4k to be worth the added infrastructure. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.

Initial development and prototyping will be completed using the qemux86 machine. Once a minimal general purpose config has been identified, further refinement will be done on the n450 machine. Finally, the general purpose small variant should be demonstrated to function on each of the four platforms defined in meta-yocto. Additionally, each of the machines defined in the meta-intel layer will be verified. Support for additional boards will require additional resources from interested parties.

The links listed under Resources provide a good set of tasks to get started with as well as some background context. After working through that, a second round of image size reduction may need to be planned.

Next Steps

  • Start with allnoconfig and get a minimal config booting on qemux86
  • Determine the delta between this config and the yocto/standard config
  • Work this delta into the "small" variant
  • Modify this config to allow the n450 to boot
  • Determine ways to minimize the image for the n450
  • Create optional small variants
  • Possibly M3 items
    • Verify small variant works on all four meta-yocto defined machines
    • Verify small variant works on all meta-intel defined machines



Initial qemux86 (2163461ec94528ecf046a04edc5db3d2dd3a6b8b)

$ ls -la arch/x86/boot/bzImage
-rw-rw-r-- 1 dvhart dvhart 4111664 2011-06-22 16:48 arch/x86/boot/bzImage

$ ls -la vmlinux
-rwxrwxr-x 1 dvhart dvhart 143686262 2011-06-22 16:47 vmlinux

$ size vmlinux
   text    data     bss     dec     hex filename
7261405  779724 1603032 9644161  932881 vmlinux
Personal tools