TipsAndTricks/DemystifyingTheLinuxYoctoKernel - Revision history

Tzanussi at 20:54, 27 June 2016

2016-06-27T20:54:03Z

← Older revision		Revision as of 20:54, 27 June 2016
Line 9:		Line 9:
	To make that point clear, let's take a quick look at a typical kernel development workflow outside of Yocto (don't let the phrase 'kernel development workflow' scare you off - for the purposes of this article it just refers to compiling and building and possibly configuring a kernel, which is something anyone dealing with a build system like Yocto should be comfortable with).		To make that point clear, let's take a quick look at a typical kernel development workflow outside of Yocto (don't let the phrase 'kernel development workflow' scare you off - for the purposes of this article it just refers to compiling and building and possibly configuring a kernel, which is something anyone dealing with a build system like Yocto should be comfortable with).

	To configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this[3]:		To modify code, configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this [3]:

			$ edit the kernel source (or don't if you're just configuring or building)
	$ make menuconfig		$ make menuconfig
	.		.
Line 25:		Line 26:
	The same thing in Yocto would be:		The same thing in Yocto would be:

			$ edit the kernel source (or don't if you're just configuring or building) [4]
	$ bitbake -c menuconfig virtual/kernel		$ bitbake -c menuconfig virtual/kernel
	.		.
Line 37:		Line 39:
	reboot target and see changes		reboot target and see changes

	As you can see, the only differences in the Yocto version are trivial: in Yocto, you use 'bitbake' instead of 'make', and in Yocto, you have to deal with a godawful long and ugly path to the final kernel image. [4]		As you can see, the only differences in the Yocto version are trivial: in Yocto, you use 'bitbake' instead of 'make', and in Yocto, you have to deal with a godawful long and ugly path to the final kernel image. [5]

			Even though it's very similar at its barest level, the Yocto version gives you one thing that the non-Yocto version doesn't - the ability to cross-compile for a different target, which is automatically hidden beneath the 'bitbake' command. In this example, we may happen to be building on the same type of host as we are targeting, for example, x86-64, but with the Yocto/bitbake version, we could build for any target and it would use essentially the same procedure.

			Of course, this says nothing about saving your changes and allowing other users to access them, which is basically what the rest of the build system is all about, and which for now is a mystery we'll cover in a future article.


Line 47:		Line 53:
	$ mount /dev/mmcblk0p1 /mnt		$ mount /dev/mmcblk0p1 /mnt

	[4] This is nothing mysterious either. Just start at the build directory and follow the path to the kernel like so (this is just a typical example - there normally aren't many ways to get lost, making it look worse than it is):		[4] In the Yocto version, the source you'd modify is located at something like tmp/work/core2-32-intel-common-poky-linux/linux-yocto/4.1.26+gitAUTOINC+9f68667031_9195020e57-r0/linux-core2-32-intel-common-standard-build/source/ (see [5] for context)

			[5] This is nothing mysterious either. Just start at the build directory and follow the path to the kernel like so (this is just a typical example - there normally aren't many ways to get lost, making it look worse than it is):
	$ cd tmp		$ cd tmp
	$ cd work		$ cd work

Tzanussi at 20:40, 27 June 2016

2016-06-27T20:40:56Z

← Older revision		Revision as of 20:40, 27 June 2016
Line 9:		Line 9:
	To make that point clear, let's take a quick look at a typical kernel development workflow outside of Yocto (don't let the phrase 'kernel development workflow' scare you off - for the purposes of this article it just refers to compiling and building and possibly configuring a kernel, which is something anyone dealing with a build system like Yocto should be comfortable with).		To make that point clear, let's take a quick look at a typical kernel development workflow outside of Yocto (don't let the phrase 'kernel development workflow' scare you off - for the purposes of this article it just refers to compiling and building and possibly configuring a kernel, which is something anyone dealing with a build system like Yocto should be comfortable with).

	To configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this:		To configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this[3]:

	$ make menuconfig		$ make menuconfig
Line 37:		Line 37:
	reboot target and see changes		reboot target and see changes

	As you can see, the only differences in the Yocto version are trivial: in Yocto, you use 'bitbake' instead of 'make', and in Yocto, you have to deal with a godawful long and ugly path to the final kernel image. [3]		As you can see, the only differences in the Yocto version are trivial: in Yocto, you use 'bitbake' instead of 'make', and in Yocto, you have to deal with a godawful long and ugly path to the final kernel image. [4]


Line 44:		Line 44:
	[2] [http://www.yoctoproject.org/docs/2.1/kernel-dev/kernel-dev.html Yocto Kernel Development Manual]		[2] [http://www.yoctoproject.org/docs/2.1/kernel-dev/kernel-dev.html Yocto Kernel Development Manual]

	[3] This is nothing mysterious either. Just start at the build directory and follow the path to the kernel like so (this is just a typical example - there normally aren't many ways to get lost, making it look worse than it is):		[3] This assumes that the target is network-connected and you've mounted the boot partition at /mnt on the target, e.g.:
			$ mount /dev/mmcblk0p1 /mnt

			[4] This is nothing mysterious either. Just start at the build directory and follow the path to the kernel like so (this is just a typical example - there normally aren't many ways to get lost, making it look worse than it is):
	$ cd tmp		$ cd tmp
	$ cd work		$ cd work

Tzanussi at 20:37, 27 June 2016

2016-06-27T20:37:59Z

← Older revision		Revision as of 20:37, 27 June 2016
Line 37:		Line 37:
	reboot target and see changes		reboot target and see changes

			As you can see, the only differences in the Yocto version are trivial: in Yocto, you use 'bitbake' instead of 'make', and in Yocto, you have to deal with a godawful long and ugly path to the final kernel image. [3]


Line 42:		Line 43:

	[2] [http://www.yoctoproject.org/docs/2.1/kernel-dev/kernel-dev.html Yocto Kernel Development Manual]		[2] [http://www.yoctoproject.org/docs/2.1/kernel-dev/kernel-dev.html Yocto Kernel Development Manual]

			[3] This is nothing mysterious either. Just start at the build directory and follow the path to the kernel like so (this is just a typical example - there normally aren't many ways to get lost, making it look worse than it is):
			$ cd tmp
			$ cd work
			$ cd core2-32-intel-common-poky-linux
			$ cd linux-yocto
			$ cd 4.1.26+gitAUTOINC+9f68667031_9195020e57-r0
			$ cd linux-core2-32-intel-common-standard-build
			$ scp arch/x86/boot/bzImage target:/mnt/bzImage

Tzanussi at 20:21, 27 June 2016

2016-06-27T20:21:58Z

← Older revision		Revision as of 20:21, 27 June 2016
Line 11:		Line 11:
	To configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this:		To configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this:

			$ make menuconfig
			.
			.
			select/deselect new config items
			.
			.
			$ make bzImage
			$ scp arch/x86/boot/bzImage 10.0.0.18/mnt/bzImage
			.
			.
			reboot target and see changes

			The same thing in Yocto would be:

			$ bitbake -c menuconfig virtual/kernel
			.
			.
			select/deselect new config items
			.
			.
			$ bitbake -c compile -f virtual/kernel
			$ scp tmp/work/core2-32-intel-common-poky-linux/linux-yocto/4.1.26+gitAUTOINC+9f68667031_9195020e57-r0/linux-core2-32-intel-common-standard-build/arch/x86/boot/bzImage 10.0.0.18:/mnt/bzImage
			.
			.
			reboot target and see changes

Tzanussi at 20:08, 27 June 2016

2016-06-27T20:08:18Z

← Older revision		Revision as of 20:08, 27 June 2016
Line 4:		Line 4:

	Let's start first with the kernel itself. When most people think of a kernel in Yocto, they tend to think of it as something that's wrapped inside a kernel recipe, which in turn is something that's wrapped inside the build system and generated into the final image. That's all true and valid, but all those extra layers (let's call them the mystery and the enigma for now) obscure the kernel of truth at the center (the riddle). Let's just look at the riddle and come back some other day to explain the mystery and the enigma.		Let's start first with the kernel itself. When most people think of a kernel in Yocto, they tend to think of it as something that's wrapped inside a kernel recipe, which in turn is something that's wrapped inside the build system and generated into the final image. That's all true and valid, but all those extra layers (let's call them the mystery and the enigma for now) obscure the kernel of truth at the center (the riddle). Let's just look at the riddle and come back some other day to explain the mystery and the enigma.

			At its heart, a Yocto kernel is just exactly the same thing as an upstream Linux kernel.

			To make that point clear, let's take a quick look at a typical kernel development workflow outside of Yocto (don't let the phrase 'kernel development workflow' scare you off - for the purposes of this article it just refers to compiling and building and possibly configuring a kernel, which is something anyone dealing with a build system like Yocto should be comfortable with).

			To configure, build, and boot a new kernel outside of Yocto, you'd typically do something like this:

Tzanussi at 19:52, 27 June 2016

2016-06-27T19:52:58Z

← Older revision		Revision as of 19:52, 27 June 2016
Line 1:		Line 1:
	Despite the existence of plenty of in-depth documentation out there on working with kernels in Yocto, most people seem to still view the subject as a riddle wrapped in a mystery inside an enigma [1][2].		Despite the existence of plenty of in-depth documentation out there on working with kernels in Yocto, most people seem to still view the subject as 'a riddle, wrapped in a mystery, inside an enigma'. [1][2]

	This is the first in what should be a short series of articles dealing with Yocto kernels, focusing only on the bare essentials.		This is the first in what should be a short series of articles dealing with Yocto kernels, focusing only on the bare essentials.

			Let's start first with the kernel itself. When most people think of a kernel in Yocto, they tend to think of it as something that's wrapped inside a kernel recipe, which in turn is something that's wrapped inside the build system and generated into the final image. That's all true and valid, but all those extra layers (let's call them the mystery and the enigma for now) obscure the kernel of truth at the center (the riddle). Let's just look at the riddle and come back some other day to explain the mystery and the enigma.

Tzanussi: Created page with "Despite the existence of plenty of in-depth documentation out there on working with kernels in Yocto, most people seem to still view the subject as a riddle wrapped in a myste..."

2016-06-27T19:43:10Z

Created page with "Despite the existence of plenty of in-depth documentation out there on working with kernels in Yocto, most people seem to still view the subject as a riddle wrapped in a myste..."

New page

Despite the existence of plenty of in-depth documentation out there on working with kernels in Yocto, most people seem to still view the subject as a riddle wrapped in a mystery inside an enigma [1][2].

This is the first in what should be a short series of articles dealing with Yocto kernels, focusing only on the bare essentials.

[1] [https://www.yoctoproject.org/training/kernel-lab Yocto kernel labs]

[2] [http://www.yoctoproject.org/docs/2.1/kernel-dev/kernel-dev.html Yocto Kernel Development Manual]