| Yocto-based build | Standalone build | |
|---|---|---|
| Recommended for | Full BSP integration, production images, or when modifying kernel recipes and configuration fragments | Rapid kernel iteration: compile, test, and deploy kernel changes without building the full image |
| Tooling | kas / BitBake with the meta-qcom layer | Docker-based kmake-image with aarch64 cross-toolchain |
| Build scope | Kernel + root file system + all packages | Kernel and in-tree modules only; out-of-tree module builds require the Yocto sysroot |
| Kernel configuration | Yocto bbappend fragments and defconfig patches | Direct menuconfig or .config editing |
| Setup complexity | Higher: full Yocto workspace and layer checkout required | Lower: Docker image provides all required dependencies |
| Deploy method | Flash full image via fastboot | Update kernel UKI image on the ESP partition |
- Yocto-based build: see Build the Kernel with Yocto
- Standalone build: see Build the kernel without Yocto
When to modify the kernel
Not all Qualcomm Linux use cases require kernel modification. The following table helps you decide: Table: When to modify the kernel| Scenario | Action needed |
|---|---|
| Running existing applications on a supported SoC and board | No kernel changes required. Use the pre-built BSP image. |
| Enabling or disabling a kernel driver or subsystem | Modify the kernel configuration (defconfig or a config fragment). See Modify the kernel. |
| Adding support for a new peripheral or sensor | Add or modify a device tree node. Rebuild the DTB. See Build and deploy DTBs. |
| Implementing a new kernel driver or subsystem | Write and integrate a new driver. Build the kernel and test. See Modify the kernel. |
| Achieving deterministic real-time latency | Switch to the RT kernel build. See RT kernel fundamentals. |
| Porting the kernel to a new board or SoC variant | Add device tree support and any required driver changes. |