Skip to main content
After a successful build, the Qualcomm® Linux boot system uses two flashed images to bring up the kernel: efi.bin (ESP partition) and dtb.bin (DTB partition).

​
Image composition

The Yocto build packages kernel artifacts into flashable images:
  • efi.bin is the EFI System Partition (ESP) image. Contains systemd-boot (boot manager) and the kernel packaged as a UKI type-2 image, which bundles the kernel, initramfs, and optionally a device tree. Flashed to the efi partition.
  • dtb.bin is the DTB partition image. Contains all compiled device tree blobs (DTBs). Flashed to the dtb_a partition.
Table: Kernel build artifacts
ImageImage nameBuild deploy pathDetails
Kernel ELFvmlinuxbuild/tmp/deploy/images/<machine>/<image>-*.rootfs.qcomflash/Output kernel ELF with debug symbols.
Initramfsinitramfs-qcom-image-<machine>.cpio.gzbuild/tmp/deploy/images/<machine>/Initramfs in CPIO format.
Kernel imageImagebuild/tmp/deploy/images/<machine>/Raw kernel binary. systemd-boot does not support compressed images.
Kernel modulesmodules-<machine>.tgzbuild/tmp/deploy/images/<machine>/Dynamically loadable kernel modules (DLKMs).
Device tree blobs<SoC>-<board>-<variant>.dtbbuild/tmp/deploy/images/<machine>/Individual device tree blobs.
ESP partitionefi.binbuild/tmp/deploy/images/<machine>/<image>-*.rootfs.qcomflash/systemd-boot, kernel, and initramfs packaged as a UKI type-2 image.
DTB partitiondtb.binbuild/tmp/deploy/images/<machine>/<image>-*.rootfs.qcomflash/All DTBOs packaged in a FIT image.

​
Deploy kernel artifacts

If you have not previously flashed all boot binaries, follow the full flashing instructions in the BSP image build with firmware first. For subsequent kernel-only updates, you can incrementally flash just efi.bin and dtb.bin: 
# Navigate to the build output directory
cd build/tmp/deploy/images/<machine>/<image>-*.rootfs.qcomflash/

# Flash the ESP and DTB partition images
fastboot flash efi efi.bin
fastboot flash dtb_a dtb.bin
fastboot reboot
Both efi.bin and dtb.bin must be flashed together after a kernel or DTS change to keep the kernel and device tree in sync.

​
Verify the running kernel

After the device reboots, confirm that the expected kernel version is running and that the boot completed without errors.

​
Connect to the device

Use one of the following methods to access a shell on the device:
  • Serial console (UART) is recommended for early-boot inspection. For setup instructions see Connect to your target.
  • ADB shell once the device has fully booted:
adb shell
  • SSH to connect over the network using the device IP address:
ssh root@<device-ip>

​
Check the kernel version

# Short version string
uname -r

# Full version, architecture, and build timestamp
uname -a

# Detailed version including compiler
cat /proc/version
The output of uname -r should reflect the kernel version you built and flashed (for example, a 6.18.x string for the LTS track).

​
Inspect boot health

Check the kernel ring buffer for errors or warnings from early boot: 
# Print the first 50 lines of kernel messages
dmesg | head -50

# Filter for errors and warnings only
dmesg --level=err,warn
On systems using systemd, kernel messages from the current boot can also be viewed with: 
journalctl -k -b

​
Confirm kernel modules

Verify that the expected kernel modules loaded successfully: 
# List all loaded modules
lsmod

# Check if Qualcomm-specific modules are present
lsmod | grep qcom
To check if a required module is missing, confirm it was included in the kernel configuration and that the image was rebuilt after the configuration change by running following command on target: 
zcat /proc/config.gz | grep CONFIG_<Module>

​
Troubleshooting

If the kernel version does not match what was built, or if the device fails to boot:
  • Confirm the flash completed without errors by re-running the fastboot flash commands and checking for OKAY responses.
  • Confirm that both efi.bin and dtb.bin were flashed to the correct partitions (efi and dtb_a respectively).
  • For boot failure and kernel panic analysis, see Troubleshoot kernel issues.
  • For serial console log capture, see Kernel logging.