From 28b6aabbda57b1b0e18d0c3859c2ec4bb681a370 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 27 Dec 2012 16:01:45 -0600 Subject: kernel-dev: Initial edits to the kernel-dev-faq.xml chapter. (From yocto-docs rev: c76898ec961cc741c6f67448b1227111ef34dbaa) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/kernel-dev/kernel-dev-faq.xml | 573 +++------------------------- 1 file changed, 49 insertions(+), 524 deletions(-) (limited to 'documentation') diff --git a/documentation/kernel-dev/kernel-dev-faq.xml b/documentation/kernel-dev/kernel-dev-faq.xml index 176573de28..3cd137d9cc 100644 --- a/documentation/kernel-dev/kernel-dev-faq.xml +++ b/documentation/kernel-dev/kernel-dev-faq.xml @@ -2,30 +2,20 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ %poky; ] > - -FAQ + +Kernel Development FAQ - How does Poky differ from OpenEmbedded? + How do I use my own Linux kernel .config + file? - The term "Poky" refers to the specific reference build system that - the Yocto Project provides. - Poky is based on OE-Core - and BitBake. - Thus, the generic term used here for the build system is - the "OpenEmbedded build system." - Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with - changes always being merged to OE-Core or BitBake first before being pulled back - into Poky. - This practice benefits both projects immediately. - For a fuller description of the term "Poky", see the - poky term in the Yocto Project - Development Manual. + Refer to the "Changing the Configuration" + section for information. @@ -33,143 +23,13 @@ - I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7. - Can I still use the Yocto Project? + How do I create configuration fragments? - You can use a stand-alone tarball to provide Python 2.6. - You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations: - - 32-bit tarball - 64-bit tarball - - - - These tarballs are self-contained with all required libraries and should work - on most Linux systems. - To use the tarballs extract them into the root - directory and run the appropriate command: - - $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH - $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH - - - - Once you run the command, BitBake uses Python 2.6. - - - - - - - - How can you claim Poky / OpenEmbedded-Core is stable? - - - - - There are three areas that help with stability; - - The Yocto Project team keeps - OE-Core small - and focused, containing around 830 recipes as opposed to the thousands - available in other OpenEmbedded community layers. - Keeping it small makes it easy to test and maintain. - The Yocto Project team runs manual and automated tests - using a small, fixed set of reference hardware as well as emulated - targets. - The Yocto Project uses an an autobuilder, - which provides continuous build and integration tests. - - - - - - - - - How do I get support for my board added to the Yocto Project? - - - - - Support for an additional board is added by creating a BSP layer for it. - For more information on how to create a BSP layer, see the - Yocto Project Board Support Package (BSP) Developer's Guide. - - - Usually, if the board is not completely exotic, adding support in - the Yocto Project is fairly straightforward. - - - - - - - - Are there any products built using the OpenEmbedded build system? - - - - - The software running on the Vernier LabQuest - is built using the OpenEmbedded build system. - See the Vernier LabQuest - website for more information. - There are a number of pre-production devices using the OpenEmbedded build system - and the Yocto Project team - announces them as soon as they are released. - - - - - - - - What does the OpenEmbedded build system produce as output? - - - - - Because the same set of recipes can be used to create output of various formats, the - output of an OpenEmbedded build depends on how it was started. - Usually, the output is a flashable image ready for the target device. - - - - - - - - How do I add my package to the Yocto Project? - - - - - To add a package, you need to create a BitBake recipe. - For information on how to add a package, see the section - "Adding a Package" - in the Yocto Project Development Manual. - - - - - - - - Do I have to reflash my entire board with a new Yocto Project image when recompiling - a package? - - - - - The OpenEmbedded build system can build packages in various formats such as - ipk for opkg, - Debian package (.deb), or RPM. - The packages can then be upgraded using the package tools on the device, much like - on a desktop distribution such as Ubuntu or Fedora. + Refer to the "Generating Configuration Files" + section for information. @@ -177,16 +37,13 @@ - What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME? + How do I use my own Linux kernel sources? - GNOME Mobile is a subset of the GNOME - platform targeted at mobile and embedded devices. - The the main difference between GNOME Mobile and standard GNOME is that - desktop-orientated libraries have been removed, along with deprecated libraries, - creating a much smaller footprint. + Refer to the "Working With Your Own Sources" + section for information. @@ -194,14 +51,22 @@ - I see the error 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'. - What is wrong? + How do I install/not-install the kernel image on the rootfs? - You are probably running the build on an NTFS filesystem. - Use ext2, ext3, or ext4 instead. + The kernel image (e.g. vmlinuz) is provided + by the kernel-image package. + Image recipes depend on kernel-base. + To specify whether or not the kernel + image is installed in the generated root filesystem, override + RDEPENDS_kernel-base to include or not + include "kernel-image". + See the + "Using .bbappend Files" + section in the Yocto Project Development Manual for information on + how to use an append file to override metadata. @@ -209,175 +74,33 @@ - How do I make the Yocto Project work in RHEL/CentOS? + How do I install a specific kernel module? - To get the Yocto Project working under RHEL/CentOS 5.1 you need to first - install some required packages. - The standard CentOS packages needed are: - - "Development tools" (selected during installation) - texi2html - compat-gcc-34 - - On top of these, you need the following external packages: - - python-sqlite2 from - DAG repository - - help2man from - Karan repository - - - - - Once these packages are installed, the OpenEmbedded build system will be able - to build standard images. - However, there might be a problem with the QEMU emulator segfaulting. - You can either disable the generation of binary locales by setting - ENABLE_BINARY_LOCALE_GENERATION - to "0" or by removing the linux-2.6-execshield.patch - from the kernel and rebuilding it since that is the patch that causes the problems with QEMU. - - - - - - - - I see lots of 404 responses for files on - http://www.yoctoproject.org/sources/*. Is something wrong? - - - - - Nothing is wrong. - The OpenEmbedded build system checks any configured source mirrors before downloading - from the upstream sources. - The build system does this searching for both source archives and - pre-checked out versions of SCM managed software. - These checks help in large installations because it can reduce load on the SCM servers - themselves. - The address above is one of the default mirrors configured into the - build system. - Consequently, if an upstream source disappears, the team - can place sources there so builds continue to work. - - - - - - - - I have machine-specific data in a package for one machine only but the package is - being marked as machine-specific in all cases, how do I prevent this? - - - - - Set SRC_URI_OVERRIDES_PACKAGE_ARCH - = "0" in the .bb file but make sure the package is - manually marked as - machine-specific in the case that needs it. - The code that handles SRC_URI_OVERRIDES_PACKAGE_ARCH is in base.bbclass. - - - - - - - - I'm behind a firewall and need to use a proxy server. How do I do that? - - - - - Most source fetching by the OpenEmbedded build system is done by wget - and you therefore need to specify the proxy settings in a - .wgetrc file in your home directory. - Example settings in that file would be + Linux kernel modules are packaged individually. + To ensure a specific kernel module is included in an image, + include it in the appropriate machine + RRECOMMENDS + variable. + These other variables are useful for installing specific + modules: - http_proxy = http://proxy.yoyodyne.com:18023/ - ftp_proxy = http://proxy.yoyodyne.com:18023/ + MACHINE_ESSENTIAL_EXTRA_RDEPENDS + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS + MACHINE_EXTRA_RDEPENDS + MACHINE_EXTRA_RRECOMMENDS - The Yocto Project also includes a site.conf.sample - file that shows how to configure CVS and Git proxy servers - if needed. - - - - - - - - What’s the difference between foo and foo-native? - - - - - The *-native targets are designed to run on the system - being used for the build. - These are usually tools that are needed to assist the build in some way such as - quilt-native, which is used to apply patches. - The non-native version is the one that runs on the target device. - - - - - - - - I'm seeing random build failures. Help?! - - - - - If the same build is failing in totally different and random ways, - the most likely explanation is that either the hardware you're running the - build on has some problem, or, if you are running the build under virtualisation, - the virtualisation probably has bugs. - The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and - CPU activity and is sensitive to even single bit failures in any of these areas. - True random failures have always been traced back to hardware or virtualisation issues. - - - - - - - - What do we need to ship for license compliance? - - - - - This is a difficult question and you need to consult your lawyer for the answer - for your specific case. - It is worth bearing in mind that for GPL compliance there needs to be enough - information shipped to allow someone else to rebuild the same end result - you are shipping. - This means sharing the source code, any patches applied to it, and also any - configuration information about how that package was configured and built. - - - - - - - - How do I disable the cursor on my touchscreen device? - - - - - You need to create a form factor file as described in the - "Miscellaneous Recipe Files" - section and set the HAVE_TOUCHSCREEN variable equal to one as follows: + For example, set the following in the qemux86.conf + file to include the ab123 kernel modules + with images built for the qemux86 machine: - HAVE_TOUCHSCREEN=1 + MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123" + For more information, see the + "Incorporating Out-of-Tree Modules" + section. @@ -385,220 +108,22 @@ - How do I make sure connected network interfaces are brought up by default? + How do I changed the Linux kernel command line? - The default interfaces file provided by the netbase recipe does not - automatically bring up network interfaces. - Therefore, you will need to add a BSP-specific netbase that includes an interfaces - file. - See the "Miscellaneous Recipe Files" - section for information on creating these types of miscellaneous recipe files. - - - For example, add the following files to your layer: + The Linux kernel command line is typically specified in + the machine config using the APPEND variable. + For example, you can add some helpful debug information doing + the following: - meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces - meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend + APPEND += "printk.time=y initcall_debug debug" - - - - How do I create images with more free space? - - - - - Images are created to be 1.2 times the size of the populated root filesystem. - To modify this ratio so that there is more free space available, you need to - set the configuration value IMAGE_OVERHEAD_FACTOR. - For example, setting IMAGE_OVERHEAD_FACTOR to 1.5 sets - the image size ratio to one and a half times the size of the populated - root filesystem. - - IMAGE_OVERHEAD_FACTOR = "1.5" - - - - - - - - - Why don't you support directories with spaces in the pathnames? - - - - - The Yocto Project team has tried to do this before but too many of the tools - the OpenEmbedded build system depends on such as autoconf - break when they find spaces in pathnames. - Until that situation changes, the team will not support spaces in pathnames. - - - - - - - - How do I use an external toolchain? - - - - - The toolchain configuration is very flexible and customizable. - It is primarily controlled with the - TCMODE variable. - This variable controls which tcmode-*.inc file to include - from the meta/conf/distro/include directory within the - source directory. - - - - The default value of TCMODE is "default" - (i.e. tcmode-default.inc). - However, other patterns are accepted. - In particular, "external-*" refers to external toolchains of which there are some - basic examples included in the OpenEmbedded Core (meta). - You can use your own custom toolchain definition in your own layer - (or as defined in the local.conf file) at the location - conf/distro/include/tcmode-*.inc. - - - - In addition to the toolchain configuration, you also need a corresponding toolchain recipe file. - This recipe file needs to package up any pre-built objects in the toolchain such as - libgcc, libstdcc++, - any locales, and libc. - An example is the external-sourcery-toolchain.bb, which is located - in meta/recipes-core/meta/ within the source directory. - - - - - - - - How does the OpenEmbedded build system obtain source code and will it work behind my - firewall or proxy server? - - - - - The way the build system obtains source code is highly configurable. - You can setup the build system to get source code in most environments if - HTTP transport is available. - - - When the build system searches for source code, it first tries the local download directory. - If that location fails, Poky tries PREMIRRORS, the upstream source, - and then MIRRORS in that order. - - - By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS - for SCM-based sources, - upstreams for normal tarballs, and then falls back to a number of other mirrors - including the Yocto Project source mirror if those fail. - - - As an example, you could add a specific server for Poky to attempt before any - others by adding something like the following to the local.conf - configuration file: - - PREMIRRORS_prepend = "\ - git://.*/.* http://www.yoctoproject.org/sources/ \n \ - ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ - http://.*/.* http://www.yoctoproject.org/sources/ \n \ - https://.*/.* http://www.yoctoproject.org/sources/ \n" - - - - These changes cause Poky to intercept Git, FTP, HTTP, and HTTPS - requests and direct them to the http:// sources mirror. - You can use file:// URLs to point to local directories - or network shares as well. - - - Aside from the previous technique, these options also exist: - - BB_NO_NETWORK = "1" - - This statement tells BitBake to throw an error instead of trying to access the - Internet. - This technique is useful if you want to ensure code builds only from local sources. - - - Here is another technique: - - BB_FETCH_PREMIRRORONLY = "1" - - This statement limits Poky to pulling source from the PREMIRRORS only. - Again, this technique is useful for reproducing builds. - - - Here is another technique: - - BB_GENERATE_MIRROR_TARBALLS = "1" - - This statement tells Poky to generate mirror tarballs. - This technique is useful if you want to create a mirror server. - If not, however, the technique can simply waste time during the build. - - - Finally, consider an example where you are behind an HTTP-only firewall. - You could make the following changes to the local.conf - configuration file as long as the PREMIRROR server is up to date: - - PREMIRRORS_prepend = "\ - ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ - http://.*/.* http://www.yoctoproject.org/sources/ \n \ - https://.*/.* http://www.yoctoproject.org/sources/ \n" - BB_FETCH_PREMIRRORONLY = "1" - - These changes would cause Poky to successfully fetch source over HTTP and - any network accesses to anything other than the PREMIRROR would fail. - - - The build system also honors the standard shell environment variables - http_proxy, ftp_proxy, - https_proxy, and all_proxy - to redirect requests through proxy servers. - - - - - - - - Can I get rid of build output so I can start over? - - - - - Yes - you can easily do this. - When you use BitBake to build an image, all the build output goes into the - directory created when you source the oe-init-build-env - setup file. - By default, this build directory - is named build but can be named - anything you want. - - - - Within the build directory is the tmp directory. - To remove all the build output yet preserve any source code or downloaded files - from previous builds, simply remove the tmp directory. - - - - -