Enablement information, known issues and workarounds for Qualcomm based platforms. Feel free to split them under their own subpages to then use the MoinMoin Include macro from various pages.

Laptops/Desktops

This section is specifically for laptop/desktop systems. Public Qualcomm silicon families targeted at this class of platforms:

platform codename

commercial name

Linux device trees (under qcom/)

glymur

Snapdragon X2 Elite/Elite Extreme

glymur-*

kalambo

Snapdragon X2 Plus/Elite

n/a

mahua

Snapdragon X2 Plus/Elite

mahua-*

purwa

Snapdragon X1 Plus (SC8380XP)

x1p-*

hamoa

Snapdragon X1 Elite/Plus (SC8380XP)

x1e-*

makena

Snapdragon 8cx Gen 3 (SC8280X)

sc8280xp-*

The WoA project maintains similar information.

Incomplete ACPI implementation device tree

Many of these systems are Windows on Arm (WoA) designs, sometimes also referred to as Windows on Snapdragon (WoS), and were primarily designed for Windows. The ACPI implementation is not completely compatible with Linux, either because of partial coverage, differing expectations between Windows and Linux, or due to OEM ACPI overlays delivered on the Windows filesystem. The firmware also doesn't provide a device tree binary (DTB) to the operating system. The Linux kernel package in Debian builds and installs a number of device trees for these platforms, and there are various ways to use them.

Manually instructing the bootloader to load a particular device tree

systemd-boot has a /etc/kernel/devicetree configuration file to force copying a specific device tree. This works fine on Debian, both for regular systemd-boot entries as for Universal Kernel Images (UKIs), but it can't be done from the systemd-boot interactive menu, and it makes the corresponding boot entries device-specific.

Ubuntu and Fedora carry GRUB patches to define a new command to load a device tree from the GRUB configuration and to copy device trees. TODO: research implementation status upstream and in Debian.

Using Stubble's stub and/or data

The Stubble project provides: - a database of firmware signatures, Microsoft's Computer Hardware Identifiers (CHID) - a map from known CHIDs to recommended Linux kernel device trees - a boot stub (based on systemd-boot's stub) that can be used with the above at boot time to load the right device tree for the current machine

Stubble can be built as a standalone EFI binary, or its stub and data can be tacked in front of an EFI binary, such as Linux kernel.

Stubble is packaged in Debian and is released quite frequently, regularly gaining support for new platforms.

Stubble PR #89 provides hooks to use systemd-stub and stubble or systemd-boot data as a DTB loader: - a kernel-postinst.d hook for systems booting with GRUB - a kernel-install install.d hook for systems booting with systemd-boot

See also Debian bug #1134185 for a kernel-install install.d hook to integrate the systemd-boot stub and stubble data in UKIs (full-blown UKIs).

Using systemd-boot's stub and/or data

Just like Stubble, recent systemd-boot versions offer similar data as Stubble, and the systemd-boot stub can be used to load the right device tree for the current machine.

TODO: It's not clear how upstream systemd intends to integrate CHID machine ids in Ukify for UKIs, and support for using these without UKIs should also be contributed upstream rather than only to Stubble.

USB Type-C Port Manager on ADSP

On makena, hamoa, and purwa based platforms, the USB Type-C Port Manager (USB TCPM) is implemented on the Audio Digital Signal Processor (ADSP). The ADSP is initialized a first time by the boot firmware to provide boot functionality, and is later reset by the Linux kernel on startup when loading firmware. This causes devices attached to the Type-C ports to be disconnected. This is why it's important to provide the ADSP firmware to the initramfs, especially in scenarios where the system is booting from an USB Type-C attached storage; a good example of that is booting an installer.

Patches were contributed to a couple of initramfs generators to teach them to include the relevant drivers and the firmware files they need:

CategoryQualcomm