Kernel Development Test Cases: Difference between revisions
(→Steps) |
|||
Line 486: | Line 486: | ||
: 5. Create a minimal image: | : 5. Create a minimal image: | ||
:: <pre>$ bitbake core-image-minimal</pre> | :: <pre>$ bitbake core-image-minimal</pre> | ||
: 6. Boot the image using | : 6. Boot the image using QEMU: | ||
:: <pre>$ runqemu nographic core-image-minimal</pre> | :: <pre>$ runqemu nographic core-image-minimal</pre> | ||
:: 6.1. Once the qemu terminal is ready, verify on it that the hello module was successfully added: | :: 6.1. Once the qemu terminal is ready, verify on it that the hello module was successfully added: |
Revision as of 17:41, 25 October 2017
Document Conventions
- 1. In command and configuration snippets that exist on the rest of the document, words or short phrases that appear in uppercase letters and enclosed on square brackets (for example, [VERSION]) are placeholders that need to be manually replaced by their correct value, depending on the context.
- 2. In command snippets, the dollar symbol and subsequent space at the beginning of the line indicates the command line prompt. This two characters should not be used when entering the command.
- 3. Other characters should be left as they appear on command or configuration sentences.
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
- 1.1. Go to kernel source directory:
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
- 7.1. Create four directories --"files", "parallel-kmeta","features" and "wimax"-- to work with parallel meta:
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. Compilation process should be performed successfully.
- 3. CONFIG_WIMAX=y option should be set properly in the .config file after executing the kernel configuration task.
Remarks
- 1. If the WIMAX 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:
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:
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
- 2.1. Create and go to an empty directory (outside the poky repository) to set is at the root to publish git repositories:
- 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
- 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:
- 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).
Remarks
- 1. If the EXT2_FS 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:
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 core-image-minimal
- 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.
References
- http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html
- http://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html
Compendium of Yocto Project manuals, including the two above: