Skip to main content
Targeted diagnosis steps and fixes for the most common failures encountered when working with the Qualcomm® Linux kernel.

​
Boot failures

​
Kernel does not boot with a black screen or no serial output

Check first:
  1. Confirm the serial console is configured (console=ttyMSM0,115200n8 in the kernel command line).
  2. Verify efi.bin was flashed successfully by re-running fastboot flash efi efi.bin and check for OKAY responses.
  3. Erase RPMB area in case its persistent state carrying EFI variables is corrupted or misaligned:
fastboot oem rpmb_erase
  1. Add earlycon to the kernel command line to get output before the UART driver initialises.
# Minimum working kernel command line for serial output
console=ttyMSM0,115200n8 earlycon
See Kernel logging for serial console setup.

​
Kernel panic at boot

A kernel panic during boot produces a call stack on the serial console. Capture it and identify the faulting function: 
# After collecting the panic log
dmesg | grep -A 30 "Kernel panic"
Common causes on Qualcomm Linux:
Panic messageLikely cause
Unable to handle kernel NULL pointer dereferenceDriver accesses a resource before it is initialised (probe order issue)
SError Interrupt on CPUTo debug unclocked or protected register access, enable MMIO traces (see Kernel probes and tracing)
Kernel panic - not syncing: VFS: Unable to mount root fsRoot partition label mismatch or missing file system driver
KASAN: use-after-freeTo check memory safety bug, enable CONFIG_KASAN=y in a debug build to get more detail

​
Device tree issues

​
DTB authentication failure

UEFI firmware authenticates the DTB before passing it to the kernel. An authentication failure prevents the kernel from receiving any device tree. Log signature: 
Platform Subtype : 0
DtPlatformLoadDtb qcs6490-rb3gen2.dtb is loaded
Platform Subtype : -2090817768
DtPlatformLoadSign qcs6490-rb3gen2.sgn is loaded
failed to authenticate image !
Fix: Flash the correctly signed dtb.bin that matches the current signing key provisioned on the device. Ensure efi.bin and dtb.bin are from the same build.

​
DTB not found

DtPlatformLoadDtb qcs6490-rb3gen2.dtb is loading failed with Status = E
DtPlatformDxeEntryPoint: no DTB blob could be loaded, defaulting to ACPI
Fix:
  1. Verify the DTB is included in the packaged dtb.bin: if using legacy concatenated dtb packaging: 
    # On the host
mount -o loop -t vfat dtb.bin /mnt/
fdtdump /mnt/combined-dtb.bin | grep -i model
    if using FIT-based packaging: 
    # On the host
mount -o loop -t vfat dtb.bin /mnt/
fdtdump /mnt/qclinux_fit.img | grep -i compatible
  2. Check that the board DTS file is listed in KERNEL_DEVICETREE in the Yocto machine configuration.
  3. Reflash dtb.bin: 
    fastboot flash dtb_a dtb.bin

​
Verify which DTB was loaded at runtime

After a successful boot, confirm the correct device tree was loaded: 
dmesg | grep -i "machine model\|compatible\|of_flat_dt"
# or
cat /proc/device-tree/model

​
DTB identification during boot

Refer common dtb issues for more information on device tree identification.

​
Module load failures

​
Invalid module format showing vermagic mismatch

insmod: ERROR: could not insert module my_driver.ko: Invalid module format
Cause: The module was built against a different kernel version, configuration, or compiler than the running kernel. The vermagic string embedded in the .ko file does not match. Diagnose: 
# Check the module's vermagic
modinfo my_driver.ko | grep vermagic

# Check the running kernel's vermagic
modinfo /lib/modules/$(uname -r)/kernel/drivers/net/dummy.ko | grep vermagic
# or
uname -r
Fix: Rebuild the module against the exact kernel source tree (same KERNEL_SRC, same defconfig and fragments) that produced the running kernel image. If using Yocto, rebuild with bitbake qcom-multimedia-image to keep the module and kernel in sync.

​
missing .ko file

insmod: ERROR: could not insert module my_driver.ko: No such file or directory
Diagnose: 
find /lib/modules/$(uname -r) -name "my_driver.ko"
Fix: Ensure the module is built (obj-m += my_driver.o in the Makefile) and installed (make modules_install or via Yocto module class).

​
Module not found and missing from modules.dep

modprobe: FATAL: Module my_driver not found in directory /lib/modules/<version>
Fix: Run depmod to rebuild the module dependency map after installing new modules: 
depmod -a
modprobe my_driver

​
Module loads but does not work

Check dmesg immediately after insmod for probe errors: 
dmesg | tail -30
Common patterns:
Log patternCause
probe of ... failed with error -19-ENODEV, hardware not present or DT node has status = "disabled"
probe of ... failed with error -22-EINVAL, missing or malformed device tree property
probe of ... deferred-EPROBE_DEFER, a dependency (clock, regulator, GPIO) is not yet ready
For deferred probe, check which devices are still pending: 
cat /sys/kernel/debug/devices_deferred

​
Serial console not working

If there is no output on the serial console after flashing a new kernel:
  1. Verify Kconfig: 
    zcat /proc/config.gz | grep QCOM_GENI
# Required: CONFIG_SERIAL_QCOM_GENI=y, CONFIG_SERIAL_QCOM_GENI_CONSOLE=y
  2. Verify kernel command line: 
    cat /proc/cmdline
# Must contain: console=ttyMSM0,115200n8
  3. Get early boot messages: Add earlycon to the kernel command line. This enables output before the UART driver is fully initialised.
  4. Check the cable and baud rate: Confirm 115200 baud, 8N1, no hardware flow control on both the device and the host terminal.

​
Remoteproc failures

​
Firmware load failure

remoteproc remoteproc0: Direct firmware load for qcom/qcs6490/adsp.mdt failed with error -2
Fix: Ensure all required firmware files are present in /lib/firmware/qcom/<SoC>/: 
ls /lib/firmware/qcom/qcs6490/
# Required: adsp.mdt, adsp.b00, adsp.b01, ..., cdsp.mdt, wpss.mdt

​
Capture logs on subsystem crash

To prevent the remoteproc driver from automatically recovering a crashed subsystem (which clears the crash logs), disable recovery before reproducing the crash: 
echo disabled > /sys/kernel/debug/remoteproc/remoteprocN/recovery
Sample crash log: 
qcom_q6v5_pas 3000000.remoteproc: fatal error received
remoteproc remoteproc2: crash detected in 3000000.remoteproc: type fatal error
remoteproc remoteproc2: handling crash #1 in 3000000.remoteproc
Enable coredump to capture a memory snapshot for offline analysis: 
echo enabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump
# After the crash:
cp /sys/class/devcoredump/devcdN/data /var/spool/crash/dump_file.elf
Transfer the .elf file to a host and analyse with the Qualcomm Crash Analysis Portal (QCAP). For more detail see Configure the remoteprocessor subsystems.