Kernel Development Test Cases

From Yocto Project
Jump to navigationJump to search

Setup

Common Prerequisites

1. Have a clone of poky:
$ git clone git://git.yoctoproject.org/poky
2. Check out the required commit using git:
$ git checkout [COMMIT_HASH]
3. Source the build environment to create the configuration files:
$ cd [POKY_PATH]
$ . oe-init-build-env
4. Open the conf/local.conf file:
$ vi conf/local.conf
Establish the machine to qemux86-64 by setting the line:
MACHINE = "qemux86-64"
5. Compile a minimal image:
$ bitbake core-image-minimal
6. Get and take note of the linux-yocto kernel version (only the first two numbers, for example: 4.10):
$ bitbake virtual/kernel -e | grep LINUX_VERSION
7. Create a layer to store kernel test metadata. For this task, you could use the yocto-layer script and its default recipe values:
$ cd [POKY_PATH]
$ yocto-layer create [LAYER-NAME]
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:
$ mkdir -p meta-kerneltest/recipes-kernel/linux/
9. Create a recipe append file inside the directory:
$ touch meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
10. Copy the recipe file corresponding to the linux-yocto version inside the directory:
$ cp meta/recipes-kernel/linux/linux-yocto_[VERSION].bb meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
11. Edit the linux-yocto-custom recipe:
$  vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Set the PV variable with the LINUX_VERSION variable value:
PV = "${LINUX_VERSION}"
12. Create directory "linux-yocto":
$ mkdir meta-kerneltest/recipes-kernel/linux/linux-yocto/
13. Create directory "linux-yocto-custom":
$ mkdir meta-kerneltest/recipes-kernel/linux/linux-yocto-custom/
14. Add the created layer to bblayers.conf. For this task, you could use the bitbake-layers script from inside the build directory:
$ cd build
$ bitbake-layers add-layer ../meta-kerneltest

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:
$ bitbake virtual/kernel -c cleansstate
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:
$ cd [POKY_PATH]/build/tmp/work-shared/qemux86-64/kernel-source
1.2. Add some information at the end of the README file:
$ echo This is a test to apply a patch to the kernel. >> README
1.3. Add the modified file to the patch:
$ git add README
1.4. Commit the change:
$ git commit -s -m "KERNEL DEV TEST CASE"
1.5. Format the patch:
$ git format-patch -1

Steps

1. Move the generated patch to the "linux-yocto" directory :
$ mv 0001-KERNEL-DEV-TEST-CASE.patch [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto/
2. Add the SRC_URI var with the patch to the linux-yocto_4%.bbappend file:
$ cd [POKY_PATH]
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
Add the following lines and save and close the file:
SRC_URI += "file://0001-KERNEL-DEV-TEST-CASE.patch"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
3. Delete the README file:
$ rm build/tmp/work-shared/qemux86-64/kernel-source/README
4. Clean the shared state:
$ cd build
$ bitbake virtual/kernel -c cleansstate
5. Build the patch:
$ bitbake virtual/kernel -c patch
6. Verify the patch is applied properly:
$ tail tmp/work-shared/qemux86-64/kernel-source/README

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):
$ cd [KERNEL_REPOS_PATH]
$ git clone git://git.yoctoproject.org/yocto-kernel-cache
$ git clone git://git.yoctoproject.org/linux-yocto-[VERSION]
3. Go to the cloned yocto-kernel-cache directory:
$ cd [KERNEL_REPOS_PATH]/yocto-kernel-cache
Checkout the required yocto-version branch:
$ git checkout [yocto-version]  # For example: $ git checkout yocto-4.8
4. Go to the linux-yocto-[VERSION] directory:
$ cd [KERNEL_REPOS_PATH]/linux-yocto-[VERSION]
Checkout the standard/base branch:
$ git checkout standard/base
5. Edit the conf/local.conf file in the repository where you are working for execution:
$ cd [POKY_PATH]
$ vi build/conf/local.conf
Set the following line:
PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"

Steps

1. Edit the linux-yocto recipe append file previously created at your "meta-kerneltest" directory:
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
Set the SRC_URI variable with the following information:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"
2. Clean the shared state:
$ cd build
$ bitbake virtual/kernel -c cleansstate
3. Build the kernel:
$ bitbake virtual/kernel
4. Verify the changes by executing:
$ bitbake virtual/kernel -e | grep "name=machine;branch"

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:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"


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:
[POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
This file should originate from [POKY_PATH]/meta/recipes-kernel/linux/linux-yocto_[VERSION].bb
2. Edit the linux-yocto-custom recipe file:
$ cd [POKY_PATH]
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Set the SRC_URI variable with the following information:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"

Steps

1. Go to the poky build directory:
$ cd [POKY_PATH]/build
2. At conf/local.conf add the following variable:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
3. Clean the shared state:
$ bitbake virtual/kernel -c cleansstate
4. Compile the kernel:
$ bitbake virtual/kernel
5. Verify the changes by executing:
$ bitbake virtual/kernel -e | grep PREFERRED_PROVIDER_virtual/kernel

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:
$ cd [POKY_PATH]
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Set the SRC_URI variable with the following information:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"
2. Go to the poky build directory:
$ cd [POKY_PATH]/build
3. At conf/local.conf add the following variable:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
4. Clean the shared state:
$ bitbake virtual/kernel -c cleansstate
5. Execute the kernel configuration task:
$ bitbake virtual/kernel -c kernel_configme
6. Verify that CONFIG_WIMAX option is not set at:
tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config
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:
$ cd [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/
$ mkdir -p files/parallel-kmeta/features/wimax
7.2. Inside "wimax" directory create two files: wimax.cfg and wimax.scc:
$ cd files/parallel-kmeta/features/wimax
$ touch wimax.cfg wimax.scc
7.3. Inside wimax.cfg add the following configuration:
CONFIG_WIMAX=y
7.4. Inside wimax.scc add the following lines:
define KFEATURE_DESCRIPTION "WiMAX Wireless Broadband support"
define KFEATURE_COMPATIBILITY board
kconf hardware wimax.cfg

Steps

1. Edit the linux-yocto-custom recipe file:
$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Set the SRC_URI variable with the following information:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"
Add the fragment by setting the next line:
KERNEL_FEATURES_append = " features/wimax/wimax.scc"
2. Edit conf/local.conf
$ cd [POKY_PATH]/build/
$ vi conf/local.conf
Set the following variable:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
3. Clean the shared state:
$ bitbake virtual/kernel -c cleansstate
4. Execute the kernel configuration task:
$ bitbake virtual/kernel -c kernel_configme
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:
$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Set the SRC_URI variable with the following information:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}; \
           file://parallel-kmeta;protocol=file;type=kmeta;name=p-kmeta;destsuffix=parallel-kmeta"
4. Execute the kernel configuration task:
$ bitbake virtual/kernel -c kernel_configme
6. Verify that CONFIG_WIMAX=y option was set properly at:
tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config
7. Verify the variables are set succesfully using:
$ bitbake virtual/kernel -e | grep -E "PREFERRED_PROVIDER_virtual/kernel|SRC_URI"

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:
$ cd [POKY_PATH]
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Set the SRC_URI variable with the following information:
SRC_URI = "git://[KERNEL_REPOS_PATH]/linux-yocto-[VERSION];protocol=file;name=machine;branch=${KBRANCH}; \
           git://[KERNEL_REPOS_PATH]/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"
Ensure the following value is not set:
SRC_URI_append = " file://pwm-test.scc"
2. At build/conf/local.conf add the following variable:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
3. Clean the shared state:
$ cd [POKY_PATH]/build
$ bitbake virtual/kernel -c cleansstate
4. Compile the kernel:
$ bitbake virtual/kernel
5. Verify that CONFIG_PWM option is not set at:
tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config
6. Create the files pwm-test.cfg and pwm-test.scc on meta-kerneltest in the linux-yocto-custom directory:
$ cd [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom
$ touch pwm-test.cfg pwm-test.scc
6.1. Inside pwm-test.cfg include the line:
CONFIG_PWM=y
6.2. Inside pwm-test.scc include the following information:
define KFEATURE_DESCRIPTION "Enable core options for PWM support - TC_KD_recipe-space_meta"
define KFEATURE_COMPATIBILITY board
kconf hardware pwm-test.cfg

Steps

1. Edit the linux-yocto-custom recipe:
$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto-custom_[VERSION].bb
Add the following variable:
SRC_URI_append = " file://pwm-test.scc"
2. Edit local.conf:
$ cd [POKY_PATH]/build
$ vi conf/local.conf
Set the following variables:
PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
3. Clean the shared state:
$ bitbake virtual/kernel -c cleansstate
4. Compile the kernel:
$ bitbake virtual/kernel
5. Verify that CONFIG_PWM=y option was set properly at:
tmp/work/qemux86_64-poky-linux/linux-yocto-custom/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config

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:
$ mkdir -p [GIT_REPOS_PATH]
$ cd [GIT_REPOS_PATH]
2.2. Inside the directory, type the following commands to clone the bare repositories:
$ git clone --bare git://git.yoctoproject.org/linux-yocto-[VERSION]
$ git clone --bare git://git.yoctoproject.org/yocto-kernel-cache
2.3. Execute the following command to launch the git daemon and leave it running:
$ git daemon --reuseaddr --base-path=. --export-all –verbose
2.4. Obtain the local git server IP and take note of it:
$ sudo /sbin/ifconfig
3. Return to the terminal being used for executing the testing steps.
4. Unset the git proxy environment variable:
$ unset GIT_PROXY_COMMAND
Verify the variable was unset with:
$ echo $GIT_PROXY_COMMAND
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:
git clone git://[IP_OF_YOUR_LOCAL_REPO]/linux-yocto-[VERSION].git
5.3. After confirming the daemon is working, delete the cloned repository:
$ rm linux-yocto-[VERSION] -rf
6. Go to the test poky build repository:
$ cd [POKY_PATH]/build
7. Make sure to comment or remove the following line on conf/local.conf:
# PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
Also, ensure the following line is set on the same file:
PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"

Steps

1. Edit the linux-yocto recipe append file previously created at your "meta-kerneltest" directory:
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
Set the SRC_URI variable with the following information:
SRC_URI = "git://[IP_OF_YOUR_LOCAL_REPO]/linux-yocto-[VERSION].git;name=machine;branch=${KBRANCH}; \
           git://[IP_OF_YOUR_LOCAL_REPO]/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-[VERSION];destsuffix=${KMETA}"
2. Clean the shared state:
$ bitbake virtual/kernel -c cleansstate
3. Execute the fetch task for the kernel:
$ bitbake virtual/kernel -c fetch
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:
[9243] Connection from IP_LOCAL:PORT
[9243] Extended attributes (20 bytes) exist <host=IP_LOCAL>
[9243] Request upload-pack for '/linux-yocto-4.9.git'


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:
$ cd [POKY_PATH]/build
$ vi conf/local.conf
Make sure to comment or remove the following line:
# PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
Ensure the following line is set:
PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"
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:
MACHINE = "qemux86-64"
5. Clean the shared state:
$ bitbake virtual/kernel -c cleansstate
6. Execute the kernel_configme task:
$ bitbake virtual/kernel -c kernel_configme
7. After the image compilation is completed, in order to have a copy of the original configuration, copy the .config file from:
[POKY_PATH]/build/tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config
to:
/home/[USER]/poky-defconfig

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:
$ scp /boot/config[VERSION-GENERIC] [USER]@[TEST_MACHINE_IP]:reference-defconfig
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:
$ cp ~/reference-defconfig [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto/defconfig
2. Edit the recipe append file:
$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
Remove or comment any existing customization, add the following lines and save and close the file:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig"
3. Clean the shared state:
$ cd [POKY_PATH]/build
$ bitbake virtual/kernel -c cleansstate
4. Execute the kernel_configme task:.
$ bitbake virtual/kernel -c kernel_configme
5. Verify that the output defconfig file is equal to the [DISTRO]-defconfig file saved on step 1.1:
$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/defconfig ~/reference-defconfig
6. Verify the output config file is based on the reference defconfig, by comparing both to identify similarities between them:
$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config ~/reference-defconfig
7. Verify the output config file has many more differences with the original defconfig file saved as part of the prerequisites:
$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config ~/poky-defconfig
8. Clean the build environment:
$ bitbake virtual/kernel -c cleanall

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 TC_KD_07.

Steps

1. Apply steps 1 to 4 from the TC_KD_07 test case.
2. Verify that CONFIG_EXT2_FS option is not set at:
tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config
3. Edit the recipe append file:
$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
Add the following line and save and close the file:
SRC_URI += "file://fragment.cfg"
4. Create fragment.cfg file under the linux-yocto directory:
$ vi [POKY_PATH]/meta-kerneltest/recipes-kernel/linux/linux-yocto/fragment.cfg
Add the following line inside and save and close the file:
CONFIG_EXT2_FS=y
5. Clean the shared state:
$ cd [POKY_PATH]/build
$ bitbake virtual/kernel -c cleansstate
6. Execute the kernel_configme task:.
$ bitbake virtual/kernel -c kernel_configme
7. Verify that the output defconfig file is equal to the [DISTRO]-defconfig file saved on step 1.1:
$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/defconfig ~/reference-defconfig
8. Verify the output config file is based on the reference defconfig, and confirm the configuration fragment has been applied correctly:
$ vimdiff tmp/work/qemux86_64-poky-linux/linux-yocto/[VERSION_DESCRIPTOR]/linux-qemux86_64-standard-build/.config ~/reference-defconfig
9. Clean the build environment:
$ bitbake virtual/kernel -c cleanall

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:
$ cp -r [POKY_PATH]/meta-skeleton/recipes-kernel/hello-mod [POKY_PATH]/meta-kerneltest/recipes-kernel/
2. Make sure to comment or remove the following line on conf/local.conf:
# PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom"
Also, ensure the following line is set on the same file:
PREFERRED_VERSION_linux-yocto_qemux86-64="[VERSION]%"

Steps

1. Set the hello module variable information on conf/local.conf (in your testing build environment), with the following line:
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-hello"
2. Edit the linux-yocto recipe append file:
$ cd [POKY_PATH]
$ vi meta-kerneltest/recipes-kernel/linux/linux-yocto_4%.bbappend
Make sure you have only the following line, and save and close the file:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
3. Clean the shared state:
$ cd [POKY_PATH]/build
$ bitbake virtual/kernel -c cleansstate
4. Compile the hello module:
$ bitbake hello-mod
5. Create a minimal image:
$ bitbake core-image-minimal
6. Boot the image using qemu:
$ runqemu nographic
6.1. Once the qemu terminal is ready, verify on it that the hello module was successfully added:
$ modprobe hello
6.2. Remove the hello module:
$ rmmod hello
6.3. Power off and exit the qemu terminal:
$ poweroff

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.