Linux kernel/Image Size - Revision history

Dvhart: /* Vision */

2011-06-27T21:53:05Z

Vision

← Older revision		Revision as of 21:53, 27 June 2011
Line 1:		Line 1:
	== Vision ==		== 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 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.		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]].

	== Design ==		== Design ==

Dvhart: /* Design */

2011-06-23T18:53:11Z

Design

← Older revision		Revision as of 18:53, 23 June 2011
Line 10:		Line 10:
	Note that <code>small</code> 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 <code>small</code> 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.		Note that <code>small</code> 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 <code>small</code> 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. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.		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 <code>small</code> 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.		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 <code>small</code> 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.

Dvhart: /* Vision */

2011-06-23T18:48:23Z

Vision

← Older revision		Revision as of 18:48, 23 June 2011
Line 1:		Line 1:
	== Vision ==		== 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 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.		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.

	== Design ==		== Design ==

Dvhart: /* Design */

2011-06-23T18:43:26Z

Design

← Older revision		Revision as of 18:43, 23 June 2011
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 <code>small</code> mechanism. These can be enabled in the recipe itself via:		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 <code>small</code> 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 <code>small</code> mechanism. These can be enabled in the recipe itself via:
	<pre>		<pre>
	KERNEL_FEATURES += "small noblock"		KERNEL_FEATURES += "small noblock"
Line 12:		Line 12:
	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. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.		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. 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.		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 <code>small</code> 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.		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.

Dvhart: /* Design */

2011-06-23T18:42:33Z

Design

← Older revision		Revision as of 18:42, 23 June 2011
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:		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 <code>small</code> mechanism. These can be enabled in the recipe itself via:
	<pre>		<pre>
	KERNEL_FEATURES += "small noblock"		KERNEL_FEATURES += "small noblock"
	</pre>		</pre>

			Note that <code>small</code> 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 <code>small</code> 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. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.		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. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.

Dvhart: /* Initial Beagleboard (refresh v2 21-Jun-2011) */

2011-06-23T00:00:52Z

Initial Beagleboard (refresh v2 21-Jun-2011)

← Older revision		Revision as of 00:00, 23 June 2011
Line 32:		Line 32:

	== Results ==		== Results ==
	=== Initial ~~Beagleboard~~ (~~refresh v2 21-Jun-2011~~) ===		=== Initial qemux86 (2163461ec94528ecf046a04edc5db3d2dd3a6b8b) ===
	<pre>		<pre>
	$ ls -la ./arch/~~arm~~/boot/~~uImage~~		$ ls -la arch/x86/boot/bzImage
	-rw-rw-r-- 1 dvhart dvhart ~~2738416~~ 2011-06-~~20 23~~:~~19 ./~~arch/~~arm~~/boot/~~uImage~~		-rw-rw-r-- 1 dvhart dvhart 4111664 2011-06-22 16:48 arch/x86/boot/bzImage

	$ size ~~./arch/arm/boot/~~vmlinux		$ ls -la vmlinux
	text data bss dec hex filename		-rwxrwxr-x 1 dvhart dvhart 143686262 2011-06-22 16:47 vmlinux
	~~5527685 338944~~ ~~272776 6139405~~ ~~5dae0d ./arch/arm/boot/~~vmlinux
			$ size vmlinux
			text data bss dec hex filename
			7261405 779724 1603032 9644161 932881 vmlinux
	</pre>		</pre>

Dvhart: /* Next Steps */

2011-06-22T21:01:19Z

Next Steps

← Older revision		Revision as of 21:01, 22 June 2011
Line 21:		Line 21:
	* Determine ways to minimize the image for the n450		* Determine ways to minimize the image for the n450
	* Create optional small variants		* Create optional small variants
	* Verify small variant works on all four meta-yocto defined machines		* Possibly M3 items
	* Verify small variant works on all meta-intel defined machines		** Verify small variant works on all four meta-yocto defined machines
			** Verify small variant works on all meta-intel defined machines

	== Resources ==		== Resources ==

Dvhart at 20:49, 22 June 2011

2011-06-22T20:49:25Z

← Older revision		Revision as of 20:49, 22 June 2011
Line 13:		Line 13:

	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.		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
			* Verify small variant works on all four meta-yocto defined machines
			* Verify small variant works on all meta-intel defined machines

	== Resources ==		== Resources ==

Dvhart: /* Design */

2011-06-22T20:45:25Z

Design

← Older revision		Revision as of 20:45, 22 June 2011
Line 9:		Line 9:

	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. An audit of linux-tiny will determine if there are patches remaining there that we should help get included upstream.		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. 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.		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.

Dvhart: /* Vision */

2011-06-22T20:41:40Z

Vision

← Older revision		Revision as of 20:41, 22 June 2011
Line 1:		Line 1:
	== Vision ==		== 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.		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.

	== Design ==		== Design ==