From 46af251ce0362f9fb37f752e546311a20f99138e Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 1 Aug 2011 14:39:35 -0700 Subject: documentation/dev-manual/dev-manual-model.xml: first pass of kernel steps added. (From yocto-docs rev: a8354af008306f4deeae7b2167c3dbd604d8b275) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-model.xml | 249 ++++++++++++++++++++++++-- 1 file changed, 234 insertions(+), 15 deletions(-) (limited to 'documentation') diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml index 2404be8..6324efa 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -84,13 +84,18 @@ process and tools you need. For information on how to get these files, see the Getting Setup section in this manual. + Establish a local copy of the base BSP files: Having + the BSP files on your system gives you access to the build + process and tools you need. + For information on how to get these files, see + Getting Setup earlier in this manual. Choose a Yocto Project-supported BSP as your base BSP: The Yocto Project ships with several BSPs that support various hardware. It is best to base your new BSP on an existing BSP rather than create all the recipes and configuration files from scratch. While it is possible to create everything from scratch, basing your new BSP on something that is close is much easier. - Or, at a minimum, it gives you some structure with which to start. + Or, at a minimum, it gives you some structure with which to start. At this point you need to understand your target hardware well enough to determine which existing BSP it most closely matches. Things to consider are your hardware’s on-board features such as CPU type and graphics support. @@ -102,13 +107,8 @@ To see the supported BSPs, go to the Yocto Project download page and click on “BSP Downloads.” - Establish a local copy of the base BSP files: Having - the BSP files on your system gives you access to the build - process and tools you need. - For information on how to get these files, see - Getting Setup earlier in this manual. Create your own BSP layer: Layers are ideal for - isolating and storing work for a given piece of hardware. + isolating and storing work for a given piece of hardware. A layer is really just a location or area in which you place the recipes for your BSP. In fact, a BSP is, in itself, a special type of layer. Consider an application as another example that illustrates a layer. @@ -119,8 +119,8 @@ all the relevant information for the project that the Yocto Project build system knows about. The Yocto Project supports four BSPs that are part of the - Yocto Project release: atom-pc, beagleboard, - mpc8315e, and routerstationpro. + Yocto Project release: atom-pc, beagleboard, + mpc8315e, and routerstationpro. The recipes and configurations for these four BSPs are located and dispersed within local Yocto Project files. Consequently, they are not totally isolated in the spirit of layers unless you think @@ -129,7 +129,7 @@ N450, and Sugar Bay are isolated. When you set up a layer for a new BSP you should follow a standard layout. This layout is described in the - + Example Filesystem Layout section of the Board Support Package (BSP) Development Guide. In the standard layout you will notice a suggested structure for recipes and @@ -137,13 +137,15 @@ You can see the standard layout for the Crown Bay BSP in this example by examining the directory structure of the meta-crownbay layer inside the local Yocto Project files. - Make configuration and recipe changes to your new BSP + Make configuration changes to your new BSP layer: The standard BSP layer structure organizes the files you need to edit in conf and several recipes-* within the - BSP layer. - Configuration changes identify where your new layer is on the local system + BSP layer. + Configuration changes identify where your new layer is on the local system and identify which kernel you are going to use. - Recipe changes include altering recipes (.bb files), removing + + Make recipe changes to your new BSP layer: Recipe + changes include altering recipes (.bb files), removing recipes you don't use, and adding new recipes that you need to support your hardware. Prepare for the build: Once you have made all the @@ -225,8 +227,225 @@ <anchor id='kernel-spot' />Modifying the Kernel - Text needed here. + Kernel modification involves changing the Linux Yocto kernel, which could involve changing + configuration variables as well as adding new kernel recipes. + Configuration changes can be added in the form of configuration fragments, while recipe + modification comes through the kernel's recipes-kernel area + in a kernel layer you create. + + + + The remainder of this section presents a high-level overview of the Linux Yocto + kernel architecture and the steps to modify the Linux Yocto kernel. + For a complete discussion of the kernel, see the + + Yocto Project Kernel Architecture and Use Manual. + You can reference Kernel Modification Example + for a detailed example that changes the configuration of a kernel. + +
+ Kernel Overview + + + When one thinks of the source files for a kernel they usually think of a fixed structure + of files that contain kernel patches. + The Yocto Project, however, employs mechanisims that in a sense result in a kernel source + generator. + + + + The Yocto Project uses the source code management (SCM) tool Git to manage and track Yocto + Project files. + Git employs branching strategies that effectively produce a tree-like structure whose + branches represent diversions from more general code. + For example, suppose two kernels are basically identical with the exception of a couple + different features in each. + In the Yocto Project source repositories managed by Git a main branch can contain the + common or shared + parts of the kernel source and two branches that diverge from that common branch can + each contain the features specific to the respective kernel. + The result is a managed tree whose "leaves" represent the end of a specific path that yields + a set of kernel source files necessary for a specific piece of hardware and its features. + + + + A big advantage to this scheme is the sharing of common features by keeping them in + "larger" branches that are further up the tree. + This practice eliminates redundant storage of similar features shared among kernels. + + + + When you build the kernel on your development system all files needed for the build + are taken from the Yocto Project source repositories pointed to by the + SRC_URI variable and gathered in a temporary work area + where they are subsequently used to create the unique kernel. + Thus, in a sense, the process constructs a local source tree specific to your + kernel to generate the new kernel image - a source generator if you will. + + + + For a complete discussion of the Yocto Project kernel's architcture and its branching strategy, + see the + The Yocto Project Kernel Architecture and Use Manual. + +
+ +
+ Kernel Modification Workflow + + + This illustration and the following list summarizes the kernel modification general workflow. + + + + + + [WRITER'S NOTE: Need new flow illustration here] + + + + + Set up your host development system to support + development using the Yocto Project: See + + The Linux Distributions section and + + The Packages section both + in the Yocto Project Quick Start for requirements. + You will also need a release of Yocto Project installed on the host. + Establish a local copy of the Yocto Project files on your + system: You need to have the Yocto Project files available on your host system. + Having the Yocto Project files on your system gives you access to the build + process and tools you need. + For information on how to get these files, see the bulleted item + Yocto Project Release in + Getting Setup earlier in this manual. + + Establish a local kernel layer by copying the + meta-skeleton layer: When you set up a kernel layer + for your changes you should follow a standard layout. + For kernel layers you can start with meta-skeleton, which + is a minimal, base kernel layer in the local Yocto Project files. + You can examine meta-skeleton + in the poky Git repository. + A layer is really just a location or area in which you place configuration + fragments and recipes that modify your kernel. + The layer, in this case, would be where all the recipes that define those dependencies + are kept. + The key point for a layer is that it is an isolated area that contains + all the relevant information for the project that the Yocto Project build + system knows about. + + Iteratively make kernel configuration changes + to your local kernel layer: Use menuconfig + to enable and disable the configurations to the Linux Yocto kernel. + Using menuconfig allows you to develop and test the + configuration changes you are making to the kernel. + Iteratively make kernel recipe changes to your new kernel + layer: The standard layer structure organizes the files you need to edit in + conf and several recipes-* within the + layer. + Recipe changes include altering recipes (.bb files), removing + recipes you don't use, and adding new recipes that you need to support your hardware. + + Prepare for the build: Once you have made all the + changes to your kernel layer there remains a few things + you need to do for the Yocto Project build system in order for it to create your image. + You need to get the build environment ready by sourcing an environment setup script + and you need to be sure two key configuration files are configured appropriately. + The entire process for building an image is overviewed in the + + Building an Image section of the Yocto Project Quick Start. + You might want to reference this information. + Build the image: The Yocto Project uses the BitBake + tool to build images based on the type of image + you want to create. + You can find more information on BitBake + here. + The build process supports several types of images to satisfy different needs. + When you issue the BitBake command you provide a “top-level” recipe that essentially + starts the process off of building the type of image you want. + [WRITER'S NOTE: Consider moving this to the Poky Reference Manual.] + You can find these recipes in the meta/recipes-core/images and + meta/recipes-sato/images directories of your local Yocto Project + file structure (Git repository or extracted release tarball). + Although the recipe names are somewhat explanatory, here is a list that describes them: + + Base – A foundational basic image without support + for X that can be reasonably used for customization. + Core – A foundational basic image with support for + X that can be reasonably used for customization. + Direct Disk – An image that you can copy directory to + the disk of the target device. + Live – An image you can run from a USB device or from + a CD without having to first install something. + Minimal – A small image without a GUI. + This image is not much more than a kernel with a shell. + Minimal Development – A Minimal image suitable for + development work. + Minimal Direct Disk – A Minimal Direct + Disk image. + Minimal RAM-based Initial Root Filesystem – + A minimal image + that has the initramfs as part of the kernel, which allows the + system to find the first “init” program more efficiently. + Minimal Live – A Minimal Live image. + Minimal MTD Utilities – A minimal image that has support + for the MTD utilities, which let the user interact with the MTD subsystem in + the kernel to perform operations on flash devices. + Sato – An image with Sato support, a mobile environment + and visual style that works well with mobile devices. + Sato Development – A Sato image suitable for + development work. + Sato Direct Disk – A Sato Direct + Disk image. + Sato Live – A Sato Live image. + Sato SDK – A Sato image that includes the Yocto Project + toolchain and development libraries. + Sato SDK Direct Disk – A Sato SDK Direct + Disk image. + Sato SDK Live – A Sato SDK Live + image. + + + Make your configuration and recipe changes available + in the kernel layer: Up to this point all the changes to the + kernel have been done and tested iteratively. + Once they are tested and ready to go you can move them into the kernel layer, + which allows you to distribute the layer. + Make your configuration and recipe changes to the + linux Yocto Git repository (in-tree changes): If the changes you made + are suited for all Linux Yocto users you might want to push the changes up into + the Linux Yocto Git repository so that they become part of the kernel tree + and available to everyone using the kernel. + + + + + You can find a web interface to the Yocto Project source repository at + . + Within the interface you will see groups of related source code, each of which can + be cloned using Git to result in a working Git repository on your local system + (referred to as the "local Yocto Project files" in this manual). + The Yocto Project supports four types of kernels in its source repositories at + : + + linux-yocto-2.6.34 - The + stable Linux Yocto kernel that is based on the Linux 2.6.34 release. + linux-yocto-2.6.37 - The current + Linux Yocto kernel that is based on the Linux 2.6.37 release. + linux-yocto-dev - A development + kernel based on the Linux 2.6.39-rc1 release. + linux-2.6 - A kernel based on + minimal Linux mainline tracking. + [WRITER'S NOTE: I don't know which Git repository the user needs to clone to get this + repository on their development system.] + + +
-- cgit v1.1