"OpenBMC Bitbake用户手册PDF介绍与获取方式"

需积分: 0 57 浏览量更新于2024-01-28 1 收藏 557KB PDF 举报

The "openbmc-bitbake-user-manual-pdf" is a comprehensive guide to using the BitBake tool within the OpenBMC project. Authored by devRichard Purdie, Chris Larson, and Phil Blundell, this manual provides an in-depth overview of BitBake, detailing its history, goals, and key concepts. The manual begins with an introduction to BitBake, outlining its purpose and functionality within the OpenBMC project. It goes on to discuss the history and goals of the BitBake tool, providing insight into its development and the objectives it aims to achieve. The manual also delves into the core concepts of BitBake, providing a thorough explanation of its key components and how they interact to facilitate the build and packaging process. This section offers valuable insights for both beginners and experienced users, ensuring a comprehensive understanding of BitBake's inner workings. Furthermore, the manual provides guidance on obtaining BitBake, offering clear instructions on how to access and install the tool. This section is invaluable for users looking to incorporate BitBake into their workflow, ensuring they have the necessary resources to get started. Overall, the "openbmc-bitbake-user-manual-pdf" serves as a valuable resource for anyone looking to utilize BitBake within the OpenBMC project. Its comprehensive overview, detailed explanations, and practical guidance make it an essential reference for both beginners and experienced users alike. With its release on May 27, 2023, this manual is set to become an indispensable tool for anyone working with BitBake and OpenBMC.

Bitbake, Release dev

The reason for this required ﬁle hierarchy is because the BBPATH variable is not constructed until the layers are parsed.

Consequently, using the conﬁguration ﬁle as a pre-conﬁguration ﬁle is not possible unless it is located in the current

working directory.

Minimally, each conﬁguration ﬁle must deﬁne the machine and the temporary directory BitBake uses for the build.

Suggested practice dictates that you do not overlap the temporary directories used during the builds.

Aside from separate conﬁguration ﬁles for each target, you must also enable BitBake to perform multiple conﬁguration

builds. Enabling is accomplished by setting the BBMULTICONFIG variable in the local.conf conﬁguration ﬁle. As

an example, suppose you had conﬁguration ﬁles for target1 and target2 deﬁned in the build directory. The following

statement in the local.conf ﬁle both enables BitBake to perform multiple conﬁguration builds and speciﬁes the two

extra multiconﬁgs:

BBMULTICONFIG = "target1 target2"

Once the target conﬁguration ﬁles are in place and BitBake has been enabled to perform multiple conﬁguration builds,

use the following command form to start the builds:

$ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]

Here is an example for two extra multiconﬁgs: target1 and target2:

$ bitbake mc::target mc:target1:target mc:target2:target

12 Chapter 1. Overview

Bitbake, Release dev

Enabling Multiple Conﬁguration Build Dependencies

Sometimes dependencies can exist between targets (multiconﬁgs) in a multiple conﬁguration build. For example,

suppose that in order to build an image for a particular architecture, the root ﬁlesystem of another build for a diﬀerent

architecture needs to exist. In other words, the image for the ﬁrst multiconﬁg depends on the root ﬁlesystem of the

second multiconﬁg. This dependency is essentially that the task in the recipe that builds one multiconﬁg is dependent

on the completion of the task in the recipe that builds another multiconﬁg.

To enable dependencies in a multiple conﬁguration build, you must declare the dependencies in the recipe using the

following statement form:

task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_

˓→which_to_depend"

To better show how to use this statement, consider an example with two multiconﬁgs: target1 and target2:

image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"

In this example, the from_multiconfig is “target1” and the to_multiconfig is “target2”. The task on which the

image whose recipe contains image_task depends on the completion of the rootfs_task used to build out image2, which

is associated with the “target2” multiconﬁg.

Once you set up this dependency, you can build the “target1” multiconﬁg using a BitBake command as follows:

$ bitbake mc:target1:image1

This command executes all the tasks needed to create image1 for the “target1” multiconﬁg. Because of the dependency,

BitBake also executes through the rootfs_task for the “target2” multiconﬁg build.

Having a recipe depend on the root ﬁlesystem of another build might not seem that useful. Consider this change to the

statement in the image1 recipe:

image_task[mcdepends] = "mc:target1:target2:image2:image_task"

In this case, BitBake must create image2 for the “target2” build since the “target1” build depends on it.

Because “target1” and “target2” are enabled for multiple conﬁguration builds and have separate conﬁguration ﬁles,

BitBake places the artifacts for each build in the respective temporary build directories.

1.5. The BitBake Command 13

CHAPTER

TWO

EXECUTION

The primary purpose for running BitBake is to produce some kind of output such as a single installable package, a ker-

nel, a software development kit, or even a full, board-speciﬁc bootable Linux image, complete with bootloader, kernel,

and root ﬁlesystem. Of course, you can execute the bitbake command with options that cause it to execute single

tasks, compile single recipe ﬁles, capture or clear data, or simply return information about the execution environment.

This chapter describes BitBake’s execution process from start to ﬁnish when you use it to create an image. The execution

process is launched using the following command form:

$ bitbake target

For information on the BitBake command and its options, see “The BitBake Command” section.

Note: Prior to executing BitBake, you should take advantage of available parallel thread execution on your build host

by setting the BB_NUMBER_THREADS variable in your project’s local.conf conﬁguration ﬁle.

A common method to determine this value for your build host is to run the following:

$ grep processor /proc/cpuinfo

This command returns the number of processors, which takes into account hyper-threading. Thus, a quad-core

build host with hyper-threading most likely shows eight processors, which is the value you would then assign to

BB_NUMBER_THREADS.

A possibly simpler solution is that some Linux distributions (e.g. Debian and Ubuntu) provide the ncpus command.

2.1 Parsing the Base Conﬁguration Metadata

The ﬁrst thing BitBake does is parse base conﬁguration metadata. Base conﬁguration metadata consists of your project’s

bblayers.conf ﬁle to determine what layers BitBake needs to recognize, all necessary layer.conf ﬁles (one from

each layer), and bitbake.conf. The data itself is of various types:

• Recipes: Details about particular pieces of software.

• Class Data: An abstraction of common build information (e.g. how to build a Linux kernel).

• Conﬁguration Data: Machine-speciﬁc settings, policy decisions, and so forth. Conﬁguration data acts as the

glue to bind everything together.

Bitbake, Release dev

The layer.conf ﬁles are used to construct key variables such as BBPATH and BBFILES. BBPATH is used to search

for conﬁguration and class ﬁles under the conf and classes directories, respectively. BBFILES is used to locate both

recipe and recipe append ﬁles (.bb and .bbappend). If there is no bblayers.conf ﬁle, it is assumed the user has set

the BBPATH and BBFILES directly in the environment.

Next, the bitbake.conf ﬁle is located using the BBPATH variable that was just constructed. The bitbake.conf ﬁle

may also include other conﬁguration ﬁles using the include or require directives.

Prior to parsing conﬁguration ﬁles, BitBake looks at certain variables, including:

• BB_ENV_PASSTHROUGH

• BB_ENV_PASSTHROUGH_ADDITIONS

• BB_PRESERVE_ENV

• BB_ORIGENV

• BITBAKE_UI

The ﬁrst four variables in this list relate to how BitBake treats shell environment variables during task execution. By

default, BitBake cleans the environment variables and provides tight control over the shell execution environment.

However, through the use of these ﬁrst four variables, you can apply your control regarding the environment variables

allowed to be used by BitBake in the shell during execution of tasks. See the “Passing Information Into the Build Task

Environment” section and the information about these variables in the variable glossary for more information on how

they work and on how to use them.

The base conﬁguration metadata is global and therefore aﬀects all recipes and tasks that are executed.

BitBake ﬁrst searches the current working directory for an optional conf/bblayers.conf conﬁguration ﬁle. This ﬁle

is expected to contain a BBLAYERS variable that is a space-delimited list of ‘layer’ directories. Recall that if BitBake

cannot ﬁnd a bblayers.conf ﬁle, then it is assumed the user has set the BBPATH and BBFILES variables directly in

the environment.

For each directory (layer) in this list, a conf/layer.conf ﬁle is located and parsed with the LAYERDIR variable being

set to the directory where the layer was found. The idea is these ﬁles automatically set up BBPATH and other variables

correctly for a given build directory.

BitBake then expects to ﬁnd the conf/bitbake.conf ﬁle somewhere in the user-speciﬁed BBPATH. That conﬁgu-

ration ﬁle generally has include directives to pull in any other metadata such as ﬁles speciﬁc to the architecture, the

machine, the local environment, and so forth.

Only variable deﬁnitions and include directives are allowed in BitBake .conf ﬁles. Some variables directly inﬂuence

BitBake’s behavior. These variables might have been set from the environment depending on the environment variables

previously mentioned or set in the conﬁguration ﬁles. The “Variables Glossary” chapter presents a full list of variables.

After parsing conﬁguration ﬁles, BitBake uses its rudimentary inheritance mechanism, which is through class ﬁles,

to inherit some standard classes. BitBake parses a class when the inherit directive responsible for getting that class is

encountered.

The base.bbclass ﬁle is always included. Other classes that are speciﬁed in the conﬁguration using the INHERIT

variable are also included. BitBake searches for class ﬁles in a classes subdirectory under the paths in BBPATH in

the same way as conﬁguration ﬁles.

A good way to get an idea of the conﬁguration ﬁles and the class ﬁles used in your execution environment is to run the

following BitBake command:

$ bitbake -e > mybb.log

Examining the top of the mybb.log shows you the many conﬁguration ﬁles and class ﬁles used in your execution

environment.

16 Chapter 2. Execution

剩余111页未读，继续阅读

「已注销」

粉丝: 0
资源: 2

"OpenBMC Bitbake用户手册PDF介绍与获取方式"

BitBake用户手册：详解、概念与命令指南

"The Yocto Project User Manual PDF: A Quick Start Guide for Building Customized Linux Distributions

ASAP2 Tool-Set User Manual v12.0: Vector Informatik的英文指南

ifr-6000-remote-commands-manual-manual-user-guide-en.pdf

the-yocto-project-user-manual-pdf

bitbake-user-manual.pdf

POC-200-series-User-Manual-RevA1-1.pdf

Mellanox-OFED-Linux-User-Manual-v3.20.pdf

BitBake User Manual-V2.4.pdf

bitbake-user-manual.rar_full

最新资源