Yocto Developer Guide
This guide is intended to help developers understand the Yocto framework in RDK so they can extend the existing functionality.
BitBake Main Tasks
Bitbake executes all the layers starting with a prefix ‘meta’. It parses the build classes, configuration files, and recipes and executes each task by creating a shell script on-the-fly.
TASK | DESCRIPTION | FUNCTION |
Build | Default task for a recipe – depends on all other normal tasks required to ‘build’ a recipe | do_build |
Init RAMFS | Combines an initial ramdisk image and kernel together to form a single image | do_bundle_initramfs |
Check URI | Validates the SRC_URI value | do_checkuri |
Clean | Removes all output files for a target | do_clean |
Clean all | Removes all output files, shared state cache, and downloaded source files for a target | do_cleanall |
Clean SSTATE | Removes all output files and shared state cache for a target | do_cleansstate |
Compile | Compiles the source in the compilation directory | do_compile |
Configure | Configures the source by enabling and disabling any build-time and configuration options for the software being built | do_configure |
Dev Shell | Starts a shell with the environment set up for development/debugging | do_devshell |
Fetch | Fetches the source code | do_fetch |
Install | Copies files from the compilation directory to a holding area | do_install |
List Tasks | Lists all defined tasks for a target | do_listtasks |
Package | Analyzes the content of the holding area and splits it into subsets based on available packages and files | do_package |
Package QA | Runs QA checks on packaged files | do_package_qa |
Write IPK | Creates the actual IPK packages and places them in the Package Feed area | do_package_write_ipk |
Patch | Locates patch files and applies them to the source code | do_patch |
Populate License | Writes license information for the recipe that is collected later when the image is constructed | do_populate_lic |
Populate SDK | Creates the file and directory structure for an installable SDK | do_populate_sdk |
Populate SYSROOT | Copies a subset of files installed by do_install into the sysroot in order to make them available to other recipes | do_populate_sysroot |
Root FS | Creates the root filesystem (file and directory structure) for an image | do_rootfs |
Unpack | Unpacks the source code into a working directory | do_unpack |
Configuration
Configuration (*.conf) comprises of global definition of variables. There are two types of configurations:
- User configuration
- Machine configuration(BSP)
User Configuration
Machine/BSP Configuration
BSPs are layers that add machine settings and recipes. It contains extensions and customizations to base system. They are added to the BBLAYERS variable in build/conf/bblayers.conf
Machine settings are specified in a layer’s conf/machine/xxx.conffile(s)
For Example:
../meta-rdk-bsp-emulator/conf/machine/qemux86hyb.conf
For Device:
../meta-rdk-oem-<OEM Name>-<SoCName>/conf/machine/<configuration_file_name>.conf
RDK Recipes
Recipes are the most basic metadata files which are denoted by the file extension*.bb. Recipes can build one or more packages from source code.
They provide:
- Descriptive information about the package
- Existing dependencies (both build and runtime dependencies)
- DEPENDS & RDEPENDS variables holds the build & runtime dependencies e.g.
- DEPENDS = “closedcaption-hal-headers”
- RDEPENDS = “libcrypto”
- Where the source code resides and how to fetch it,
- SRC_URI variable holds the URL path to fetch
- SRC_URI = “${RDK_GENERIC_ROOT_GIT}/devicesettings/generic;protocol=${RDK_GIT_PROTOCOL};branch=${RDK_GIT_BRANCH}”
- The version of the recipe
- SRCREV= “${AUTOREV}” /
- SRCREV= “6c492f7452a6b4b240f1b572dbda2f2bcc4faf2d”
- Whether the source code requires any patches, where to find them, and how to apply them
- How to configure and compile the source code
- Where on the target machine to install the package or packages created
Recipe Append files
Append files are identified by the extension *.bbappend. They are used to extend or override information in an existing recipe file. BitBake expects every append file to have a corresponding recipe (*.bb) file. A missing .bb file will be shown as an warning by the BitBake parser. The append file and corresponding recipe file must use the same root filename.
Example: devicesettings_git.bb & devicesettings_git.bbappend
Bitbake variables/meta data
These are set automatically by bitbake.
- TOPDIR – The build directory
- LAYERDIR – Current layer directory
- FILE – Path and filename of file being processed
Build time meta-data
- PN – Pakage name (“myrecipe”)
- PV – Package version (1.0)
- PR – Package Release (r0)
- P = “${PN}-${PV}”
- PF = “${PN}-${PV}-${PR}”
- FILE_DIRNAME – Directory for FILE
- FILESPATH = “${FILE_DIRNAME}/${PF}:
- TOPDIR – The build directory
- TMPDIR = “${TOPDIR}/tmp”
- WORKDIR = ${TMPDIR}/work/${PF}”
- S = “${WORKDIR}/${P}” (Source dir)
- B = “${S}” (Build dir)
- D = “${WORKDIR}/${image}” (Destination dir)
- DEPLOY_DIR = “${TMPDIR}/deploy”
- DEPLOY_DIR_IMAGE = “${DEPLOY_DIR}/images”
Dependency meta-data
Build time package variables
- DEPENDS – Build time package dependencies
- PROVIDES = “${P} ${PF} ${PN}”
Runtime package variables
- RDEPENDS – Runtime package dependencies
- RRECOMMENDS – Runtime recommended packages
- RSUGGESTS – Runtime suggested packages
- RPROVIDES – Runtime provides
- RCONFLICTS – Runtime package conflicts
- RREPLACES – Runtime package replaces
Common meta-data
Variables you commonly set
- SUMMARY – Short description of package/recipe
- HOMEPAGE – Upstream web page
- LICENSE – Licenses of included source code
- LIC_FILES_CHKSUM – Checksums of license files at time of packaging (checked for change by build)
- SRC_URI – URI of source code, patches and extra files to be used to build packages. Uses different fetchers based on the URI.
- FILES – Files to be included in binary packages
Patching
Patches can be applied to recipe files. Patch files extension *.patch. Place the patch file in subdirectory of recipe named (component) folder. The subdirectory should be preferably named as that of component or as ‘files’. Add the below line to the recipe file
SRC_URI += “file://temp.patch“
More information on patches can be found here
Prebuilts with Yocto
SSTATE ( shared state ) is the way OE speeds up builds. A much detailed conceptual description please read http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache
OE/Yocto has a feature called SSTATE(shared state) to deliver prebuilts amongst users. Shared state is currently configured with OE/Yocto projects.
Leave a Reply