Transcript: Using the Yocto BSP tools to manage kernel patches and config items

From Yocto Project
Revision as of 02:50, 21 June 2012 by Tzanussi (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Here's a cut-and-paste shell session showing how to use the Yocto BSP 'yocto-kernel' tool to manage kernel patches and config items for a BSP that was created using 'yocto-bsp'. This particular session uses the qemu ARM BSP that was created in the Transcript: Using the Yocto BSP tools to create a qemu BSP.

The 'yocto-kernel' tool allows you to list, add, and remove kernel patches and individual kernel config items to/from a BSP's kernel recipe.

Like the other Yocto BSP tools, you can get help by simply invoking the command or sub-command with no parameters (first we need to source the environment, again this is using the BSP we created in the session linked to by the above link):

trz@elmorro:/usr/local/dev/Yocto$ source oe-init-build-env 

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-toolchain-sdk
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel

Usage: 

 Modify and list Yocto BSP kernel config items and patches.

 usage: yocto-kernel [--version] [--help] COMMAND [ARGS]

 The most commonly used 'yocto-kernel' commands are:
   config list       List the modifiable set of bare kernel config options for a BSP
   config add        Add or modify bare kernel config options for a BSP
   config rm         Remove bare kernel config options from a BSP
   patch list        List the patches associated with a BSP
   patch add         Patch the Yocto kernel for a BSP
   patch rm          Remove patches from a BSP

 See 'yocto-kernel help COMMAND' for more information on a specific command.
 


Options:
  --version    show program's version number and exit
  -h, --help   show this help message and exit
  -D, --debug  output debug information


Let's start by adding a patch. Here's the patch we'll add: [yocto-testmod.patch: https://wiki.yoctoproject.org/wiki/images/c/c9/Yocto-testmod.patch] NOTE: You should use the patch in the link - scraping the screen from below will result in a patch with whitespace differences that won't apply:

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6a1a092..b6165b6 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -392,6 +392,11 @@ config HMC6352
          This driver provides support for the Honeywell HMC6352 compass,
          providing configuration and heading data via sysfs.
 
+config YOCTO_TESTMOD
+       tristate "Yocto Test Driver"
+       help
+         This driver provides a silly message for testing Yocto.
+
 config EP93XX_PWM
        tristate "EP93xx PWM support"
        depends on ARCH_EP93XX
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 3e1d801..11384d8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_TI_DAC7512)      += ti_dac7512.o
 obj-$(CONFIG_C2PORT)           += c2port/
 obj-$(CONFIG_IWMC3200TOP)      += iwmc3200top/
 obj-$(CONFIG_HMC6352)          += hmc6352.o
+obj-$(CONFIG_YOCTO_TESTMOD)    += yocto-testmod.o
 obj-y                          += eeprom/
 obj-y                          += cb710/
 obj-$(CONFIG_SPEAR13XX_PCIE_GADGET)    += spear13xx_pcie_gadget.o
diff --git a/drivers/misc/yocto-testmod.c b/drivers/misc/yocto-testmod.c
new file mode 100644
index 0000000..81de912
--- /dev/null
+++ b/drivers/misc/yocto-testmod.c
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2012 Intel Corporation
+ * Authored-by:  Tom Zanussi <tom.zanussi@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/module.h>
+
+static int __init yocto_testmod_init(void)
+{
+       printk("Kilroy was here! __m_(OuO)_m__");
+}
+
+static void __exit yocto_testmod_exit(void)
+{
+       printk("Kilroy was not here!");
+}
+
+module_init(yocto_testmod_init);
+module_exit(yocto_testmod_exit);
+
+MODULE_AUTHOR("Tom Zanussi <tom.zanussi@intel.com");
+MODULE_DESCRIPTION("Yocto Test Driver");
+MODULE_LICENSE("GPL");

First, let's list the current set of patches associated with the BSP. Again, we'll use the built-in help to remind ourselves of the syntax for that:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch list

Usage: 

 List the patches associated with the kernel for a BSP

 usage: yocto-kernel patch list <bsp-name>

 This command lists the patches associated with a BSP.

 NOTE: this only applies to patches listed in the kernel recipe's
 user-patches.scc file (and currently repeated in its SRC_URI).


Options:
  -h, --help  show this help message and exit

The name of our BSP is qemuarm, so we can list the current set of patches like this:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch list myqemuarm
The current set of machine-specific patches for myqemuarm is:

As we can see, there are no patches listed, as we'd expect.

Let's see the syntax for adding a patch:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch add

Usage: 

Patch the Yocto kernel for a specific BSP

usage: yocto-kernel patch add <bsp-name> [<PATCH> ...]

This command adds one or more patches to a BSP's machine branch.  The
patch will be added to the BSP's linux-yocto kernel user-patches.scc
file (and currently repeated in its SRC_URI) and will be guaranteed
to be applied in the order specified.

Options:
 -h, --help  show this help message and exit

So using the add subcommand as follows, we can add our patch:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch add myqemuarm /home/trz/newpatches/yocto-testmod.patch 
Added patches:
	yocto-testmod.patch

Let's verify that the patch was added:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch list myqemuarm
The current set of machine-specific patches for myqemuarm is:
	1) yocto-testmod.patch

So apparently it was. If you look at the patch, you can see that it adds new code as a module under 'misc devices'. In order to get it built in to the kernel, we need to enable a couple options, one to enable misc devices, and another to enable our particular module.

We can do that using analagous 'yocto-kernel config' subcommands. First, let's see if we already have any BSP-specific config options enabled for our BSP:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config list myqemuarm
The current set of machine-specific kernel config items for myqemuarm is:
	1) CONFIG_FTRACE_SYSCALLS=y
	2) CONFIG_SCHED_TRACER=y
	3) CONFIG_IRQSOFF_TRACER=y
	4) CONFIG_PREEMPT_TRACER=y

We do - these are a small set of BSP-specific options that were added by the BSP template that generated the BSP.

Let's add to these our two options:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config add myqemuarm CONFIG_MISC_DEVICES=y
Added items:
	CONFIG_MISC_DEVICES=y
trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config add myqemuarm CONFIG_YOCTO_TESTMOD=y
Added items:
	CONFIG_YOCTO_TESTMOD=y

Now let's verify that they were added:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config list myqemuarm
The current set of machine-specific kernel config items for myqemuarm is:
	1) CONFIG_FTRACE_SYSCALLS=y
	2) CONFIG_SCHED_TRACER=y
	3) CONFIG_IRQSOFF_TRACER=y
	4) CONFIG_PREEMPT_TRACER=y
	5) CONFIG_MISC_DEVICES=y
	6) CONFIG_YOCTO_TESTMOD=y

Now that we've successfully added the patch and associated config items, we can rebuild with the new code and settings, reboot, and we should find our string 'Kilroy was here! __m_(OuO)_m__' in the dmesg log (simply open up a terminal window and type 'dmesg | egrep Kilroy' and you should see the string if everything went as expected).

trz@elmorro:/usr/local/dev/Yocto/build$ bitbake core-image-sato
trz@elmorro:/usr/local/dev/Yocto/build$ runqemu qemuarm tmp/deploy/images/zImage-myqemuarm.bin  tmp/deploy/images/core-image-sato-myqemuarm.ext3

We can also use 'yocto-kernel' to remove kernel patches and config items. Let's use it to remove the patch and config items we just added.

Let's first remove the patch:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch rm myqemuarm
Specify the patches to remove:
	1) yocto-testmod.patch
1
Removed patches:
	yocto-testmod.patch

And let's verify that it was removed:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel patch list myqemuarm
The current set of machine-specific patches for myqemuarm is:

Let's do the same for the config items:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config rm myqemuarmSpecify the kernel config items to remove:
	1) CONFIG_FTRACE_SYSCALLS=y
	2) CONFIG_SCHED_TRACER=y
	3) CONFIG_IRQSOFF_TRACER=y
	4) CONFIG_PREEMPT_TRACER=y
	5) CONFIG_MISC_DEVICES=y
	6) CONFIG_YOCTO_TESTMOD=y
5
Removed items:
	CONFIG_MISC_DEVICES=y

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config rm myqemuarm
Specify the kernel config items to remove:
	1) CONFIG_FTRACE_SYSCALLS=y
	2) CONFIG_SCHED_TRACER=y
	3) CONFIG_IRQSOFF_TRACER=y
	4) CONFIG_PREEMPT_TRACER=y
	5) CONFIG_YOCTO_TESTMOD=y
5
Removed items:
	CONFIG_YOCTO_TESTMOD=y

And let's also verify that those are now gone:

trz@elmorro:/usr/local/dev/Yocto/build$ yocto-kernel config list myqemuarm
The current set of machine-specific kernel config items for myqemuarm is:
	1) CONFIG_FTRACE_SYSCALLS=y
	2) CONFIG_SCHED_TRACER=y
	3) CONFIG_IRQSOFF_TRACER=y
	4) CONFIG_PREEMPT_TRACER=y

The appear to be. Rebuilding and booting should show that Kilroy has left (i.e. open a terminal window and typing 'dmesg | egrep Kilroy' should now show nothing again).