Updated Yocto Hands-on Kernel Lab available


Tom Zanussi <tom.zanussi@...>
 

Hi,

I'm happy to announce that an updated version of the Yocto 'Hands-on
Kernel Lab' has been released and is available here:

https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf

The above document contains all the instructions you need to get started
from scratch.

You can always get to the lab and associated content by visiting the
Yocto home page (https://www.yoctoproject.org/) and selecting 'Read
presentations about the project' from the drop-down list you get by
clicking on the 'Start Here to learn more' box on the left-hand side and
clicking on the 'Working with the Kernel' presentation link.

The 'Hands-on Kernel Lab' has been updated to Yocto 1.3 ('danny') and
has been substantially expanded from three to five labs, with completely
new sections covering custom kernels, loadable modules and getting them
into (and autoloaded into) images, external modules, local clones, bare
local clones, and enabling LTSI features.

See below for a more complete listing of what's covered along with the
lab number covering those topics.

I've run through the lab twice, once on Fedora 17 and once on Ubuntu
12.04, so it should be pretty solid at this point, but if you find
problems, please let me know...

* Creating and using a traditional kernel recipe (lab1)
* Using 'bitbake -c menuconfig' to modify the kernel configuration and replace the defconfig with the new configuration (lab1)
* Adding a kernel module to the kernel source and configuring it as a built-in module by adding options to the kernel defconfig (lab1)
* Creating and using a linux-yocto-based kernel (lab2)
* Adding a kernel module to the kernel source and configuring it as a built-in module using linux-yocto 'config fragments' (lab2)
* Using the linux-yocto kernel as an LTSI kernel (configuring in an item added by the LTSI kernel which is merged into linux-yocto) (lab2)
* Using an arbitrary git-based kernel via the linux-yocto-custom kernel recipe (lab3)
* Adding a kernel module to the kernel source of an arbitrary git-based kernel and configuring it as a loadable module using 'config fragments' (lab3)
* Actually getting the module into the image and autoloading it on boot (lab3)
* Using a local clone of an arbitrary git-based kernel via the linux-yocto-custom kernel recipe to demonstrate a typical development workflow (lab4)
* Modifying the locally cloned custom kernel source and verifying the changes in the new image (lab4)
* Using a local clone of a linux-yocto- kernel recipe to demonstrate a typical development workflow (lab4)
* Modifying the locally cloned linux-yocto kernel source and verifying the changes in the new image (lab4)
* Using a 'bare' local clone of a linux-yocto- kernel recipe to demonstrate a typical development workflow (lab4)
* Modifying the locally cloned 'bare' linux-yocto kernel source and verifying the changes in the new image (lab4)
* Adding and using an external kernel module via a module recipe (lab4)
* Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP (lab5)
* Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches and config fragments (lab5)


David Stewart
 

On 2/15/13 6:29 PM, "Tom Zanussi" <tom.zanussi@intel.com> wrote:

Hi,

I'm happy to announce that an updated version of the Yocto 'Hands-on
Kernel Lab' has been released and is available here:

https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-l
ab.pdf

The above document contains all the instructions you need to get started
from scratch.
Pretty frickin' awesome. Great job!


You can always get to the lab and associated content by visiting the
Yocto home page (https://www.yoctoproject.org/) and selecting 'Read
presentations about the project' from the drop-down list you get by
clicking on the 'Start Here to learn more' box on the left-hand side and
clicking on the 'Working with the Kernel' presentation link.

The 'Hands-on Kernel Lab' has been updated to Yocto 1.3 ('danny') and
has been substantially expanded from three to five labs, with completely
new sections covering custom kernels, loadable modules and getting them
into (and autoloaded into) images, external modules, local clones, bare
local clones, and enabling LTSI features.

See below for a more complete listing of what's covered along with the
lab number covering those topics.

I've run through the lab twice, once on Fedora 17 and once on Ubuntu
12.04, so it should be pretty solid at this point, but if you find
problems, please let me know...

* Creating and using a traditional kernel recipe (lab1)
* Using 'bitbake -c menuconfig' to modify the kernel configuration and
replace the defconfig with the new configuration (lab1)
* Adding a kernel module to the kernel source and configuring it as a
built-in module by adding options to the kernel defconfig (lab1)
* Creating and using a linux-yocto-based kernel (lab2)
* Adding a kernel module to the kernel source and configuring it as a
built-in module using linux-yocto 'config fragments' (lab2)
* Using the linux-yocto kernel as an LTSI kernel (configuring in an item
added by the LTSI kernel which is merged into linux-yocto) (lab2)
* Using an arbitrary git-based kernel via the linux-yocto-custom kernel
recipe (lab3)
* Adding a kernel module to the kernel source of an arbitrary git-based
kernel and configuring it as a loadable module using 'config fragments'
(lab3)
* Actually getting the module into the image and autoloading it on boot
(lab3)
* Using a local clone of an arbitrary git-based kernel via the
linux-yocto-custom kernel recipe to demonstrate a typical development
workflow (lab4)
* Modifying the locally cloned custom kernel source and verifying the
changes in the new image (lab4)
* Using a local clone of a linux-yocto- kernel recipe to demonstrate a
typical development workflow (lab4)
* Modifying the locally cloned linux-yocto kernel source and verifying
the changes in the new image (lab4)
* Using a 'bare' local clone of a linux-yocto- kernel recipe to
demonstrate a typical development workflow (lab4)
* Modifying the locally cloned 'bare' linux-yocto kernel source and
verifying the changes in the new image (lab4)
* Adding and using an external kernel module via a module recipe (lab4)
* Using the 'Yocto BSP Tools' yocto-bsp tool generate a new Yocto BSP
(lab5)
* Using the 'Yocto BSP Tools' yocto-kernel tool to add kernel patches and
config fragments (lab5)


_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Trevor Woerner
 

...sorry, I meant to CC the list too


---------- Forwarded message ----------
From: Trevor Woerner <twoerner@gmail.com>
Date: Sun, Feb 17, 2013 at 9:15 PM
Subject: Re: [yocto] Updated Yocto Hands-on Kernel Lab available
To: Tom Zanussi <tom.zanussi@intel.com>


Hi Tom,

I can see how the kernel *.bb files get pulled in due to the following
line in each lab's layer configuration (${LAYERDIR}/conf/layer.conf):

BBFILES := "... ${LAYERDIR}/recipes-*/*/*.bb ..."

Since the *.bb files are located under
${LAYERDIR}/recipes-kernel/linux/<kernel>.bb this matched the above
pattern.

What I can't figure out is why, for example, in lab1 are the kernel
patch files located in

${LAYERDIR}/recipes-kernel/linux/linux

while the kernel patch files for lab2 are in

${LAYERDIR}/recipes-kernel/linux/files

Does bitbake find the patch files for lab1 in a subdirectory called
"linux" because the recipe's name is linux_3.0.18.bb? Because I don't
see anything in that particular recipe which would suggest it
(bitbake) should look there (linux). And when I go to lab2 and rename
the "files" directory to "linux-yocto" the build doesn't work, so this
behaviour would seem to discount the belief that a patch directory
name can take on the recipe name and be found.

Best regards,
Trevor


Tom Zanussi <tom.zanussi@...>
 

On Sun, 2013-02-17 at 21:16 -0500, Trevor Woerner wrote:
...sorry, I meant to CC the list too


---------- Forwarded message ----------
From: Trevor Woerner <twoerner@gmail.com>
Date: Sun, Feb 17, 2013 at 9:15 PM
Subject: Re: [yocto] Updated Yocto Hands-on Kernel Lab available
To: Tom Zanussi <tom.zanussi@intel.com>


Hi Tom,

I can see how the kernel *.bb files get pulled in due to the following
line in each lab's layer configuration (${LAYERDIR}/conf/layer.conf):

BBFILES := "... ${LAYERDIR}/recipes-*/*/*.bb ..."

Since the *.bb files are located under
${LAYERDIR}/recipes-kernel/linux/<kernel>.bb this matched the above
pattern.

What I can't figure out is why, for example, in lab1 are the kernel
patch files located in

${LAYERDIR}/recipes-kernel/linux/linux

while the kernel patch files for lab2 are in

${LAYERDIR}/recipes-kernel/linux/files

Does bitbake find the patch files for lab1 in a subdirectory called
"linux" because the recipe's name is linux_3.0.18.bb? Because I don't
see anything in that particular recipe which would suggest it
(bitbake) should look there (linux). And when I go to lab2 and rename
the "files" directory to "linux-yocto" the build doesn't work, so this
behaviour would seem to discount the belief that a patch directory
name can take on the recipe name and be found.
Hi,

Yes, in lab1 bitbake finds the patch files because they're in the
'linux' subdirectory. It should also be able to find them if you
renamed that directory to 'linux-3.0.18', and it would also find them in
the 'files' directory. These subdirectories are added to FILESPATH in
base.bbclass:

FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"

Those are relative to a .bb, which is what we have in lab1 - the kernel
recipe is linux_3.0.18.bb.

In lab2, we have a linux-yocto_3.4.bbappend file rather than a .bb file.

If you look at the .bbappend, you can see:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

which is what we need to add to the .bbappend to get bitbake to look in
the 'files' subdirectory under the .bbappend - since the FILESPATH is
relative to the base recipe in meta/, linux-yocto_3.4.bb, and not
our .bbappend, bitbake won't find the files under our .bbappend unless
we add our .bbappend's 'files' subdir to FILESPATH via FILESEXTRAPATHS.

If you wanted to change the name of the directory under the .bbappend to
'linux-yocto', you could just use:

FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto:"

or better:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

Tom

Best regards,
Trevor
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Trevor Woerner
 

I can't figure out what I'm doing wrong, but I can't get lab3 to work.

Following the instructions in the pdf I first tried doing lab3
incrementally (build/test, build/test, build/test) and it didn't work.
Then I tried deleting (tmp, sstate, etc), trying again, and it still
didn't work.

Build Configuration:
BB_VERSION = "1.16.0"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "lab3-qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.3"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-lab3-qemux86 = "danny:45f95b5f3381097672dd43077f267aa716a02b4c"

I then copied the meta-lab3-qemux86 layer to where I was working with
the master branch of poky (hmm... I guess I could have just edited
bblayers.conf without needing the hassle of the copy), retried the
exercise, and it worked.

Build Configuration:
BB_VERSION = "1.17.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "SUSE-LINUX-12.2"
TARGET_SYS = "i586-poky-linux"
MACHINE = "lab3-qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.3+snapshot-20130218"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-lab3-qemux86 = "master:c7b23ab68aafc04d9830ef318015912e5d4f0672"

Note that the above information is a bit misleading.
"meta-lab3-qemux86" is just a plain directory without any .git so
there is no "master" or "danny" of "meta-lab3-qemux86". The "master"
and "danny" branches are of the enclosing poky repository.

In the case where it doesn't work, the module is built and included in
the image, but it isn't loaded automatically during boot. Working off
master, the module is loaded during boot automatically.


Tom Zanussi <tom.zanussi@...>
 

On Mon, 2013-02-18 at 18:50 -0500, Trevor Woerner wrote:
I can't figure out what I'm doing wrong, but I can't get lab3 to work.

Following the instructions in the pdf I first tried doing lab3
incrementally (build/test, build/test, build/test) and it didn't work.
Then I tried deleting (tmp, sstate, etc), trying again, and it still
didn't work.

Build Configuration:
BB_VERSION = "1.16.0"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "lab3-qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.3"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-lab3-qemux86 = "danny:45f95b5f3381097672dd43077f267aa716a02b4c"

I then copied the meta-lab3-qemux86 layer to where I was working with
the master branch of poky (hmm... I guess I could have just edited
bblayers.conf without needing the hassle of the copy), retried the
exercise, and it worked.

Build Configuration:
BB_VERSION = "1.17.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "SUSE-LINUX-12.2"
TARGET_SYS = "i586-poky-linux"
MACHINE = "lab3-qemux86"
DISTRO = "poky"
DISTRO_VERSION = "1.3+snapshot-20130218"
TUNE_FEATURES = "m32 i586"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp
meta-lab3-qemux86 = "master:c7b23ab68aafc04d9830ef318015912e5d4f0672"

Note that the above information is a bit misleading.
"meta-lab3-qemux86" is just a plain directory without any .git so
there is no "master" or "danny" of "meta-lab3-qemux86". The "master"
and "danny" branches are of the enclosing poky repository.

In the case where it doesn't work, the module is built and included in
the image, but it isn't loaded automatically during boot. Working off
master, the module is loaded during boot automatically.
So when you say it doesn't work, you mean the module autoload didn't
work, but everything else did? Did you do the 'bump the PR' step after
you uncommmented the module autoload statement?

If that's not it, then I don't know what you say - I tested it with
danny and it worked fine for me. I can try running through it again to
verify again, but it really should work...

Tom


Trevor Woerner
 

On Tue, Feb 19, 2013 at 12:31 AM, Tom Zanussi <tom.zanussi@intel.com> wrote:
So when you say it doesn't work, you mean the module autoload didn't
work, but everything else did?
Yes, exactly.

Did you do the 'bump the PR' step after
you uncommmented the module autoload statement?
Yes, I even bumped it twice :-) But even if I forgot to bump the PR
number, when I deleted tmp/sstate/etc and started a fresh build, it
should have worked then?

If that's not it, then I don't know what you say - I tested it with
danny and it worked fine for me. I can try running through it again to
verify again, but it really should work...
Thanks for your comments. I'll guess I'll have to try it all again.
Maybe I somehow checked out the wrong version. Like I said, performing
the same steps against yesterday's master worked completely as
expected.


Tom Zanussi <tom.zanussi@...>
 

On Tue, 2013-02-19 at 05:31 -0500, Trevor Woerner wrote:
On Tue, Feb 19, 2013 at 12:31 AM, Tom Zanussi <tom.zanussi@intel.com> wrote:
So when you say it doesn't work, you mean the module autoload didn't
work, but everything else did?
Yes, exactly.

Did you do the 'bump the PR' step after
you uncommmented the module autoload statement?
Yes, I even bumped it twice :-) But even if I forgot to bump the PR
number, when I deleted tmp/sstate/etc and started a fresh build, it
should have worked then?
It really should have, yes.

If that's not it, then I don't know what you say - I tested it with
danny and it worked fine for me. I can try running through it again to
verify again, but it really should work...
Thanks for your comments. I'll guess I'll have to try it all again.
Maybe I somehow checked out the wrong version. Like I said, performing
the same steps against yesterday's master worked completely as
expected.
I'll go through it here as well as soon as I can and let you know...

Tom


Trevor Woerner
 

Following up on a hunch, after reading Pierre Ficheux's email from
earlier today, I realized that by default I always switch my build's
PACKAGE_CLASSES to ipk simply because this packaging takes the least
amount of build time. Sure enough, when working on lab3 I had switched
to ipk and it didn't work. Switching PACKAGE_CLASSES to rpm and doing
nothing else but rebuilding, everything worked. I tried twice more
switching between ipk and rpm and anytime ipk is used the module is
not automatically installed, but with rpm it is.


Tom Zanussi <tom.zanussi@...>
 

On Tue, 2013-02-19 at 22:34 -0500, Trevor Woerner wrote:
Following up on a hunch, after reading Pierre Ficheux's email from
earlier today, I realized that by default I always switch my build's
PACKAGE_CLASSES to ipk simply because this packaging takes the least
amount of build time. Sure enough, when working on lab3 I had switched
to ipk and it didn't work. Switching PACKAGE_CLASSES to rpm and doing
nothing else but rebuilding, everything worked. I tried twice more
switching between ipk and rpm and anytime ipk is used the module is
not automatically installed, but with rpm it is.
Interesting - I wouldn't have thought of looking at that as a source of
the problem. I'll try it out myself and file a bug if it turns out to
be the problem. Thanks for that info!

Tom