[[Category:Kernel Development QA]]
This article is the test plan for Kernel Development.

= About Kernel Development =
Describes common tasks you can perform on Yocto Project using the kernel tools, and shows you how to use the metadata needed to work with the kernel.
For more information you can review [http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html Kernel Development.]

= Objectives =
Verify all Kernel Development components to be fully functional. This approach is based from Manual Testing.

= Team members =
==QA Team involved in Kernel Development testing==

[mailto:jair.de.jesus.gonzalez.plascencia@intel.com Jair Gonzalez ]

= Scope =
* linux-yocto-custom
* local source.
* local source with parallel meta.
* local source with recipe-space meta.
* External Source
* defconfig
* defconfig + fragments
* linux-yocto meta data + local fragments.
* building external modules (hello-mod).

= Test Strategy =
There are several test approaches for Kernel Development, such as:
Perform test cases agreed upon the development during periodic Manual (full pass) according to the Schedule.
Write new test cases based on developer request or new features as required.
Maintain current test cases and update them accordingly the new changes.
Perform exploratory testing on existing functionalities.

== Test automation ==
Not required until now.
== Test Approach ==

=== Sanity testing ===
* Not covered at this moment
* TBD following DEV discussions

== Maintaining the test cases ==
== Submitting Bugs ==
Being part of the Yocto Project, Kernel Development follows the same Yocto Project guidelines and principles. The guidelines can be found at https://wiki.yoctoproject.org/wiki/Community_Guidelines.
Kernel Development bugs are no different and are tracked into Bugzilla, the official Yocto Project bug tracker. Learn more about [https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking our process for reporting bugs].

=Requirements=

This set of requirements is listed in a two column format, Bugzilla entries vs. requirement description in the form of a user story.

As a Developer I want to be able to generate and change configuration files (defconfig). - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1612 Test Case 1612]

As a Developer I want to be able to generate and change configuration files (defconfig + fragments). - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1613 Test Case 1613]

As a Developer I want to be able to apply single patch to Linux Kernel Source. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1614 Test Case 1614]

As a Developer I want to to be able to work with your own sources. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1615 Test Case 1615]

As a Developer I want to be able to work with own sources for linux-yocto-custom-local-source. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1616 Test Case 1616]

As a Developer I want to be able to work with recipe-space meta. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1617 Test Case 1617]

As a Developer I want to be able to work with External Source. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1618 Test Case 1618]

As a Developer I want to be able to configure linux-yocto meta data + local fragments. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1618 Test Case 1618]

As a Developer I want to be able to build external modules (hello-mod). - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1832 Test Case 1832]

As a Developer I want to be able to work with local source with parallel meta.. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1833 Test Case 1833]

The complete test cases are not completed due current design.

==HW Requirements==
* Any machine able to build Yocto Project.

==Software Requirements==
* Poky.
* GNU/Linux environment

==Environment Requirements==
**YP 2.3 Release:
**Ubuntu-14.04
**Ubuntu-14.10
**Ubuntu-15.04
**Fedora-21
**CentOS-6.*
**CentOS-7.*
**Debian-7.*
**Debian-8.*
**openSUSE-project-13.2

=Features=
 Features to be Tested 

1. linux-yocto-custom.
1.1 local source. 
1.2 local source with parallel meta
1.3 local source with recipe-space meta

2. External Source.

3.Defconfig.
4.Defconfig + Fragments.
5.building external modules (hello-mod).

= Schedule =
Every cycle depending on Milestone and release candidate

==Test execution Cycle==
{| class="wikitable"
! Build
! Automated Test
! Manual Test
|-
| Daily Master
| NO
| NO
|-
| Weekly Build
| TBD
| Y
|-
| Milestone Build
| TBD
| Y
|}

=Dependencies=
*YP Dependencies
** poky
** meta-kerneltest recipe

=Risk Assumptions=
* For each change in kernel version and kernel cache, the team needs to change many configuration in order to achieve this.
* Just like any software, the kernel is also susceptible to bugs. A common “Long Term Support”.

=Tools=
 TBD 

= Release Criteria/ Exit Criteria =

Kernel Development QA

2017-10-16T23:47:26Z

Jair Gonzalez: /* About Kernel Development */

[[Category:Kernel Development QA]]
This article is the test plan for Kernel Development.

= About Kernel Development =
Describes common tasks you can perform on Yocto Project using the kernel tools, and shows you how to use the metadata needed to work with the kernel.
For more information you can review [http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html Kernel Development.]

= Objectives =
Verify all Kernel Development components to be fully functional. This approach is based from Manual Testing.

= Team members =
==QA Team involved in Kernel Development testing==

[mailto:francisco.j.pedraza.gonzalez@intel.com Francisco Pedraza ]

= Scope =
* linux-yocto-custom
* local source.
* local source with parallel meta.
* local source with recipe-space meta.
* External Source
* defconfig
* defconfig + fragments
* linux-yocto meta data + local fragments.
* building external modules (hello-mod).

= Test Strategy =
There are several test approaches for Kernel Development, such as:
Perform test cases agreed upon the development during periodic Manual (full pass) according to the Schedule.
Write new test cases based on developer request or new features as required.
Maintain current test cases and update them accordingly the new changes.
Perform exploratory testing on existing functionalities.

== Test automation ==
Not required until now.
== Test Approach ==

=== Sanity testing ===
* Not covered at this moment
* TBD following DEV discussions

== Maintaining the test cases ==
== Submitting Bugs ==
Being part of the Yocto Project, Kernel Development follows the same Yocto Project guidelines and principles. The guidelines can be found at https://wiki.yoctoproject.org/wiki/Community_Guidelines.
Kernel Development bugs are no different and are tracked into Bugzilla, the official Yocto Project bug tracker. Learn more about [https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking our process for reporting bugs].

=Requirements=

This set of requirements is listed in a two column format, Bugzilla entries vs. requirement description in the form of a user story.

As a Developer I want to be able to generate and change configuration files (defconfig). - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1612 Test Case 1612]

As a Developer I want to be able to generate and change configuration files (defconfig + fragments). - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1613 Test Case 1613]

As a Developer I want to be able to apply single patch to Linux Kernel Source. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1614 Test Case 1614]

As a Developer I want to to be able to work with your own sources. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1615 Test Case 1615]

As a Developer I want to be able to work with own sources for linux-yocto-custom-local-source. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1616 Test Case 1616]

As a Developer I want to be able to work with recipe-space meta. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1617 Test Case 1617]

As a Developer I want to be able to work with External Source. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1618 Test Case 1618]

As a Developer I want to be able to configure linux-yocto meta data + local fragments. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1618 Test Case 1618]

As a Developer I want to be able to build external modules (hello-mod). - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1832 Test Case 1832]

As a Developer I want to be able to work with local source with parallel meta.. - [https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1833 Test Case 1833]

The complete test cases are not completed due current design.

==HW Requirements==
* Any machine able to build Yocto Project.

==Software Requirements==
* Poky.
* GNU/Linux environment

==Environment Requirements==
**YP 2.3 Release:
**Ubuntu-14.04
**Ubuntu-14.10
**Ubuntu-15.04
**Fedora-21
**CentOS-6.*
**CentOS-7.*
**Debian-7.*
**Debian-8.*
**openSUSE-project-13.2

=Features=
 Features to be Tested 

1. linux-yocto-custom.
1.1 local source. 
1.2 local source with parallel meta
1.3 local source with recipe-space meta

2. External Source.

3.Defconfig.
4.Defconfig + Fragments.
5.building external modules (hello-mod).

= Schedule =
Every cycle depending on Milestone and release candidate

==Test execution Cycle==
{| class="wikitable"
! Build
! Automated Test
! Manual Test
|-
| Daily Master
| NO
| NO
|-
| Weekly Build
| TBD
| Y
|-
| Milestone Build
| TBD
| Y
|}

=Dependencies=
*YP Dependencies
** poky
** meta-kerneltest recipe

=Risk Assumptions=
* For each change in kernel version and kernel cache, the team needs to change many configuration in order to achieve this.
* Just like any software, the kernel is also susceptible to bugs. A common “Long Term Support”.

=Tools=
 TBD 

= Release Criteria/ Exit Criteria =

Kernel Development Test Cases

2017-10-16T23:14:08Z

Jair Gonzalez: /* Expected results */

==Setup==
===Common Prerequisites===
: 1. Have a clone of poky:
:: <pre>$ git clone git://git.yoctoproject.org/poky</pre>
: 2. Check out the required commit using git:
:: <pre>$ git checkout [COMMIT_HASH]</pre>
: 3. Source the build environment to create the configuration files:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ . oe-init-build-env</pre>
: 4. Open the conf/local.conf file:
:: <pre>$ vi conf/local.conf</pre>
:: Establish the machine to qemux86-64 by setting the line:
:: <pre>MACHINE = "qemux86-64"</pre>
: 5. Compile a minimal image:
:: <pre>$ bitbake core-image-minimal</pre>
: 6. Get and take note of the linux-yocto kernel version (only the first two numbers, for example: 4.10):
:: <pre>$ bitbake virtual/kernel -e | grep LINUX_VERSION</pre>
: 7. Create a layer to store kernel test metadata. For this task, you could use the yocto-layer script and its default recipe values:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ yocto-layer create [LAYER-NAME]</pre>
:: Note: In the rest of this document "meta-kerneltest" is used as the [LAYER-NAME].
: 8. Create the recipe directory structure inside the created layer:
:: <pre>$ mkdir -p meta-kerneltest/recipes-kernel/linux/</pre>
: 9. Create a recipe append file inside the directory:
:: <pre>$ touch meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
: 10. Copy the recipe file corresponding to the linux-yocto version inside the directory:
:: <pre>$ cp meta/recipes-kernel/linux/linux-yocto_[VERSION].bb meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
: 11. Edit the linux-yocto-custom recipe:
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Set the PV variable with the LINUX_VERSION variable value:
:: <pre>PV = "${LINUX_VERSION}"</pre>
: 12. Create directory "linux-yocto":
:: <pre>$ mkdir meta-kerneltest/recipes-kernel/linux/linux-yocto/</pre>
: 13. Create directory "linux-yocto-custom":
:: <pre>$ mkdir meta-kerneltest/recipes-kernel/linux/linux-yocto-custom/</pre>
: 14. Add the created layer to bblayers.conf. For this task, you could use the bitbake-layers script from inside the build directory:
:: <pre>$ cd build</pre>
:: <pre>$ bitbake-layers add-layer ../meta-kerneltest</pre>
===General Remarks===
: 1. As a suggestion, open another terminal in order to perform git commands.
: 2. Remember to source the environment and ensure your current work directory is [POKY_PATH]/build before using bitbake scripts and tools.
: 3. You can edit any required file with vim, emacs, or your preferred text editor.
: 4. If there is not a proper response after building an image, be sure to clean the shared state, and try again. To clean it, you can use:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 5. Be careful with the information added to recipe and recipe append files, using the same values -- including spaces-- to set a recipe variable value.
:: To ensure all the sources are correctly downloaded and the required taks are executed, ensure no shared states proxies are set on conf/local.conf.
: 6. Make sure to point to the correct linux-yocto version.

 
==TC_KD_01 – Applying Patches==
===Use Case===
As a developer, I want to be able to apply a single patch to the Linux kernel source.
===Prerequisites===
: 1. Generate the patch:
:: 1.1. Go to kernel source directory:
::: <pre>$ cd [POKY_PATH]/build/tmp/work-shared/qemux86-64/kernel-source</pre>
:: 1.2. Add some information at the end of the README file:
::: <pre>$ echo This is a test to apply a patch to the kernel. >> README</pre>
:: 1.3. Add the modified file to the patch:
::: <pre>$ git add README</pre>
:: 1.4. Commit the change:
::: <pre>$ git commit -s -m "KERNEL DEV TEST CASE"</pre>
:: 1.5. Format the patch:
::: <pre>$ git format-patch -1</pre>
===Steps===
: 1. Move the generated patch to the "linux-yocto" directory :
:: <pre>$ mv 0001-KERNEL-DEV-TEST-CASE.patch [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto/</pre>
: 2. Add the SRC_URI var with the patch to the linux-yocto_4%.bbappend file:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
:: Add the following lines and save and close the file:
:: <pre>SRC_URI += "file://0001-KERNEL-DEV-TEST-CASE.patch"</pre>
:: <pre>FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"</pre>
: 3. Delete the README file:
:: <pre>$ rm build/tmp/work-shared/qemux86-64/kernel-source/README</pre>
: 4. Clean the shared state:
:: <pre>$ cd build</pre>
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 5. Build the patch:
:: <pre>$ bitbake virtual/kernel -c patch</pre>
: 6. Verify the patch is applied properly:
:: <pre>$ tail tmp/work-shared/qemux86-64/kernel-source/README</pre>
===Expected Results===
: 1. Bitbake should complete the build without errors.
: 2. The README file should exist.
: 3. The patch changes should be displayed at the end of the file.

 

==TC_KD_02 – linux-yocto Local Source==
===Use Case===
As a developer, I want to to be able to work with my own Linux kernel sources.
===Prerequisites===
: 1. Have a recipe append file for linux-yocto (created previously).
: 2. Clone in a specific directory (different of poky):
:: <pre>$ cd [KERNEL_REPOS_PATH]</pre>
:: <pre>$ git clone git://git.yoctoproject.org/yocto-kernel-cache</pre>
:: <pre>$ git clone git://git.yoctoproject.org/linux-yocto-[VERSION]</pre>
: 3. Go to the cloned yocto-kernel-cache directory:
:: <pre>$ cd [KERNEL_REPOS_PATH]/yocto-kernel-cache</pre>
:: Checkout the required yocto-version branch:
:: <pre>$ git checkout [yocto-version] # For example: $ git checkout yocto-4.8</pre>
: 4. Go to the linux-yocto-[VERSION] directory:
:: <pre>$ cd [KERNEL_REPOS_PATH]/linux-yocto-[VERSION]</pre>
:: Checkout the standard/base branch:
:: <pre>$ git checkout standard/base</pre>
: 5. Edit the conf/local.conf file in the repository where you are working for execution:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ vi build/conf/local.conf</pre>
:: Set the following line:
:: <pre>PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"</pre>
===Steps===
: 1. Edit the linux-yocto recipe append file previously created at your "meta-kerneltest" directory:
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>
: 2. Clean the shared state:
:: <pre>$ cd build</pre>
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 3. Build the kernel:
:: <pre>$ bitbake virtual/kernel</pre>
: 4. Verify the changes by executing:
:: <pre>$ bitbake virtual/kernel -e | grep "name=machine;branch"</pre>
===Expected Results===
: 1. The changes should be performed successfully.
: 2. The build should be completed successfully.
: 3. The bitbake variables output should display that the SRC_URI variable is now:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>

 
==TC_KD_03 – linux-yocto Custom Local Source==
===Use Case===
As a developer, I want to be able to work with my own local sources for a customized linux-yocto kernel.
===Prerequisites===
: 1. Make sure you have the custom recipe file corresponding to the latest linux-yocto version:
:: <pre>[POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: This file should originate from [POKY_PATH]/meta/recipes-kernel/linux/linux-yocto_[VERSION].bb
: 2. Edit the linux-yocto-custom recipe file:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>
===Steps===
: 1. Go to the poky build directory:
:: <pre>$ cd [POKY_PATH]/build</pre>
: 2. At conf/local.conf add the following variable:
:: <pre>PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
: 3. Clean the shared state:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 4. Compile the kernel:
:: <pre>$ bitbake virtual/kernel</pre>
: 5. Verify the changes by executing:
:: <pre>$ bitbake virtual/kernel -e | grep PREFERRED_PROVIDER_virtual/kernel</pre>
===Expected Results===
: 1. The variable "PREFERRED_PROVIDER_virtual/kernel" should be set successfully.
: 2. Compilation process should be performed successfully.

 
==TC_KD_04 – Local Parallel Meta==
===Use Case===
As a developer, I want to be able to work with local source with parallel meta.
===Prerequisites===
: 1. Edit the linux-yocto-custom recipe file:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>
: 2. Go to the poky build directory:
:: <pre>$ cd [POKY_PATH]/build</pre>
: 3. At conf/local.conf add the following variable:
:: <pre>PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
: 4. Clean the shared state:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 5. Execute the kernel configuration task:
:: <pre>$ bitbake virtual/kernel -c kernel_configme</pre>
: 6. Verify that CONFIG_WIMAX option is not set at:
:: <pre>tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config</pre>
: 7. Set parallel-meta for linux-yocto-custom, adding a specific fragment:
:: 7.1. Create four directories --"files", "parallel-kmeta","features" and "wimax"-- to work with parallel meta:
::: <pre>$ cd [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/</pre>
::: <pre>$ mkdir -p files/parallel-kmeta/features/wimax</pre>
:: 7.2. Inside "wimax" directory create two files: wimax.cfg and wimax.scc:
::: <pre>$ cd files/parallel-kmeta/features/wimax</pre>
::: <pre>$ touch wimax.cfg wimax.scc</pre>
:: 7.3. Inside wimax.cfg add the following configuration:
::: <pre>CONFIG_WIMAX=y</pre>
:: 7.4. Inside wimax.scc add the following lines:
::: <pre>define KFEATURE_DESCRIPTION "WiMAX Wireless Broadband support"</pre>
::: <pre>define KFEATURE_COMPATIBILITY board</pre>
::: <pre></pre>
::: <pre>kconf hardware wimax.cfg</pre>

===Steps===
: 1. Edit the linux-yocto-custom recipe file:
:: <pre>$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>
:: Add the fragment by setting the next line:
:: <pre>KERNEL_FEATURES_append = " features/wimax/wimax.scc"</pre>
: 2. Edit conf/local.conf
:: <pre>$ cd [POKY_PATH]/build/</pre>
:: <pre>$ vi conf/local.conf</pre>
:: Set the following variable:
:: <pre>PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
: 3. Clean the shared state:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 4. Execute the kernel configuration task:
:: <pre>$ bitbake virtual/kernel -c kernel_configme</pre>
:: Note: The build should fail at this step with an error indicating the "wimax.scc" fragment is not found.
: 4. Edit the linux-yocto-custom recipe file:
:: <pre>$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}; \</pre>
:: <pre> file://parallel-kmeta;protocol=file;type=kmeta;name=p-kmeta;destsuffix=parallel-kmeta"</pre>
: 4. Execute the kernel configuration task:
:: <pre>$ bitbake virtual/kernel -c kernel_configme</pre>
: 6. Verify that CONFIG_WIMAX=y option was set properly at:
:: <pre>tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config</pre>
: 7. Verify the variables are set succesfully using:
:: <pre>$ bitbake virtual/kernel -e | grep -E "PREFERRED_PROVIDER_virtual/kernel|SRC_URI"</pre>
===Expected Results===
: 1. The variables should be set successfully.
: 2. The fragment should be added properly.
: 3. Compilation process should be performed successfully.
: 4. CONFIG_WIMAX=y option should be set properly in the .config file after executing the kernel configuration task.

==TC_KD_05 – Recipe-space Meta==
===Use Case===
As a developer, I want to be able to work with recipe-space meta.
===Prerequisites===
: 1. Edit the linux-yocto-custom recipe file:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>
:: Ensure the following value is not set:
:: <pre>SRC_URI_append = " file://pwm-test.scc"</pre>
: 2. At build/conf/local.conf add the following variable:
:: <pre>PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
: 3. Clean the shared state:
:: <pre>$ cd [POKY_PATH]/build</pre>
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 4. Compile the kernel:
:: <pre>$ bitbake virtual/kernel</pre>
: 5. Verify that CONFIG_PWM option is not set at:
:: <pre>tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config</pre>
: 6. Create the files pwm-test.cfg and pwm-test.scc on meta-kerneltest in the linux-yocto-custom directory:
:: <pre>$ cd [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom</pre>
:: <pre>$ touch pwm-test.cfg pwm-test.scc</pre>
:: 6.1. Inside pwm-test.cfg include the line:
::: <pre>CONFIG_PWM=y</pre>
:: 6.2. Inside pwm-test.scc include the following information:
::: <pre>define KFEATURE_DESCRIPTION "Enable core options for PWM support - TC_KD_recipe-space_meta"</pre>
::: <pre>define KFEATURE_COMPATIBILITY board</pre>
::: <pre></pre>
::: <pre>kconf hardware pwm-test.cfg</pre>
===Steps===
: 1. Edit the linux-yocto-custom recipe:
:: <pre>$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb</pre>
:: Add the following variable:
:: <pre>SRC_URI_append = " file://pwm-test.scc"</pre>
: 2. Edit local.conf:
:: <pre>$ cd [POKY_PATH]/build</pre>
:: <pre>$ vi conf/local.conf</pre>
:: Set the following variables:
:: <pre>PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"</pre>
:: <pre>PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
: 3. Clean the shared state:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 4. Compile the kernel:
:: <pre>$ bitbake virtual/kernel</pre>
: 5. Verify that CONFIG_PWM=y option was set properly at:
:: <pre>tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config</pre>
===Expected Results===
: 1. The variables should be set successfully.
: 2. Compilation process should be performed successfully.
: 3. CONFIG_PWM=y option should be set properly in the .config file.
===Remarks===
: 1. If the PWM feature is included on a build by default, verify on the following link a feature that is not included, and use it instead, updating the test case for future reference:
:: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/features

 
==TC_KD_06 – External Source==
===Use Case===
As a developer, I want to be able to work with external sources.
===Prerequisites===
: 1. Open a new terminal, different than the one being used for executing the testing steps.
: 2. Create git bare repositories of Linux sources and cache:
:: 2.1. Create and go to an empty directory (outside the poky repository) to set is at the root to publish git repositories:
::: <pre>$ mkdir -p [GIT_REPOS_PATH]</pre>
::: <pre>$ cd [GIT_REPOS_PATH]</pre>
:: 2.2. Inside the directory, type the following commands to clone the bare repositories:
::: <pre>$ git clone --bare git://git.yoctoproject.org/linux-yocto-[VERSION]</pre>
::: <pre>$ git clone --bare git://git.yoctoproject.org/yocto-kernel-cache</pre>
:: 2.3. Execute the following command to launch the git daemon and leave it running:
::: <pre>$ git daemon --reuseaddr --base-path=. --export-all –verbose</pre>
:: 2.4. Obtain the local git server IP and take note of it:
::: <pre>$ sudo /sbin/ifconfig</pre>
: 3. Return to the terminal being used for executing the testing steps.
: 4. Unset the git proxy environment variable:
:: <pre>$ unset GIT_PROXY_COMMAND</pre>
:: Verify the variable was unset with:
:: <pre>$ echo $GIT_PROXY_COMMAND</pre>
: 5. Ensure the git daemon is working:
:: 5.1. Go to any directory were you can test cloning from your local git repository.
:: 5.2. Verify that the git daemon responds and allows cloning the repo using the following command:
::: <pre>git clone git://[IP_OF_YOUR_LOCAL_REPO]/linux-yocto-[VERSION].git</pre>
:: 5.3. After confirming the daemon is working, delete the cloned repository:
::: <pre>$ rm linux-yocto-[VERSION] -rf</pre>
: 6. Go to the test poky build repository:
:: <pre>$ cd [POKY_PATH]/build</pre>
: 7. Make sure to comment or remove the following line on conf/local.conf:
:: <pre># PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
:: Also, ensure the following line is set on the same file:
:: <pre>PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"</pre>

===Steps===
: 1. Edit the linux-yocto recipe append file previously created at your "meta-kerneltest" directory:
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
:: Set the SRC_URI variable with the following information:
:: <pre>SRC_URI = "git://[IP_OF_YOUR_LOCAL_REPO]/linux-yocto-[VERSION].git;name=machine;branch=${KBRANCH}; \</pre>
:: <pre> git://[IP_OF_YOUR_LOCAL_REPO]/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"</pre>
: 2. Clean the shared state:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 3. Execute the fetch task for the kernel:
:: <pre>$ bitbake virtual/kernel -c fetch</pre>
: 4. Set the git proxy environment variable to its previous value, or close and reopen the terminal.
===Expected Results===
: 1. The configuration should be successfully added.
: 2. Compilation should be performed successfully
: 3. The terminal where the daemon was launched should display some information like:
:: <pre>[9243] Connection from IP_LOCAL:PORT</pre>
:: <pre>[9243] Extended attributes (20 bytes) exist <host=IP_LOCAL></pre>
:: <pre>[9243] Request upload-pack for '/linux-yocto-4.9.git'</pre>

 
==TC_KD_07 – defconfig==
===Use Case===
As a developer, I want to be able to generate and change configuration files (defconfig).
===Prerequisites===
: 1. Have a clone of poky.
: 2. Have availability to another machine/server in the same network to use it as reference.
: 3. Make sure to have the same architecture in the reference machine than the Yocto machine to build.
: 4. Edit the local.conf file on the poky repository in the testing machine:
:: <pre>$ cd [POKY_PATH]/build</pre>
:: <pre>$ vi conf/local.conf</pre>
:: Make sure to comment or remove the following line:
:: <pre># PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
:: Ensure the following line is set:
:: <pre>PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"</pre>
:: Set the same architecture than the one of the reference machine. For example, if you have an ubuntu_x86_64 as reference, in local.conf set:
:: <pre>MACHINE = "qemux86-64"</pre>
: 5. Clean the shared state:
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 6. Execute the kernel_configme task:
:: <pre>$ bitbake virtual/kernel -c kernel_configme</pre>
: 7. After the image compilation is completed, in order to have a copy of the original configuration, copy the .config file from:
:: <pre>[POKY_PATH]/build/tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config</pre>
:: to:
:: <pre>/home/[USER]/poky-defconfig</pre>

===Steps===
: 1. Set defconfig:
:: 1.1. Open a terminal on your reference machine and copy the config file located at: /boot/config-[VERSION-GENERIC] to the machine where the test poky repository is located. Select a name to identify the reference defconfig:
::: <pre>$ scp /boot/config[VERSION-GENERIC] [USER]@[TEST_MACHINE_IP]:reference-defconfig</pre>
:: 1.2. Return to the terminal on the test machine and copy the reference file to the linux-yocto path in meta-kerneltest with the name defconfig:
::: <pre>$ cp ~/reference-defconfig [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto/defconfig</pre>
: 2. Edit the recipe append file:
:: <pre>$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
:: Remove or comment any existing customization, add the following lines and save and close the file:
:: <pre>FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"</pre>
:: <pre>SRC_URI += "file://defconfig"</pre>
: 3. Clean the shared state:
:: <pre>$ cd [POKY_PATH]/build</pre>
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 4. Execute the kernel_configme task:.
:: <pre>$ bitbake virtual/kernel -c kernel_configme</pre>
: 5. Verify that the output defconfig file is equal to the [DISTRO]-defconfig file saved on step 1.1:
:: <pre>$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/defconfig ~/reference-defconfig</pre>
: 6. Verify the output config file is based on the reference defconfig, by comparing both to identify similarities between them:
:: <pre>$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config ~/reference-defconfig</pre>
: 7. Verify the output config file has many more differences with the original defconfig file saved as part of the prerequisites:
:: <pre>$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config ~/poky-defconfig</pre>
: 8. Clean the build environment:
:: <pre>$ bitbake virtual/kernel -c cleanall</pre>
===Expected Results===
: 1. The variable should be set.
: 2. The execution of kernel_configme task should be successful.
: 3. The reference defconfig and output defconfig should be the same.
: 4. The .config and the reference-defconfig files should be similar.
: 5. The .config and the original poky-defconfig files should have several more differences than when compared with the reference-defconfig file.

 
==TC_KD_08 – defconfig Fragments==
===Use Case===
As a developer, I want to be able to generate and change configuration files (defconfig + fragments).
===Prerequisites===
: 1. Same prerequisites than [[#Prerequisites_7|TC_KD_07]].
===Steps===
: 1. Apply steps 1 to 4 from the [[#Steps_7|TC_KD_07]] test case.
: 2. Verify that CONFIG_EXT2_FS option is not set at:
:: <pre>tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config</pre>
: 3. Edit the recipe append file:
:: <pre>$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
:: Add the following line and save and close the file:
:: <pre>SRC_URI += "file://fragment.cfg"</pre>
: 4. Create fragment.cfg file under the linux-yocto directory:
:: <pre>$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto/fragment.cfg</pre>
:: Add the following line inside and save and close the file:
:: <pre>CONFIG_EXT2_FS=y</pre>
: 5. Clean the shared state:
:: <pre>$ cd [POKY_PATH]/build</pre>
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 6. Execute the kernel_configme task:.
:: <pre>$ bitbake virtual/kernel -c kernel_configme</pre>
: 7. Verify that the output defconfig file is equal to the [DISTRO]-defconfig file saved on step 1.1:
:: <pre>$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/defconfig ~/reference-defconfig</pre>
: 8. Verify the output config file is based on the reference defconfig, and confirm the configuration fragment has been applied correctly:
:: <pre>$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config ~/reference-defconfig</pre>
: 9. Clean the build environment:
:: <pre>$ bitbake virtual/kernel -c cleanall</pre>
===Expected Results===
: 1. The fragment file should be appended to the SRC_URI variable.
: 2. The execution of kernel_configme task should be successful.
: 3. The reference defconfig and output defconfig should be the same.
: 4. The .config and the reference-defconfig files should be similar, and .config should contain the configuration option from the fragment (CONFIG_EXT2_FS=y).

 
==TC_KD_09 – linux-yocto Meta Data and Local Fragments==
===Use Case===
As a developer, I want to be able to configure linux-yocto meta data + local fragments.
===Prerequisites===
: TBD, MUST HAVE REPOSITORY OF YOCTO KERNEL CACHE.
===Steps===
: TBD.
===Expected Results===
: TBD.

 

==TC_KD_10 – Building hello-mod==
===Use Case===
As a developer, I want to be able to build external modules (hello-mod).
===Prerequisites===
: 1. Copy the hello-mod directory from meta-skeleton to meta-kerneltest:
:: <pre>$ cp -r [POKY_PATH]/meta-skeleton/recipes-kernel/hello-mod [POKY_PATH]/meta-kerneltest/recipes-kernel/</pre>
: 2. Make sure to comment or remove the following line on conf/local.conf:
:: <pre># PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"</pre>
:: Also, ensure the following line is set on the same file:
:: <pre>PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"</pre>
===Steps===
: 1. Set the hello module variable information on conf/local.conf (in your testing build environment), with the following line:
:: <pre>MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-hello"</pre>
: 2. Edit the linux-yocto recipe append file:
:: <pre>$ cd [POKY_PATH]</pre>
:: <pre>$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend</pre>
:: Make sure you have only the following line, and save and close the file:
:: <pre>FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"</pre>
: 3. Clean the shared state:
:: <pre>$ cd [POKY_PATH]/build</pre>
:: <pre>$ bitbake virtual/kernel -c cleansstate</pre>
: 4. Compile the hello module:
:: <pre>$ bitbake hello-mod</pre>
: 5. Create a minimal image:
:: <pre>$ bitbake core-image-minimal</pre>
: 6. Boot the image using qemu:
:: <pre>$ runqemu nographic</pre>
:: 6.1. Once the qemu terminal is ready, verify on it that the hello module was successfully added:
::: <pre>$ modprobe hello</pre>
:: 6.2. Remove the hello module:
::: <pre>$ rmmod hello</pre>
:: 6.3. Power off and exit the qemu terminal:
::: <pre>$ poweroff</pre>

===Expected Results===
: 1. The variables should be set successfully.
: 2. Compilation process should be performed successfully.
: 3. Image should be compiled without errors.
: 4. Verify the message "Hello World!"is displayed after executing modprobe on the qemu terminal.
: 5. Verify the message "Goodbye Cruel world!" is displayed after removing the module on the qemu terminal.