From 3b4c9331df58ff6e9574c9f616433518b52ea52d Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 20 Jul 2012 10:24:47 -0700 Subject: documentation/poky-ref-manual/ref-variables.xml: New KMACHINE gloss entry Created a new glossary entry for the KMACHINE variable. I used Bruce Ashfield as my resource for understanding this variable. (From yocto-docs rev: 1069ddb3fe0b3bd00ba651b51419354258ae57d3) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/poky-ref-manual/ref-variables.xml | 88 +++++++++++++++++++++++++ 1 file changed, 88 insertions(+) (limited to 'documentation/poky-ref-manual/ref-variables.xml') diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index f83844e0a7..9a4e56043e 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -1128,6 +1128,94 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" + KMACHINE + + + The machine as known by the kernel. + Sometimes the machine name used by the kernel does not match the machine name + used by the OpenEmbedded build system. + For example, the machine name that the OpenEmbedded build system understands as + qemuarm goes by a different name in the Linux Yocto kernel. + The kernel understands that machine as arm_versatile926ejs. + For cases like these, the KMACHINE variable maps the + kernel machine name to the OpenEmbedded build system machine name. + + + + Kernel machine names are initially defined in the + Yocto Project Kernel in + the meta/cfg/kernel-cache/bsp/<bsp_name>/<bsp-name>-<kernel-type>.scc file. + For example, in the linux-yocto-3.4 kernel in the + meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc file, + has the following: + + define KMACHINE cedartrail + define KTYPE standard + define KARCH i386 + + include ktypes/standard + branch cedartrail + + include cedartrail.scc + + You can see that the kernel understands the machine name for the Cedar Trail BSP as + cedartrail. + + + + If you look in the Cedar Trail BSP layer in the meta-intel source + repository at meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend, + you will find the following statements among others: + + COMPATIBLE_MACHINE_cedartrail = "cedartrail" + KMACHINE_cedartrail = "cedartrail" + KBRANCH_cedartrail = "yocto/standard/cedartrail" + KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc" + KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc" + + COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail" + KMACHINE_cedartrail-nopvr = "cedartrail" + KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail" + KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc" + + The KMACHINE statements in the kernel's append file make sure that + the OpenEmbedded build system and the Yocto Linux kernel understand the same machine + names. + + + + This append file uses two KMACHINE statements. + The first is not really necessary but does ensure that the machine known to the + OpenEmbedded build system as cedartrail maps to the machine + in the kernel also known as cedartrail: + + KMACHINE_cedartrail = "cedartrail" + + + + + The second statement is a good example of why the KMACHINE variable + is needed. + In this example, the OpenEmbedded build system uses the cedartrail-nopvr + machine name to refer to the Cedar Trail BSP that does not support the propriatory + PowerVR driver. + The kernel, however, uses the machine name cedartrail. + Thus, the append file must map the cedartrail-nopvr machine name to + the kernel's cedartrail name: + + KMACHINE_cedartrail-nopvr = "cedartrail" + + + + + BSPs that ship with the Yocto Project release provide all mappings between the Yocto + Project kernel machine names and the OpenEmbedded machine names. + Be sure to use the KMACHINE if you create a BSP and the machine + name you use is different than that used in the kernel. + + + + L -- cgit v1.2.3-54-g00ecf