From 7727a1608a4238d4305eb9493803721b54c3db6a Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 6 Mar 2015 07:57:02 -0800 Subject: [PATCH] ref-manual: Updated the KMACHINE variable description. The example was ancient so I consulted Bruce Ashfield for a better example and implemented it. (From yocto-docs rev: e737f380ca5bb36c0095f11182cd3e3a93791e61) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/ref-variables.xml | 106 ++++++--------------- 1 file changed, 28 insertions(+), 78 deletions(-) diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml index 1135728fd2..a79d8e5bcb 100644 --- a/documentation/ref-manual/ref-variables.xml +++ b/documentation/ref-manual/ref-variables.xml @@ -6085,92 +6085,42 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" 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. + 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 + core2-32-intel-common goes by a + different name in the Linux Yocto kernel. + The kernel understands that machine as + intel-core2-32. + 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 + These mappings between different names occur in the Yocto Linux Kernel's meta branch. - From the meta branch, look in - the meta/cfg/kernel-cache/bsp/<bsp_name>/<bsp-name>-<kernel-type>.scc file. - For example, from the meta branch in the - linux-yocto-3.0 kernel, the - meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc file - has the following: + As an example take a look in the + common/recipes-kernel/linux/linux-yocto_3.19.bbappend + file: - define KMACHINE cedartrail - define KTYPE standard - define KARCH i386 - - include ktypes/standard - branch cedartrail - - include cedartrail.scc + LINUX_VERSION_core2-32-intel-common = "3.19.0" + COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}" + SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974" + SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711" + KMACHINE_core2-32-intel-common = "intel-core2-32" + KBRANCH_core2-32-intel-common = "standard/base" + KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}" - You can see that the kernel understands the machine name for - the Cedar Trail Board Support Package (BSP) as - cedartrail. + The KMACHINE statement says that + the kernel understands the machine name as + "intel-core2-32". + However, the OpenEmbedded build system understands the + machine as "core2-32-intel-common". - - If you look in the Cedar Trail BSP layer in the - meta-intel - Source Repositories - 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 proprietary - 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. -