diff --git a/documentation/dev-manual/dev-manual-cases.xml b/documentation/dev-manual/dev-manual-cases.xml index ebc8eeca1e..fc93b53744 100644 --- a/documentation/dev-manual/dev-manual-cases.xml +++ b/documentation/dev-manual/dev-manual-cases.xml @@ -5,219 +5,6 @@ Development Cases - - Many development cases exist for which you can use the Yocto Project. - However, for the purposes of this manual we are going to focus on two common development cases or groupings: - System Development and User Application Development. - System Development covers Board Support Package (BSP) development and kernel modification. - User Application Development covers development of applications that you intend to run on some - target hardware. - - - - This chapter presents an overview of the primary cases. - Supsequent appendices in the manual provide detailed explanations of the examples. - - - - [WRITERS NOTE: What is undetermined at this point is how much of the entire development process - we include in this particular chapter. - In other words, do we cover debugging and emulation steps here on a case-specific basis? - Or, do we capture that information in the appropriate subsequent chapter by case?] - - -
- System Development - - - System development involves modification or creation of an image that you want to run on - a specific hardware target. - Usually when you want to create an image that runs on embedded hardware the image does - not require the same amount of features that a full-fledged Linux distribution provides. - Thus, you can create a much smaller image that is designed to just use the hardware - features for your particular hardware. - - - - To help you understand how system development works in the Yocto Project, this section - covers two types of image development: BSP creation and kernel modification. - - -
- Developing a Board Support Package (BSP) - - - A BSP is a package of recipes that when applied while building an image results in - an image you can run on a particular board. - Thus, the package, when compiled into the new image, supports the operation of the board. - - - - For a brief list of terms used when describing the development process in the Yocto Project, - see Yocto Project Terms in this manual. - - - - The remainder of this section presents the basic steps to create a BSP basing it on an - existing BSP that ships with the Yocto Project. - You can reference BSP Development Case - for a detailed example that uses the Crown Bay BSP as a base BSP from which to start. - - - - Here are the basic steps involved in creating a BSP: - - 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 - Getting Setup section 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. - 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. - You should look at the README files for supported BSPs to get an idea of which one - you could use. - A generic Atom-based BSP to consider is the Crown Bay that does not support - the Intel® Embedded Media Graphics Driver (EMGD). - The remainder of this example uses that base BSP. - 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. - 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. - Suppose you are creating an application that has library or other dependencies in - order for it to compile and run. - 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. - The Yocto Project supports four BSPs that are part of the - 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 - of meta-yocto as a layer itself. - On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, - 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 - configuration information. - 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 - 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 - and identify which kernel you are going to use. - 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 BSP 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. - - - - - - - You can view a video presentation of the BSP creation process - here. - You can also find supplemental information in the - - Board Support Package (BSP) Development Guide. - Finally, there is wiki page write up of the example located - - here you might find helpful. - -
-
Modifying a Kernel @@ -593,7 +380,6 @@
-