poky: subtree update:1203d1f24d..2dcd1f2a21
Alejandro Enedino Hernandez Samaniego (2):
python3: Improve logging, syntax and update deprecated modules to create_manifest
python3: Upgrade 3.9.2 -> 3.9.4
Alexander Kanavin (22):
scripts/oe-debuginfod: correct several issues
libmicrohttpd: add a recipe from meta-oe
maintainers.inc: add libmicrohttpd entry
xwayland: add a standalone recipe
weston: use standalone xwayland instead of outdated xserver-xorg version
elfutils: correct debuginfod builds on x32
elfutils: adjust ptests for correct debuginfod testing
default-distrovars.inc: add debuginfod to default DISTRO_FEATURES
oeqa: tear down oeqa decorators if one of them raises an exception in setup
meta/lib/oeqa/core/tests/cases/timeout.py: add a testcase for the previous fix
core-image-weston: add sdk/ptest images
oeqa/core/tests/test_data.py: use weston image instead of sato
oeqa/selftest: transition to weston images
core-image-multilib-example: base on weston, and not sato
dev-manual/common-tasks.rst: correct the documentation for debuginfod
diffoscope: add native libraries to LD_LIBRARY_PATH
Revert "oeqa: Set LD_LIBRARY_PATH when executing native commands"
boost: correct upstream version check
vte: use tarballs again
gdk-pixbuf: update 2.40.0 -> 2.42.6
glib-2.0: update 2.68.0 -> 2.68.1
gnu-config: update to latest revision
Anatol Belski (1):
cross-canadian: Whitelist "mingw32" as TARGET_OS
Anders Wallin (3):
lttng-tools: Fix missing legacy test files
lttng-tools: Fix path for test_python_looging
scripts/contrib/image-manifest: add new script
Andreas Müller (1):
xwayland: remove protocol.txt - it clashes with xserver-xorg
Anthony Bagwell (1):
systemd: upgrade 247.4 -> 247.6
Anuj Mittal (2):
Revert "qemu: fix CVE-2021-3392"
qemu: fix CVE-2021-3392
Armin Kuster (6):
binutils: rename BRANCH var
libseccomp: move recipe from meta-security to core
gnutls: Enable seccomp if FEATURE is set
systemd: Enable seccomp if FEATURE is set
qemu: Enable seccomp if FEATURE is set
default-distrovars.inc: Add seccomp to DISTRO_FEATURES_DEFAULT
Bastian Krause (1):
ccache: add packageconfig docs option
Bruce Ashfield (20):
kern-tools: add dropped options to audit output
linux-yocto/5.4: update to v5.4.109
linux-yocto/5.10: update to v5.10.27
linux-yocto/5.10: BSP configuration fixes
linux-yocto/5.10: update to v5.10.29
linux-yocto/5.4: update to v5.4.111
linux-yocto/5.10: update to v5.10.30
linux-yocto-rt/5.10: update to -rt34
linux-yocto/5.4: update to v5.4.112
linux-yocto/5.4: fix arm defconfig warnings
linux-yocto/5.10: fix arm defconfig warnings
linux-yocto/5.10: aufs fixes
linux-yocto/5.10: qemuriscv32.cfg: RV32 only supports 1G physical memory
linux-yocto/5.10: update to v5.10.32
perf: fix python-audit RDEPENDS
linux-yocto/5.4: update to v5.4.114
linux-yocto/5.10: update to v5.10.34
linux-yocto/5.4: update to v5.4.116
linux-yocto/5.10: qemuppc32: reduce serial shutdown issues
yocto-check-layer: Only note a layer without a conf/layer.conf (versus error)
Changqing Li (2):
libpam: make volatile files created successfully
gcr: fix one parallel build failure
Chen Qi (3):
busybox: fix CVE-2021-28831
weston: fix build failure due to race condition
rsync: fix CVE-2020-14387
Christophe Chapuis (1):
rootfs.py: find .ko.gz and .ko.xz kernel modules as well
Daniel Ammann (1):
archiver: Fix typos
Devendra Tewari (2):
bitbake: lib/bb: Add bb.utils.rename() helper function and use for renaming
classes/lib/scripts: Use bb.utils.rename() instead of os.rename()
Diego Sueiro (3):
oeqa/selftest/bblayers: Add test case for bitbake-layers layerindex-show-depends
bitbake: layerindex: Fix bitbake-layers layerindex-show-depends command
bitbake: layerindex: Add --fetchdir parameter to layerindex-fetch
Douglas Royds (2):
Revert "externalsrc: Detect code changes in submodules"
externalsrc: Detect code changes in submodules
Gavin Li (1):
kmod: do not symlink config.guess/config.sub during autoreconf
Harald Brinkmann (1):
bitbake: fetch/svn: Fix parsing revision of SVN repos with redirects
He Zhe (1):
linux-yocto-dev: add features/scsi/scsi-debug.scc features/gpio/mockup.scc to KERNEL_FEATURES
Henning Schild (3):
bitbake: fetch/git: add support for disabling shared clones on unpack
bitbake: tests/fetch: deduplicate local git testing code
bitbake: tests/fetch: add tests for local and remote "noshared" git fetching
Jon Mason (1):
oeqa/runtime: space needed
Jonas Höppner (1):
ltp: fix empty ltp-dev package
Jose Quaresma (4):
gstreamer1.0: update patch upstream status
ptest-runner: libgcc must be installed for pthread_cancel to work
gstreamer1.0: rename patches
gstreamer1.0: update ptest patch
Joshua Watt (2):
bitbake: knotty: Re-enable command line logging levels
classes/image: Use xargs to set file timestamps
Kai Kang (2):
cmake.bbclass: remove ${B} before cmake_do_configure
kernel-yocto.bbclass: chdir to ${WORKDIR} for do_kernel_checkout
Kevin Hao (3):
modutils-initscripts: Bail out when no module is installed
sysvinit-inittab/start_getty: Check /sys for the tty device existence
Revert "inittab: Add getty launch on hvc0 for qemuppc64"
Khairul Rohaizzat Jamaluddin (1):
qemu: Fix CVE-2020-35517
Khem Raj (54):
gcc: Upgrade to 10.3.0 bug-fix release
glibc: Rename glibc src package
gcc-runtime: Make DEBUG_PREFIX_MAP relative to S
valgrind: Delete trailing whitespaces
valgrind: Add glibc-src to ptest rdeps
valgrind: Add libstdc++ debug symbols for ptest
vte: Upgrade to 0.64.0 release
systemd: Fix build on mips/musl
epiphany: Add missing dependency on gnutls
cups: Turn gnutls into a packageconfig knob
wpa-supplicant: Enable openssl
curl: Use openssl backend
libpsl: Add config knobs for runtime/builtin conversion choices
glib-networking: Prefer openssl backend instead of gnutls
gstreamer1.0-plugins-bad: Add packageconfigs for hls crypto backends
ca-certificates: Fix openssl runtime cert dependencies
weston: Drop loading xwayland.so module
elfutils: Make 64bit time_t fix generic
binutils: Fix linking failures when using dwarf-5
go: Use dl.google.com for SRC_URI
musl: Update to latest master
llvm: Upgrade to LLVM 12 release
python3-docutils: Upgrade to 0.17.1
python3-markupsafe: Enable ptests
python3-jinja2: Enable ptests
python3-pyyaml: Add recipe
apt: Fix build on musl when seccomp is enabled
default-distrovars.inc: Remove seccomp for riscv32
gcc-target: Create a LTO plugin symlink in bfd-plugins directory
bitbake.conf: Use gcc-nm as default NM
gcc-cross: Install linker LTO plugin for binutils tools
gcc-cross-canadian: Install LTO linker plugin to BFD searchable location
gnutls: Point to staging area for finding seccomp libs and includes
libjpeg-turbo: Use --reproducible option for nasm
libid3tag: Filter -ffile-prefix-map too
openssl: Filter out -ffile-prefix-map as well
ltp: Filter out -ffile-prefix-map
gcc-runtime: Fix __FILE__ related reproducablity issues
reproducible_build.bbclass: Enable -Wdate-time
pkgconfig: Fix nativesdk builds for mingw sdk hosts
m4: Do not use SIGSTKSZ
bluez: Fix shadowing of pause function from libc
valgrind: Disable leak_cpp_interior test
findutils: Do not use SIGSTKSZ
bash: Include files needed for run-heredoc ptest
libpam: Provide needed env for tst-pam_start_confdir ptest
cml1.bbclass: Return sorted list of cfg files
busybox: Enable long options for enabled applets
webkitgtk: Fix reproducibility in minibrowser
webkitgtk: Update patch status
libgcc-initial: Do not build fp128 to decimal ppc functions
gcc: Upgrade to GCC 11
busybox: Fix reproducibility
strace: Upgrade to 5.12
Konrad Weihmann (2):
cpan-base: set default UPSTREAM_CHECK_REGEX
cve-update-db-native: skip on empty cpe23Uri
Marek Vasut (1):
linux-firmware: Package RSI 911x WiFi firmware
Martin Jansa (2):
xwayland: add opengl to REQUIRED_DISTRO_FEATURES
ofono: prevent using bundled ell headers and fix build with ell-0.39
Michael Halstead (1):
releases: update to include 3.3
Michael Opdenacker (7):
dev-manual: fix code insertion
manuals: simplify code insertion
manuals: code insertion simplification over two lines
bitbake: doc: bitbake-user-manual: simplify colon usage
bitbake: doc: bitbake-user-manual: code insertion simplification over two lines
dev-manual: update references to Docker installation instructions
sanity.bbclass: mention CONNECTIVITY_CHECK_URIS in network failure message
Mikko Rapeli (4):
bitbake: bitbake: tests/fetch: fix test execution without .gitconfig
bitbake: bitbake: tests/fetch: remove write protected files too
lz4: use CFLAGS from bitbake
unzip: use optimization from bitbake
Mingli Yu (6):
libxshmfence: Build fixes for riscv32
packagegroup-core-tools-profile: Remove valgrind for riscv32
packagegroup-core-tools-testapps.bb: Remove kexec for riscv32
libtool: make sure autoheader run before automake
groff: not ship /usr/bin/grap2graph
rpm: Upgrade to 4.16.1.3
Minjae Kim (1):
qemu: fix CVE-2021-3392
Nicolas Dechesne (1):
bitbake: doc: bitbake-user-manual: fix typo left over from Sphinx migration
Niels Avonds (1):
bitbake: fetch/gitsm: Fix crash when using git LFS and submodules
Oleksandr Kravchuk (2):
python3-setuptools: update to 56.0.0
autoconf-archive: update to 2021.02.19
Otavio Salvador (2):
gstreamer1.0-plugins-base: Add 'viv-fb' OpenGL Window System option
gstreamer1.0-plugins-base: Use bb.utils.filter to reduce code
Paul Barker (10):
bitbake: hashserv: Use generic ConnectionError
bitbake: asyncrpc: Common implementation of RPC using json & asyncio
bitbake: hashserv: Refactor to use asyncrpc
bitbake: prserv: Drop obsolete python version check
bitbake: prserv: Drop unused dump_db method
bitbake: prserv: Add connect function
prservice: Use new connect API
bitbake: prserv: Use multiprocessing to auto start prserver
bitbake: prserv: Extract daemonization from PRServer class
bitbake: prserv: Handle requests in main thread
Paulo Cesar Zaneti (1):
perl: fix startperl configuration option for perl-native
Peter Budny (1):
lib/oe/terminal: Fix tmux new-session on older tmux versions (<1.9)
Petr Vorel (1):
ltp: Replace musl patches with do_patch[postfuncs]
Przemyslaw Gorszkowski (2):
bitbake: progress: LineFilterProgressHandler - Handle parsing line which ends with CR only
bitbake: fetch/s3: Add progress handler for S3 cp command
Randy MacLeod (2):
sqlite3: upgrade 3.35.0 -> 3.35.3
oe-time-dd-test.sh: increase timeout to 15 sec
Reto Schneider (2):
license_image.bbclass: Detect broken symlinks
license_image.bbclass: Fix symlink to generic license files
Richard Purdie (32):
oeqa/selftest: Hardcode test assumptions about heartbeat event timings
pseudo: Upgrade to add trailing slashes ignore path fix
oeqa/selftest: Ensure packages classes are set correctly for maintainers test
layer.conf: Update to add post 3.3 release honister series
sanity: Add error check for '%' in build path
bitbake: runqueue: Fix deferred task issues
bitbake: tinfoil/data_smart: Allow variable history emit() to function remotely
sanity: Further improve directory sanity tests
bitbake: bitbake-server: Remove now unneeded code
bitbake: doc/user-manual-fetching: Remove basepath unpack parameter docs
poky.conf: Post release version bump
runqemu: Ensure we cleanup snapshot files after image run
patchelf: Backport fix from upstream for note section overlap error
pyyaml: Add missing HOMEPAGE
yocto-check-layer: Avoid bug when iterating and autoadding dependencies
libseccomp: Add MAINTAINERS entry and HOMEPAGE
libseccomp: Fix reproducibility issue
apt: Disable libseccomp
libxcrypt: Update to 4.4.19 release and fix symbol version issues
patchelf: Fix note section alignment issues
bitbake: runqueue: Fix multiconfig deferred task sstate validity caching issue
bitbake: runqueue: Handle deferred task rehashing in multiconfig builds
patchelf: Fix alignment patch
pybootchart/draw: Avoid divide by zero error
yocto-uninative: Update to 3.1 which includes a patchelf fix
Revert "perl: fix startperl configuration option for perl-native"
bitbake: bin/bitbake-getvar: Add a new command to query a variable value (with history)
bitbake: bitbake: Switch to post release version number 1.51.0
sanity.conf: Require bitbake 1.51.0
oeqa/qemurunner: Improve logging thread exit handling for qemu shutdown test
oeqa/qemurunner: Handle path length issues for qmp socket
lib/package_manager: Use shutil.copy instead of bb.utils.copyfile for intercepts
Robert Joslyn (3):
btrfs-tools: Update to 5.11.1
btrfs-tools: Add PACKAGECONFIG options
btrfs-tools: Try to follow style guide
Robert P. J. Day (3):
sdk-manual: "beablebone" -> "beaglebone"
sdk-manual: fix broken formatting of sample command
bitbake.conf: sort MIRROR list, add missing SAMBA_MIRROR
Ross Burton (4):
glslang: strip whitespace in pkgconfig file
insane: clean up some more warning messages
bitbake: bitbake-server: ensure server timeout is a float
oe-buildenv-internal: add BitBake's library to PYTHONPATH
Sakib Sajal (12):
oe-time-dd-test.sh: make executable
oe-time-dd-test.sh: provide more information from "top"
qemu: fix CVE-2021-20181
qemu: fix CVE-2020-29443
qemu: fix CVE-2021-20221
qemu: fix CVE-2021-3409
qemu: fix CVE-2021-3416
qemu: fix CVE-2021-20257
oe-time-dd-test.sh: collect cooker log when timeout is exceeded
buildstats.bbclass: collect data in the same file.
qemu: fix CVE-2020-27821
qemu: fix CVE-2021-20263
Samuli Piippo (1):
assimp: BBCLASSEXTEND to native and nativesdk
Saul Wold (4):
pango: re-enable ptest
qemu-system-native: install qmp python module
qemurunner: Add support for qmp commands
qemurunner: change warning to info
Stefan Ghinea (3):
wpa-supplicant: fix CVE-2021-30004
libssh2: fix build failure with option no-ecdsa
xserver-xorg: fix CVE-2021-3472
Stefano Babic (1):
libubootenv: upgrade 0.3.1 -> 0.3.2
Teoh Jay Shen (6):
oeqa/manual/bsp-hw.json : remove boot_from_runlevel_3 and boot_from_runlevel_5 manual test
oeqa/manual/bsp-hw.json : remove ethernet_static_ip_set_in_connman and ethernet_get_IP_in_connman_via_DHCP manual test
oeqa/manual/bsp-hw.json : remove standby and Test_if_LAN_device_works_well_after_resume_from_suspend_state manual test
oeqa/manual/bsp-hw.json : remove click_terminal_icon_on_X_desktop manual test
oeqa/manual/bsp-hw.json :remove Check_if_RTC_(Real_Time_Clock)_can_work_correctly manual test
oeqa/manual/bsp-hw.json : remove Test_if_usb_hid_device_works_well_after_resume_from_suspend_state manual test
Trevor Gamblin (2):
nettle: upgrade 3.7.1 -> 3.7.2
ref-manual/variables.rst: Add incompatibility warning for SERIAL_CONSOLES_CHECK
Ulrich Ölmann (1):
arch-armv6m.inc: fix access rights
Vinay Kumar (1):
binutils: Fix CVE-2021-20197
Vineela Tummalapalli (1):
Adding dunfell 3.1.7 to the switcher and release list.
Wang Mingyu (6):
at-spi2-core: upgrade 2.38.0 -> 2.40.0
babeltrace2: upgrade 2.0.3 -> 2.0.4
boost-build-native: upgrade 4.3.0 -> 4.4.1
libassuan: upgrade 2.5.4 -> 2.5.5
webkitgtk: upgrade 2.30.5 -> 2.30.6
vte: upgrade 0.62.2 -> 0.62.3
Wes Lindauer (1):
oeqa/runtime/cases: Only disable/enable for current boot
Yanfei Xu (1):
parselogs: ignore floppy error on qemu-system-x86 at boot stage
Yi Fan Yu (7):
valgrind: update 3.16.1 -> 3.17.0
valgrind: Disable ptest swapcontext.vgtest
valgrind: Fix ptest swapcontext.vgtest
Revert "glib-2.0: add workaround to fix codegen.py.test failing"
re2c: Upgrade 2.0.3 -> 2.1.1
valgrind: Enable drd/tests/bar_bad* ptest
libevent: Increase ptest timing tolerance 50 ms -> 100 ms
Zqiang (1):
rt-tests: Update rt-tests
hongxu (1):
deb: apply postinstall on sdk
wangmy (34):
ell: upgrade 0.38 -> 0.39
dbus-glib: upgrade 0.110 -> 0.112
ccache: upgrade 4.2 -> 4.2.1
gcr: upgrade 3.38.1 -> 3.40.0
ghostscript: upgrade 9.53.3 -> 9.54.0
libsolv: upgrade 0.7.17 -> 0.7.18
glib-2.0: upgrade 2.66.7 -> 2.68.0
file: upgrade 5.39 -> 5.40
curl: upgrade 7.75.0 -> 7.76.0
acpica: upgrade 20210105 -> 20210331
help2man: upgrade 1.48.2 -> 1.48.3
libportal: upgrade 0.3 -> 0.4
libksba: upgrade 1.5.0 -> 1.5.1
go: upgrade 1.16.2 -> 1.16.3
libcap: upgrade 2.48 -> 2.49
libcomps: upgrade 0.1.15 -> 0.1.16
icu: upgrade 68.2 -> 69.1
mpg123: upgrade 1.26.4 -> 1.26.5
man-pages: upgrade 5.10 -> 5.11
go: update SRC_URI to use https protocol
mesa: upgrade 21.0.1 -> 21.0.2
openssh: upgrade 8.5p1 -> 8.6p1
mtools: upgrade 4.0.26 -> 4.0.27
python3-cython: upgrade 0.29.22 -> 0.29.23
tiff: upgrade 4.2.0 -> 4.3.0
boost: upgrade 1.75.0 -> 1.76.0
wpebackend-fdo: upgrade 1.8.2 -> 1.8.3
mesa: upgrade 21.0.2 -> 21.0.3
gdb: upgrade 10.1 -> 10.2
glib-networking: upgrade 2.66.0 -> 2.68.1
glslang: upgrade 11.2.0 -> 11.4.0
hdparm: upgrade 9.60 -> 9.61
libhandy: upgrade 1.2.1 -> 1.2.2
libjitterentropy: upgrade 3.0.1 -> 3.0.2
zangrc (1):
maintainers.inc: Modify email address
zhengruoqin (19):
epiphany: upgrade 3.38.2 -> 3.38.3
wpebackend-fdo: upgrade 1.8.0 -> 1.8.2
netbase: upgrade 6.2 -> 6.3
python3-dbusmock: upgrade 0.22.0 -> 0.23.0
python3-gitdb: upgrade 4.0.5 -> 4.0.7
libva: upgrade 2.10.0 -> 2.11.0
ruby: upgrade 3.0.0 -> 3.0.1
libva-utils: upgrade 2.10.0 -> 2.11.1
libdazzle: upgrade 3.38.0 -> 3.40.0
librepo: upgrade 1.13.0 -> 1.14.0
libdrm: upgrade 2.4.104 -> 2.4.105
python3-pygobject: upgrade 3.38.0 -> 3.40.1
libedit: upgrade 20210216-3.1 -> 20210419-3.1
libhandy: upgrade 1.2.0 -> 1.2.1
libical: upgrade 3.0.9 -> 3.0.10
libsolv: upgrade 0.7.18 -> 0.7.19
libmicrohttpd: upgrade 0.9.72 -> 0.9.73
python3-numpy: upgrade 1.20.1 -> 1.20.2
wireless-regdb: upgrade 2020.11.20 -> 2021.04.21
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Ibdaea694cae40b0749d472bf08b53002a45b31d7
diff --git a/poky/documentation/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst
index fb6dfca..b0d0385 100644
--- a/poky/documentation/kernel-dev/advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -67,8 +67,7 @@
.. note::
You can use the ``KBRANCH`` value to define an alternate branch typically
- with a machine override as shown here from the ``meta-yocto-bsp`` layer:
- ::
+ with a machine override as shown here from the ``meta-yocto-bsp`` layer::
KBRANCH_edgerouter = "standard/edgerouter"
@@ -106,15 +105,13 @@
variable to include features (configuration fragments, patches, or both)
that are not already included by the ``KMACHINE`` and
``LINUX_KERNEL_TYPE`` variable combination. For example, to include a
-feature specified as "features/netfilter/netfilter.scc", specify:
-::
+feature specified as "features/netfilter/netfilter.scc", specify::
KERNEL_FEATURES += "features/netfilter/netfilter.scc"
To include a
feature called "cfg/sound.scc" just for the ``qemux86`` machine,
-specify:
-::
+specify::
KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
@@ -157,8 +154,7 @@
While the kernel Metadata syntax does not enforce any logical separation
of configuration fragments, patches, features or kernel types, best
practices dictate a logical separation of these types of Metadata. The
-following Metadata file hierarchy is recommended:
-::
+following Metadata file hierarchy is recommended::
base/
bsp/
@@ -222,8 +218,7 @@
recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of
two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
``cfg`` directory of the ``yocto-4.12`` branch in the
-``yocto-kernel-cache`` Git repository:
-::
+``yocto-kernel-cache`` Git repository::
cfg/smp.scc:
define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds"
@@ -265,8 +260,7 @@
As described in the
":ref:`kernel-dev/common:validating configuration`" section, you can
-use the following BitBake command to audit your configuration:
-::
+use the following BitBake command to audit your configuration::
$ bitbake linux-yocto -c kernel_configcheck -f
@@ -287,8 +281,7 @@
``yocto-kernel-cache`` Git repository.
The following listings show the ``build.scc`` file and part of the
-``modpost-mask-trivial-warnings.patch`` file:
-::
+``modpost-mask-trivial-warnings.patch`` file::
patches/build/build.scc:
patch arm-serialize-build-targets.patch
@@ -334,8 +327,7 @@
Features are complex kernel Metadata types that consist of configuration
fragments, patches, and possibly other feature description files. As an
-example, consider the following generic listing:
-::
+example, consider the following generic listing::
features/myfeature.scc
define KFEATURE_DESCRIPTION "Enable myfeature"
@@ -371,15 +363,13 @@
``poky/meta/recipes-kernel/linux``, a
:ref:`require <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` directive
includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
-which has the following statement that defines the default kernel type:
-::
+which has the following statement that defines the default kernel type::
LINUX_KERNEL_TYPE ??= "standard"
Another example would be the real-time kernel (i.e.
``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel
-type as follows:
-::
+type as follows::
LINUX_KERNEL_TYPE = "preempt-rt"
@@ -412,8 +402,7 @@
For any given kernel type, the Metadata is defined by the ``.scc`` (e.g.
``standard.scc``). Here is a partial listing for the ``standard.scc``
file, which is found in the ``ktypes/standard`` directory of the
-``yocto-kernel-cache`` Git repository:
-::
+``yocto-kernel-cache`` Git repository::
# Include this kernel type fragment to get the standard features and
# configuration values.
@@ -482,15 +471,13 @@
For simplicity, consider the following root BSP layer description files
for the BeagleBone board. These files employ both a structure and naming
convention for consistency. The naming convention for the file is as
-follows:
-::
+follows::
bsp_root_name-kernel_type.scc
Here are some example root layer
BSP filenames for the BeagleBone Board BSP, which is supported by the
-Yocto Project:
-::
+Yocto Project::
beaglebone-standard.scc
beaglebone-preempt-rt.scc
@@ -498,8 +485,7 @@
Each file uses the root name (i.e "beaglebone") BSP name followed by the
kernel type.
-Examine the ``beaglebone-standard.scc`` file:
-::
+Examine the ``beaglebone-standard.scc`` file::
define KMACHINE beaglebone
define KTYPE standard
@@ -533,8 +519,7 @@
To separate your kernel policy from your hardware configuration, you
include a kernel type (``ktype``), such as "standard". In the previous
-example, this is done using the following:
-::
+example, this is done using the following::
include ktypes/standard/standard.scc
@@ -544,13 +529,11 @@
information.
To aggregate common configurations and features specific to the kernel
-for `mybsp`, use the following:
-::
+for `mybsp`, use the following::
include mybsp.scc
-You can see that in the BeagleBone example with the following:
-::
+You can see that in the BeagleBone example with the following::
include beaglebone.scc
@@ -558,15 +541,13 @@
configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section.
Finally, if you have any configurations specific to the hardware that
-are not in a ``*.scc`` file, you can include them as follows:
-::
+are not in a ``*.scc`` file, you can include them as follows::
kconf hardware mybsp-extra.cfg
The BeagleBone example does not include these
types of configurations. However, the Malta 32-bit board does
-("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file:
-::
+("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file::
define KMACHINE mti-malta32-le
define KMACHINE qemumipsel
@@ -623,8 +604,7 @@
included in each of the three "minnow" description files for the
supported kernel types (i.e. "standard", "preempt-rt", and "tiny").
Consider the "minnow" description for the "standard" kernel type (i.e.
-``minnow-standard.scc``):
-::
+``minnow-standard.scc``)::
define KMACHINE minnow
define KTYPE standard
@@ -656,8 +636,7 @@
kernel types. Using this command significantly reduces duplication.
Now consider the "minnow" description for the "tiny" kernel type (i.e.
-``minnow-tiny.scc``):
-::
+``minnow-tiny.scc``)::
define KMACHINE minnow
define KTYPE tiny
@@ -720,8 +699,7 @@
section for more information.
Here is an example that shows a trivial tree of kernel Metadata stored
-in recipe-space within a BSP layer:
-::
+in recipe-space within a BSP layer::
meta-my_bsp_layer/
`-- recipes-kernel
@@ -744,8 +722,7 @@
If the BSP description is in recipe space, you cannot simply list the
``*.scc`` in the ``SRC_URI`` statement. You need to use the following
-form from your kernel append file:
-::
+form from your kernel append file::
SRC_URI_append_myplatform = " \
file://myplatform;type=kmeta;destsuffix=myplatform \
@@ -759,8 +736,7 @@
Metadata to the build as a "type=kmeta" repository through the
:term:`SRC_URI` variable. As an
example, consider the following ``SRC_URI`` statement from the
-``linux-yocto_4.12.bb`` kernel recipe:
-::
+``linux-yocto_4.12.bb`` kernel recipe::
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
@@ -844,14 +820,12 @@
Once you have a new branch, you can set up your kernel Metadata to use
the branch a couple different ways. In the recipe, you can specify the
-new branch as the ``KBRANCH`` to use for the board as follows:
-::
+new branch as the ``KBRANCH`` to use for the board as follows::
KBRANCH = "mynewbranch"
Another method is to use the ``branch`` command in the BSP
-description:
-::
+description::
mybsp.scc:
define KMACHINE mybsp
@@ -865,15 +839,13 @@
If you find yourself with numerous branches, you might consider using a
hierarchical branching system similar to what the Yocto Linux Kernel Git
-repositories use:
-::
+repositories use::
common/kernel_type/machine
If you had two kernel types, "standard" and "small" for instance, three
machines, and common as ``mydir``, the branches in your Git repository
-might look like this:
-::
+might look like this::
mydir/base
mydir/standard/base
@@ -905,8 +877,7 @@
provide for this with the ``git merge`` command.
To merge a feature branch into a BSP, insert the ``git merge`` command
-after any ``branch`` commands:
-::
+after any ``branch`` commands::
mybsp.scc:
define KMACHINE mybsp
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index 56217b9..3f35d84 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -54,8 +54,7 @@
1. *Initialize the BitBake Environment:* Before building an extensible
SDK, you need to initialize the BitBake build environment by sourcing
- the build environment script (i.e. :ref:`structure-core-script`):
- ::
+ the build environment script (i.e. :ref:`structure-core-script`)::
$ cd poky
$ source oe-init-build-env
@@ -83,16 +82,14 @@
In this example we wish to build for qemux86 so we must set the
``MACHINE`` variable to "qemux86" and also add the "kernel-modules".
- As described we do this by appending to ``conf/local.conf``:
- ::
+ As described we do this by appending to ``conf/local.conf``::
MACHINE = "qemux86"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
3. *Create a Layer for Patches:* You need to create a layer to hold
patches created for the kernel image. You can use the
- ``bitbake-layers create-layer`` command as follows:
- ::
+ ``bitbake-layers create-layer`` command as follows::
$ cd poky/build
$ bitbake-layers create-layer ../../meta-mylayer
@@ -116,8 +113,7 @@
4. *Inform the BitBake Build Environment About Your Layer:* As directed
when you created your layer, you need to add the layer to the
:term:`BBLAYERS` variable in the
- ``bblayers.conf`` file as follows:
- ::
+ ``bblayers.conf`` file as follows::
$ cd poky/build
$ bitbake-layers add-layer ../../meta-mylayer
@@ -125,16 +121,14 @@
$
5. *Build the Extensible SDK:* Use BitBake to build the extensible SDK
- specifically for use with images to be run using QEMU:
- ::
+ specifically for use with images to be run using QEMU::
$ cd poky/build
$ bitbake core-image-minimal -c populate_sdk_ext
Once
the build finishes, you can find the SDK installer file (i.e.
- ``*.sh`` file) in the following directory:
- ::
+ ``*.sh`` file) in the following directory::
poky/build/tmp/deploy/sdk
@@ -143,8 +137,7 @@
6. *Install the Extensible SDK:* Use the following command to install
the SDK. For this example, install the SDK in the default
- ``poky_sdk`` directory:
- ::
+ ``poky_sdk`` directory::
$ cd poky/build/tmp/deploy/sdk
$ ./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-&DISTRO;.sh
@@ -172,8 +165,7 @@
BitBake shell used to build the installer.
After opening a new shell, run the SDK environment setup script as
- directed by the output from installing the SDK:
- ::
+ directed by the output from installing the SDK::
$ source poky_sdk/environment-setup-i586-poky-linux
"SDK environment now set up; additionally you may now run devtool to perform development tasks.
@@ -186,8 +178,7 @@
8. *Build the Clean Image:* The final step in preparing to work on the
kernel is to build an initial image using ``devtool`` in the new
- terminal you just set up and initialized for SDK work:
- ::
+ terminal you just set up and initialized for SDK work::
$ devtool build-image
Parsing recipes: 100% |##########################################| Time: 0:00:05
@@ -269,16 +260,14 @@
In this example we wish to build for qemux86 so we must set the
``MACHINE`` variable to "qemux86" and also add the "kernel-modules".
- As described we do this by appending to ``conf/local.conf``:
- ::
+ As described we do this by appending to ``conf/local.conf``::
MACHINE = "qemux86"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
3. *Create a Layer for Patches:* You need to create a layer to hold
patches created for the kernel image. You can use the
- ``bitbake-layers create-layer`` command as follows:
- ::
+ ``bitbake-layers create-layer`` command as follows::
$ cd poky/build
$ bitbake-layers create-layer ../../meta-mylayer
@@ -301,8 +290,7 @@
4. *Inform the BitBake Build Environment About Your Layer:* As directed
when you created your layer, you need to add the layer to the
:term:`BBLAYERS` variable in the
- ``bblayers.conf`` file as follows:
- ::
+ ``bblayers.conf`` file as follows::
$ cd poky/build
$ bitbake-layers add-layer ../../meta-mylayer
@@ -350,8 +338,7 @@
the ``yocto-4.12`` branch.
The following commands show how to create a local copy of the
- ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch:
- ::
+ ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch::
$ cd ~
$ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12
@@ -394,8 +381,7 @@
tools. These steps assume creation of a layer named ``mylayer`` in your
home directory:
-1. *Create Structure*: Create the layer's structure:
- ::
+1. *Create Structure*: Create the layer's structure::
$ mkdir meta-mylayer
$ mkdir meta-mylayer/conf
@@ -409,8 +395,7 @@
2. *Create the Layer Configuration File*: Move to the
``meta-mylayer/conf`` directory and create the ``layer.conf`` file as
- follows:
- ::
+ follows::
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
@@ -429,8 +414,7 @@
``meta-mylayer/recipes-kernel/linux`` directory and create the
kernel's append file. This example uses the ``linux-yocto-4.12``
kernel. Thus, the name of the append file is
- ``linux-yocto_4.12.bbappend``:
- ::
+ ``linux-yocto_4.12.bbappend``::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -483,8 +467,7 @@
:term:`FILESPATH` search path by
prepending the directory that contains your files to the
:term:`FILESEXTRAPATHS`
-variable as follows:
-::
+variable as follows::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -492,8 +475,7 @@
expands to "linux-yocto" in the current directory for this example. If
you add any new files that modify the kernel recipe and you have
extended ``FILESPATH`` as described above, you must place the files in
-your layer in the following area:
-::
+your layer in the following area::
your-layer/recipes-kernel/linux/linux-yocto/
@@ -582,8 +564,7 @@
similar procedure. Here is an example that groups separate
configurations specifically for Ethernet and graphics into their own
files and adds the configurations by using a ``SRC_URI`` statement like
-the following in your append file:
-::
+the following in your append file::
SRC_URI += "file://myconfig.cfg \
file://eth.cfg \
@@ -627,8 +608,7 @@
statements.
For example, you can apply a three-patch series by adding the following
-lines to your linux-yocto ``.bbappend`` file in your layer:
-::
+lines to your linux-yocto ``.bbappend`` file in your layer::
SRC_URI += "file://0001-first-change.patch"
SRC_URI += "file://0002-second-change.patch"
@@ -658,8 +638,7 @@
to use for the configuration, as before, copy that file to the
appropriate ``${PN}`` directory in your layer's ``recipes-kernel/linux``
directory, and rename the copied file to "defconfig". Then, add the
-following lines to the linux-yocto ``.bbappend`` file in your layer:
-::
+following lines to the linux-yocto ``.bbappend`` file in your layer::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig"
@@ -685,8 +664,7 @@
incremental change you want to make and add that as a configuration
fragment. For example, if you want to add support for a basic serial
console, create a file named ``8250.cfg`` in the ``${PN}`` directory
-with the following content (without indentation):
-::
+with the following content (without indentation)::
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
@@ -698,8 +676,7 @@
Next, include this
configuration fragment and extend the ``FILESPATH`` variable in your
-``.bbappend`` file:
-::
+``.bbappend`` file::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://8250.cfg"
@@ -718,8 +695,7 @@
through a ``defconfig`` file that is pulled from the kernel source tree
for the configured machine. By default, the OpenEmbedded build system
looks for ``defconfig`` files in the layer used for Metadata, which is
-"out-of-tree", and then configures them using the following:
-::
+"out-of-tree", and then configures them using the following::
SRC_URI += "file://defconfig"
@@ -732,16 +708,14 @@
``defconfig`` file that is "in-tree".
To specify an "in-tree" ``defconfig`` file, use the following statement
-form:
-::
+form::
KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
Here is an example
that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2"
and provides the path to the "in-tree" ``defconfig`` file to be used for
-a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset:
-::
+a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
@@ -792,8 +766,7 @@
":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
section for more information.
- Use the following ``devtool`` command to check out the code:
- ::
+ Use the following ``devtool`` command to check out the code::
$ devtool modify linux-yocto
@@ -819,14 +792,12 @@
noted where you can find the source files (e.g.
``poky_sdk/workspace/sources/linux-yocto``). Change to where the
kernel source code is before making your edits to the
- ``calibrate.c`` file:
- ::
+ ``calibrate.c`` file::
$ cd poky_sdk/workspace/sources/linux-yocto
2. *Edit the source file*: Edit the ``init/calibrate.c`` file to have
- the following changes:
- ::
+ the following changes::
void calibrate_delay(void)
{
@@ -846,8 +817,7 @@
.
3. *Build the Updated Kernel Source:* To build the updated kernel
- source, use ``devtool``:
- ::
+ source, use ``devtool``::
$ devtool build linux-yocto
@@ -872,8 +842,7 @@
using QEMU to verify your changes:
1. *Boot the image*: Boot the modified image in the QEMU emulator
- using this command:
- ::
+ using this command::
$ runqemu qemux86
@@ -891,8 +860,7 @@
6. *Stage and commit your changes*: Within your eSDK terminal, change
your working directory to where you modified the ``calibrate.c`` file
- and use these Git commands to stage and commit your changes:
- ::
+ and use these Git commands to stage and commit your changes::
$ cd poky_sdk/workspace/sources/linux-yocto
$ git status
@@ -921,8 +889,7 @@
image that includes your kernel patches. Execute the following
command from your
:term:`Build Directory` in the terminal
- set up to run BitBake:
- ::
+ set up to run BitBake::
$ cd poky/build
$ bitbake core-image-minimal
@@ -966,14 +933,12 @@
1. *Change the working directory*: You need to locate the source
files in the local copy of the kernel Git repository. Change to
where the kernel source code is before making your edits to the
- ``calibrate.c`` file:
- ::
+ ``calibrate.c`` file::
$ cd ~/linux-yocto-4.12/init
2. *Edit the source file*: Edit the ``calibrate.c`` file to have the
- following changes:
- ::
+ following changes::
void calibrate_delay(void)
{
@@ -993,8 +958,7 @@
.
2. *Stage and Commit Your Changes:* Use standard Git commands to stage
- and commit the changes you just made:
- ::
+ and commit the changes you just made::
$ git add calibrate.c
$ git commit -m "calibrate.c - Added some printk statements"
@@ -1009,13 +973,11 @@
updated kernel source files. Add
:term:`SRC_URI` and
:term:`SRCREV` statements similar
- to the following to your ``local.conf``:
- ::
+ to the following to your ``local.conf``::
$ cd poky/build/conf
- Add the following to the ``local.conf``:
- ::
+ Add the following to the ``local.conf``::
SRC_URI_pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
git:///path-to/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
@@ -1031,16 +993,14 @@
4. *Build the Image:* With the source modified, your changes staged and
committed, and the ``local.conf`` file pointing to the kernel files,
- you can now use BitBake to build the image:
- ::
+ you can now use BitBake to build the image::
$ cd poky/build
$ bitbake core-image-minimal
5. *Boot the image*: Boot the modified image in the QEMU emulator using
this command. When prompted to login to the QEMU console, use "root"
- with no password:
- ::
+ with no password::
$ cd poky/build
$ runqemu qemux86
@@ -1059,8 +1019,7 @@
7. *Generate the Patch File:* Once you are sure that your patch works
correctly, you can generate a ``*.patch`` file in the kernel source
- repository:
- ::
+ repository::
$ cd ~/linux-yocto-4.12/init
$ git format-patch -1
@@ -1073,8 +1032,7 @@
``meta-mylayer``. When the layer was created using the
``yocto-create`` script, no additional hierarchy was created to
support patches. Before moving the patch file, you need to add
- additional structure to your layer using the following commands:
- ::
+ additional structure to your layer using the following commands::
$ cd ~/meta-mylayer
$ mkdir recipes-kernel
@@ -1083,8 +1041,7 @@
Once you have created this
hierarchy in your layer, you can move the patch file using the
- following command:
- ::
+ following command::
$ mv ~/linux-yocto-4.12/init/0001-calibrate.c-Added-some-printk-statements.patch ~/meta-mylayer/recipes-kernel/linux/linux-yocto
@@ -1093,8 +1050,7 @@
the OpenEmbedded build system to find the patch. The append file
needs to be in your layer's ``recipes-kernel/linux`` directory and it
must be named ``linux-yocto_4.12.bbappend`` and have the following
- contents:
- ::
+ contents::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
@@ -1113,8 +1069,7 @@
To build ``core-image-minimal`` again and see the effects of your patch,
you can essentially eliminate the temporary source files saved in
``poky/build/tmp/work/...`` and residual effects of the build by entering
- the following sequence of commands:
- ::
+ the following sequence of commands::
$ cd poky/build
$ bitbake -c cleanall yocto-linux
@@ -1160,8 +1115,7 @@
- You must be sure of the state of your build's configuration in the
:term:`Source Directory`.
-- Your build host must have the following two packages installed:
- ::
+- Your build host must have the following two packages installed::
libncurses5-dev
libtinfo-dev
@@ -1169,8 +1123,7 @@
The following commands initialize the BitBake environment, run the
:ref:`ref-tasks-kernel_configme`
task, and launch ``menuconfig``. These commands assume the Source
-Directory's top-level folder is ``poky``:
-::
+Directory's top-level folder is ``poky``::
$ cd poky
$ source oe-init-build-env
@@ -1232,8 +1185,7 @@
Within the ``.config`` file, you can see the kernel settings. For
example, the following entry shows that symmetric multi-processor
-support is not set:
-::
+support is not set::
# CONFIG_SMP is not set
@@ -1274,8 +1226,7 @@
file to "defconfig" (e.g.
``~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig``). Then,
add the following lines to the linux-yocto ``.bbappend`` file in your
-layer:
-::
+layer::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig"
@@ -1323,8 +1274,7 @@
It is simple to create a configuration fragment. One method is to use
shell commands. For example, issuing the following from the shell
creates a configuration fragment file named ``my_smp.cfg`` that enables
-multi-processor support within the kernel:
-::
+multi-processor support within the kernel::
$ echo "CONFIG_SMP=y" >> my_smp.cfg
@@ -1342,8 +1292,7 @@
steps:
1. *Complete a Build Through Kernel Configuration:* Complete a build at
- least through the kernel configuration task as follows:
- ::
+ least through the kernel configuration task as follows::
$ bitbake linux-yocto -c kernel_configme -f
@@ -1352,8 +1301,7 @@
your build state might become unknown, it is best to run this task
prior to starting ``menuconfig``.
-2. *Launch menuconfig:* Run the ``menuconfig`` command:
- ::
+2. *Launch menuconfig:* Run the ``menuconfig`` command::
$ bitbake linux-yocto -c menuconfig
@@ -1361,8 +1309,7 @@
to prepare a configuration fragment. The resulting file
``fragment.cfg`` is placed in the
``${``\ :term:`WORKDIR`\ ``}``
- directory:
- ::
+ directory::
$ bitbake linux-yocto -c diffconfig
@@ -1387,8 +1334,7 @@
directory named ``linux-yocto`` that resides in the same directory as
the kernel's append file within your layer and then add the following
statements to the kernel's append file, those configuration options will
-be picked up and applied when the kernel is built:
-::
+be picked up and applied when the kernel is built::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://myconfig.cfg"
@@ -1397,8 +1343,7 @@
files and name them all in the ``SRC_URI`` statement as well. For
example, you could group separate configurations specifically for
Ethernet and graphics into their own files and add those by using a
-``SRC_URI`` statement like the following in your append file:
-::
+``SRC_URI`` statement like the following in your append file::
SRC_URI += "file://myconfig.cfg \
file://eth.cfg \
@@ -1409,8 +1354,7 @@
You can use the
:ref:`ref-tasks-kernel_configcheck`
-task to provide configuration validation:
-::
+task to provide configuration validation::
$ bitbake linux-yocto -c kernel_configcheck -f
@@ -1537,8 +1481,7 @@
successfully. Use this configuration file as your baseline.
2. *Run Configure and Check Tasks:* Separately run the
- ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks:
- ::
+ ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks::
$ bitbake linux-yocto -c kernel_configme -f
$ bitbake linux-yocto -c kernel_configcheck -f
@@ -1572,8 +1515,7 @@
Sometimes it is helpful to determine what a variable expands to during a
build. You can examine the values of variables by examining the
output of the ``bitbake -e`` command. The output is long and is more
-easily managed in a text file, which allows for easy searches:
-::
+easily managed in a text file, which allows for easy searches::
$ bitbake -e virtual/kernel > some_text_file
@@ -1590,15 +1532,13 @@
1. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned
Git repository (source directory) and use the following Git command
- to list the files that have been changed, added, or removed:
- ::
+ to list the files that have been changed, added, or removed::
$ git status
2. *Commit the Changes:* You should commit those changes to the kernel
source tree regardless of whether or not you will save, export, or
- use the changes:
- ::
+ use the changes::
$ git add
$ git commit -s -a -m "getting rid of -dirty"
@@ -1633,8 +1573,7 @@
``kernel.org`` sources and the Yocto Project Linux kernel tools for
managing kernel Metadata. You can find this recipe in the ``poky`` Git
repository of the Yocto Project :yocto_git:`Source Repository <>`
-at:
-::
+at::
poky/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
@@ -1655,8 +1594,7 @@
``defconfig`` file or configuration fragment files in your layer.
When you use the ``linux-yocto-custom.bb`` recipe, you must specify a
configuration. If you do not have a ``defconfig`` file, you can run
- the following:
- ::
+ the following::
$ make defconfig
@@ -1708,8 +1646,7 @@
``LINUX_VERSION`` with the Source Control Manager (SCM) revision
as derived from the :term:`SRCPV`
variable. The combined results are a string with the following
- form:
- ::
+ form::
3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
@@ -1723,8 +1660,7 @@
triggers an explicit build failure. You must change it to match a
list of the machines that your new recipe supports. For example,
to support the ``qemux86`` and ``qemux86-64`` machines, use the
- following form:
- ::
+ following form::
COMPATIBLE_MACHINE = "qemux86|qemux86-64"
@@ -1807,8 +1743,7 @@
Depending on the build system used by the module sources, you might need
to make some adjustments. For example, a typical module ``Makefile``
-looks much like the one provided with the ``hello-mod`` template:
-::
+looks much like the one provided with the ``hello-mod`` template::
obj-m := hello.o
@@ -1845,8 +1780,7 @@
- :term:`MACHINE_EXTRA_RRECOMMENDS`
Modules are often not required for boot and can be excluded from certain
-build configurations. The following allows for the most flexibility:
-::
+build configurations. The following allows for the most flexibility::
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
@@ -1895,26 +1829,22 @@
$ git whatchanged origin/standard/base..origin/standard/emenlow
-To see short, one line summaries of changes use the ``git log`` command:
-::
+To see short, one line summaries of changes use the ``git log`` command::
$ git log --oneline origin/standard/base..origin/standard/emenlow
-Use this command to see code differences for the changes:
-::
+Use this command to see code differences for the changes::
$ git diff origin/standard/base..origin/standard/emenlow
Use this command to see the commit log messages and the text
-differences:
-::
+differences::
$ git show origin/standard/base..origin/standard/emenlow
Use this command to create individual patches for each change. Here is
an example that creates patch files for each commit and places them
-in your ``Documents`` directory:
-::
+in your ``Documents`` directory::
$ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
@@ -1923,15 +1853,13 @@
Tags in the Yocto Project kernel tree divide changes for significant
features or branches. The ``git show`` tag command shows changes based
-on a tag. Here is an example that shows ``systemtap`` changes:
-::
+on a tag. Here is an example that shows ``systemtap`` changes::
$ git show systemtap
You can use the ``git branch --contains`` tag command to
show the branches that contain a particular feature. This command shows
-the branches that contain the ``systemtap`` feature:
-::
+the branches that contain the ``systemtap`` feature::
$ git branch --contains systemtap
@@ -1986,8 +1914,7 @@
searched during the build as potential feature directories.
Continuing with the example, suppose the "test.scc" feature you are
- adding has a ``test.scc`` file in the following directory:
- ::
+ adding has a ``test.scc`` file in the following directory::
my_recipe
|
@@ -2001,8 +1928,7 @@
a similarly named configuration fragment file ``test.cfg``.
2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the
- recipe's ``SRC_URI`` statement:
- ::
+ recipe's ``SRC_URI`` statement::
SRC_URI_append = " file://test.scc"
@@ -2011,8 +1937,7 @@
3. *Specify the Feature as a Kernel Feature:* Use the
``KERNEL_FEATURES`` statement to specify the feature as a kernel
- feature:
- ::
+ feature::
KERNEL_FEATURES_append = " test.scc"
diff --git a/poky/documentation/kernel-dev/concepts-appx.rst b/poky/documentation/kernel-dev/concepts-appx.rst
index 4b6dbe5..63e6731 100644
--- a/poky/documentation/kernel-dev/concepts-appx.rst
+++ b/poky/documentation/kernel-dev/concepts-appx.rst
@@ -359,8 +359,7 @@
"non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
files that classify individual or groups of options as either hardware
or non-hardware. To better show this, consider a situation where the
-``yocto-kernel-cache`` contains the following files:
-::
+``yocto-kernel-cache`` contains the following files::
yocto-kernel-cache/features/drm-psb/hardware.cfg
yocto-kernel-cache/features/kgdb/hardware.cfg
@@ -400,8 +399,7 @@
(i.e. ``hardware.kcf`` or ``non-hardware.kcf``).
Here is a specific example using the
-``kernel-cache/bsp/mti-malta32/hardware.cfg``:
-::
+``kernel-cache/bsp/mti-malta32/hardware.cfg``::
CONFIG_SERIAL_8250
CONFIG_SERIAL_8250_CONSOLE
diff --git a/poky/documentation/kernel-dev/faq.rst b/poky/documentation/kernel-dev/faq.rst
index c2106f8..8169511 100644
--- a/poky/documentation/kernel-dev/faq.rst
+++ b/poky/documentation/kernel-dev/faq.rst
@@ -57,8 +57,7 @@
For example, set the following in the ``qemux86.conf`` file to include
the ``ab123`` kernel modules with images built for the ``qemux86``
-machine:
-::
+machine::
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
@@ -71,8 +70,7 @@
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:
-::
+following::
APPEND += "printk.time=y initcall_debug debug"
diff --git a/poky/documentation/kernel-dev/maint-appx.rst b/poky/documentation/kernel-dev/maint-appx.rst
index 44c4389..f84ab6e 100644
--- a/poky/documentation/kernel-dev/maint-appx.rst
+++ b/poky/documentation/kernel-dev/maint-appx.rst
@@ -28,8 +28,7 @@
Linux kernel source repository and ``yocto-kernel-cache`` Git trees. For
example, the following commands clone the Yocto Project baseline Linux
kernel that branches off ``linux.org`` version 4.12 and the
-``yocto-kernel-cache``, which contains stores of kernel Metadata:
-::
+``yocto-kernel-cache``, which contains stores of kernel Metadata::
$ git clone git://git.yoctoproject.org/linux-yocto-4.12
$ git clone git://git.yoctoproject.org/linux-kernel-cache
@@ -42,16 +41,14 @@
Once you have cloned the kernel Git repository and the cache of Metadata
on your local machine, you can discover the branches that are available
-in the repository using the following Git command:
-::
+in the repository using the following Git command::
$ git branch -a
Checking out a branch allows you to work with a particular Yocto Linux
kernel. For example, the following commands check out the
"standard/beagleboard" branch of the Yocto Linux kernel repository and
-the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository:
-::
+the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository::
$ cd ~/linux-yocto-4.12
$ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard
@@ -111,8 +108,7 @@
For a typical build, the target of the search is a feature
description in an ``.scc`` file whose name follows this format (e.g.
- ``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``):
- ::
+ ``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``)::
bsp_root_name-kernel_type.scc
@@ -222,8 +218,7 @@
local Git source repository tree. This build tree has a name that uses
the following form, where ``${MACHINE}`` is the metadata name of the
machine (BSP) and "kernel_type" is one of the Yocto Project supported
-kernel types (e.g. "standard"):
-::
+kernel types (e.g. "standard")::
linux-${MACHINE}-kernel_type-build