Skip to main content
The Qualcomm® Linux kernel is developed using the Yocto devtool workflow. This page covers the edit–build–maintain cycle for making kernel source and configuration changes within a Yocto workspace.
This page covers the Yocto devtool workflow only. For faster iteration on kernel-only changes without building a full image, see Build the kernel without Yocto.
Before starting, ensure your host is set up with the required tools (kas, git, and the Yocto build dependencies). See Prerequisites & host setup.
For more information about Yocto kernel development provisions, see Yocto Project Linux Kernel Development.

Unpack the kernel source

Use devtool to unpack the kernel source into a local workspace for editing. devtool modify checks out the kernel source into the devtool workspace and rewires the recipe to build from that local copy, so your edits are picked up automatically on the next build without re-fetching from upstream.
  1. Clone meta-qcom at a release tag. Release tags follow the qli-<version> convention (for example, qli-2.0). For available tags, see the Qualcomm Linux release notes - Introduction.
git clone https://github.com/qualcomm-linux/meta-qcom.git -b <release-tag>
  1. Sync all meta-layers at their pinned revisions. If you have already completed the sync steps in Build the kernel using Yocto, this step is already done.
  2. Open a kas shell. Replace rb3gen2-core-kit.yml with the machine YML that matches your board. All supported machine YML files are in meta-qcom/ci/.
kas shell meta-qcom/ci/rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml
  1. Unpack the kernel source into the devtool workspace:
devtool modify linux-qcom
The kernel source is checked out to build/workspace/sources/linux-qcom.
For the mainline BSP, use linux-qcom-next and set PREFERRED_PROVIDER_virtual/kernel = "linux-qcom-next" in build/conf/local.conf before unpacking.

Make kernel config changes

Edit kernel source or configuration in build/workspace/sources/linux-qcom. To modify the kernel configuration interactively:
  1. Open a kas shell (replace rb3gen2-core-kit.yml with your machine YML):
kas shell meta-qcom/ci/rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml
  1. Launch menuconfig via devtool:
devtool menuconfig linux-qcom
  1. The configuration fragment is saved to:
build/workspace/sources/linux-qcom/oe-local-files/devtool-fragment.cfg
For the mainline kernel, replace linux-qcom with linux-qcom-next.

Build and test your changes

After editing the kernel source or configuration, build and deploy the kernel to verify your changes on hardware before committing them.
  1. Open a kas shell (replace rb3gen2-core-kit.yml with your machine YML):
kas shell meta-qcom/ci/rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml
  1. Build the kernel only (faster than a full image build):
devtool build linux-qcom
  1. Build the full flashable image when ready to deploy:
devtool build-image qcom-multimedia-image
  1. Flash the updated kernel images and reboot. See Install & boot the kernel for the full flashing procedure and post-boot verification steps.

Commit the kernel changes

After editing and testing, commit your changes inside the devtool workspace so they can be exported as patches. The -s flag adds a Signed-off-by: trailer, which is required for patches submitted upstream.
cd build/workspace/sources/linux-qcom
git add .
git commit -s -m "my changes"

Maintain kernel changes

Use devtool finish to export your changes as patches and wire them into a custom meta-layer:
  1. Open a kas shell (replace rb3gen2-core-kit.yml with your machine YML):
kas shell meta-qcom/ci/rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml
  1. Create and register a custom layer (first time only):
bitbake-layers create-layer ~/meta-<mylayer>
mkdir -p ~/meta-<mylayer>/recipes-kernel/linux/linux-qcom
bitbake-layers add-layer ~/meta-<mylayer>
  1. Export patches and configuration fragments into the layer:
devtool finish linux-qcom ~/meta-<mylayer>
After devtool finish, the layer is updated with:
  • Kernel patches in meta-<mylayer>/recipes-kernel/linux/linux-qcom/*.patch
  • A bbappend that adds those patches to SRC_URI
  • The build/workspace entry is removed
The resulting bbappend looks like:
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://devtool-fragment.cfg \
            file://0001-my-patch.patch"
  1. Rebuild the image from the layer to verify the patches apply cleanly:
devtool build-image qcom-multimedia-image

Clean up the workspace

To discard the devtool workspace and return to a clean state:
  1. Open a kas shell (replace rb3gen2-core-kit.yml with your machine YML):
kas shell meta-qcom/ci/rb3gen2-core-kit.yml:meta-qcom/ci/qcom-distro.yml
  1. Remove the custom layer:
bitbake-layers remove-layer ~/meta-<mylayer>
  1. Reset the devtool workspace:
devtool reset linux-qcom
  1. Delete the workspace directory:
rm -rf build/workspace/sources/linux-qcom

Next steps