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.- To set up your host and clone the source, see Access kernel sources.
- To configure the kernel and build an image, see Build the kernel using Yocto.
- To build the kernel without Yocto, see Build the kernel without Yocto.
- To flash and verify after a build, see Install & boot the kernel.
Unpack the kernel source
Usedevtool 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.
- Clone
meta-qcomat a release tag. Release tags follow theqli-<version>convention (for example,qli-2.0). For available tags, see the Qualcomm Linux release notes - Introduction.
- 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.
-
Open a kas shell. Replace
rb3gen2-core-kit.ymlwith the machine YML that matches your board. All supported machine YML files are inmeta-qcom/ci/.
- Unpack the kernel source into the devtool workspace:
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 inbuild/workspace/sources/linux-qcom.
To modify the kernel configuration interactively:
- Open a kas shell (replace
rb3gen2-core-kit.ymlwith your machine YML):
- Launch
menuconfigvia devtool:
- The configuration fragment is saved to:
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.- Open a kas shell (replace
rb3gen2-core-kit.ymlwith your machine YML):
- Build the kernel only (faster than a full image build):
- Build the full flashable image when ready to deploy:
- 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.
Maintain kernel changes
Usedevtool finish to export your changes as patches and wire them into a
custom meta-layer:
- Open a kas shell (replace
rb3gen2-core-kit.ymlwith your machine YML):
- Create and register a custom layer (first time only):
- Export patches and configuration fragments into the layer:
devtool finish, the layer is updated with:
- Kernel patches in
meta-<mylayer>/recipes-kernel/linux/linux-qcom/*.patch - A
bbappendthat adds those patches toSRC_URI - The
build/workspaceentry is removed
bbappend looks like:
- Rebuild the image from the layer to verify the patches apply cleanly:
Clean up the workspace
To discard the devtool workspace and return to a clean state:- Open a kas shell (replace
rb3gen2-core-kit.ymlwith your machine YML):
- Remove the custom layer:
- Reset the devtool workspace:
- Delete the workspace directory:
Next steps
- To debug kernel issues, see Configure debug methods.

