Qualcomm Snapdragon 410/412 (MSM8916)

MSM8916/APQ8016 (or Snapdragon 410) is Qualcomm SoC released in 2014, with great mainline Linux support originally added for the Dragonboard 410c. There is a slightly higher clocked variant (CPU cores up to 1.4 GHz) available as Snapdragon 412.

APQ8016 (Snapdragon 410, WiFi-only)
The WiFi-only variant gt58wifi of samsung-gt58 is APQ8016.

The WiFi-only variant gt510wifi of samsung-gt510 is APQ8016.

Installation
All MSM8916 devices in postmarketOS use lk2nd as secondary bootloader. It does not replace the stock bootloader. Instead, it is flashed in place of an Android boot image, so that the stock bootloader will first load lk2nd instead of a regular Linux kernel. The advantage of this approach is that there is a consistent installation procedure for all MSM8916 devices (once lk2nd was installed), and various device-specific quirks can be handled within lk2nd.

Installing lk2nd


The instructions for installing lk2nd vary from device to device, so please check your device wiki page for instructions. Once you have lk2nd installed and working, you can proceed with the common installation procedure documented below.

Installation from pre-built image
Download a pre-built image as explained in the Installation article.

Unpack the compressed rootfs image and with phone in "lk2nd mode" flash it to userdata partition. Do not forget to erase system partition to prevent accidental booting from it. For example:

$ unxz --keep 20210202-0502-postmarketOS-edge-plasma-mobile-3.2-samsung-a5lte-mainline-modem.img.xz $ fastboot flash userdata 20210202-0502-postmarketOS-edge-plasma-mobile-3.2-samsung-a5lte-mainline-modem.img $ fastboot erase system $ fastboot reboot

Enjoy postmarketOS! (If the image has a pin on it try 0000, 1111, 1234 or 147147)

Installation using pmbootstrap
Follow the pmbootstrap article to build your own fully customized image, with many more UIs to choose from and other options. Below are MSM8916 specific notes.

During  you may get prompted to select a provider for soc-qcom-msm8916-rproc: If you don't want to use the modem on your device (e.g. if your device is a tablet with APQ8016), you may want to pick no-modem.

Large phone UIs like Plasma Mobile or Phosh are too big for the system partition, so either install to the SD card:

Or put your phone into lk2nd mode and flash to the userdata partition. Ignore the hint in the pmbootstrap output that  should be used, this is not necessary. lk2nd will boot the kernel image from the installed rootfs.

Enjoy postmarketOS!

Switching rproc mode
On msm8916 devices it's possible to choose if you want the remote processors (such as wifi and modem) to be enabled or not. You can change the mode by installing one of those packages by running  on your device. (You may need to uninstall other rproc mode package first.) Disabling the remote processors frees up a bit of RAM that they would otherwise use (~80 MB of ram for modem) so you may want to disable the modem if you install the system on an APQ8016 device where the modem core is currently unused.

Display
There's a common issue that the display cant wake up on Xorg.

Here is the kernel log of the issue:

This issue is being work on the github issue on the our msm8916 kernel fork

The cause of this issue
The new function "bridge power on" introdced in v5.18-msm8916 is called at boot but not at wake-up. And the function "bridge mode set", which would call "bridge power on", is also called just at boot but not at wake-up. As some of the stuff of "bridge pre-enable" moved into "bridge power on", they are not called anymore on wake-up in v5.18-msm8916 which caused this issue.

See this reply in that github issue by Jakko: Nice hints, that's a notable step foreward! I want to share my state of research, although it's not finished. Still it might help the discussion (I hope it helps and does not mislead). On samsung-serranove the issue started between `v5.17-msm8916` and `v5.18-msm8916`. I wanted to do a "git bisect", which would need to rebase the mainline (torvalds) `v5.18` commits on top of `v5.17-msm8916`. I failed to do this rebase cleanly, therefore didn't even get to the "git bisect". Instead started to poke around in `v5.18-msm8916`. A candidate causing the issue is commit [7d8e9a9](https://github.com/msm8916-mainline/linux/commit/7d8e9a90509f1bd1d193a0c93cb8d1dbad9049fb) "drm/msm/dsi: move DSI host powerup to modeset time", which is also mentioned in vknecht's hack. Reverting that commit in `v5.18-msm8916` makes my display to wake up as it should. However, reverting that commit is not a sustainable solution. I tried to understand what the commit acctually does. The change is not easy to understand to me. Actually it makes of function `dsi_mgr_bridge_pre_enable` in `v5.17-msm8916`... * https://github.com/msm8916-mainline/linux/blob/v5.17-msm8916/drivers/gpu/drm/msm/dsi/dsi_manager.c#L339 ... two functions `dsi_mgr_bridge_power_on` and `dsi_mgr_bridge_pre_enable` in `v5.18-msm8916`, which are slighty different from the original function in `v5.17-msm8916`. * https://github.com/msm8916-mainline/linux/blob/v5.18-msm8916/drivers/gpu/drm/msm/dsi/dsi_manager.c#L318 * https://github.com/msm8916-mainline/linux/blob/v5.18-msm8916/drivers/gpu/drm/msm/dsi/dsi_manager.c#L374 I don't yet have a good understanding what it means. A bit simplified I would say that the content of "bridge pre-enable" in `v5.17-msm8916` was split into "bridge power on" and "bridge pre-enable" in `v5.18-msm8916`. Now the "bridge pre-enable" alone contains less things than before, because some stuff moved into "bridge power on". Setting some additional debug flags, I could see the order of functions called in `v5.18-msm8916`: * at boot: * bridge mode set * bridge power on  * bridge pre-enable * panel prepare * panel on  * bridge enable * (panel enable) _# if implemented_ * going to sleep: * bridge disable * (panel disable) _# if implemented_ * bridge post-disable * panel unprepare * panel off * waking up: * bridge pre-enable * panel prepare * panel on  * bridge enable * (panel enable) _# if implemented_ So the new function "bridge power on" introdced in `v5.18-msm8916` is called at boot but not at wake-up. And the function "bridge mode set", which would call "bridge power on", is also called just at boot but not at wake-up. As some of the stuff of "bridge pre-enable" moved into "bridge power on", they are not called anymore on wake-up in `v5.18-msm8916`. Notably there is the function `msm_dsi_host_power_on` that moved from `dsi_mgr_bridge_pre_enable` to `dsi_mgr_bridge_power_on` in `v5.18-msm8916`. Interstingly at the end of function `dsi_mgr_bridge_post_disable` there is `msm_dsi_host_power_off`. So at "bridge post-disable" the dsi host gets powered off. But when waking up that host doesn't get powered on because that would happen in "bridge power on" which is not called at wake-up. That's basically where I currently am with the research. I just had a short glimpse into the current kernel (the above was just about `v5.18-msm8916`). In `msm8916/6.4-rc4` I see within "bridge pre-enable" there is now a call of "bridge power on" (that's what we need) but under the condition that `dsi_mgr_power_on_early` isn't valid. * https://github.com/msm8916-mainline/linux/blob/msm8916/6.4-rc4/drivers/gpu/drm/msm/dsi/dsi_manager.c#L415-L416 Using the "blame" button to see where this condition comes from shows that it was introduced by commit [ec7981e](https://github.com/msm8916-mainline/linux/commit/ec7981e6c614254937b37ce0af9eac09901c05c5) "drm/msm/dsi: don't powerup at modeset time for parade-ps8640". The commit diff also shows that the "brige power on" should actually happen in "bridge mode set" function. This closes the circle to vknecht's hack to not power on early. I'm not sure all the text here added something at all ;) Nonetheless I think we're getting closer. As a next step it would need a better understanding why the `dsi_mgr_bridge_power_on` is in function `dsi_mgr_bridge_mode_set`. Looks like this function gets called at boot but not at panel wake-up (so far I just tested on `v5.18-msm8916`).

Battery
Unfortunately, the battery/charging drivers are device-specific and hard to validate without expert knowledge. The level of battery/charging support can be seen in the "Battery" status row on the device page:


 * Broken/Empty: Not supported, can not even check remaining battery capacity.
 * Partial: Can check remaining battery capacity, but not charging status. Charging may or may not work, and may or may not be dangerous on long-time use.
 * Working: Both battery/charging drivers are working. Charging works but is unlikely to be validated for safety.

Pipewire
Seem to be broken

PulseAudio
Audio should work out of the box with PulseAudio. In your favorite PulseAudio mixer (e.g.  on the command line) you can select the output port to use (e.g. Speaker, Earpiece, ...).

Note: If you use  you can switch between output/input configuration with  /, or loop with  /. To select a particular output/input device press  and choose.

ALSA
Everything is muted by default and must be enabled through alsaucm. Unfortunately, the tool is not very user-friendly.

$ alsaucm -i -c hw:0 set _verb HiFi set _enadev

where  is one of ,  ,  ,  ,   or. alsaucm does not track which devices are already enabled, therefore it is possible to produce combinations that won't work properly (e.g. + ). To switch between devices, the old device first needs to be re-enabled and then disabled:

$ alsaucm -i -c hw:0 set _verb HiFi set _enadev OLD set _disdev OLD set _enadev NEW

Modem
If you install via pmbootstrap, pick "all" as rproc provider and make sure to agree to the usage of non-free firmware (required for the modem). Prebuilt images should have the modem working out of the box.

Note that this changes the way audio is routed on the device:
 * Without modem, audio is routed directly to the audio hardware, and works without the need for non-free firmware.
 * With modem running, audio must be routed through the audio DSP, which requires non-free firmware.

Therefore you should choose the kernel depending whether or not you would like to run the modem.

For usage instructions, see Modem.

GNSS (GPS)
On Qualcomm devices GNSS is usually part of the modem. ModemManager and libqmi (with qmicli) can configure and use the modem Location service. Applications like Pure Maps can use ModemManager interface directly, however you may need to enable the gps module:

$ mmcli -m any --location-enable-gps-nmea

Alternatively you can run gpsd to read NMEA output from qmicli. An example of that would be the following (you still need ModemManager to run as it will keep the connection with the modem open):

First command will enable the location service on the modem and give you CID to attach to in the second command.

$ sudo qmicli -pd /dev/modem --loc-start --client-no-release-cid $ sudo qmicli -pd /dev/modem --loc-follow-nmea --client-cid=2 | gpsd -bnN /dev/stdin

There is a WIP merge request to the gpsd that adds the support for GNSS via Qualcomm modems.

GPS operation without a sim-card does not seem to be supported. The following test (assuming ;   untested) shows the problem. It has been confirmed with various community and testing MSM8916:
 * motorola-harpia
 * motorola-osprey
 * samsung-a3

No APQ8016 devices offer GPS capability at present. The samsung-gt58 (/gt58wifi) unified MSM8916/APQ8016 device may be a useful test case.

Test procedure:
 * power-off; remove sim card; power-on.
 * attempt to enable location services:
 * attempt to enable modem:
 * check failure status:

GPU
Snapdragon 410 uses Adreno 306 GPU and it's supported by the Freedreno driver in Mesa. While many applications work as-is, the driver isn't perfect and some applications may crash it. In some cases the GPU crash can lead to full system restart. If you see such behavior, you can try following workarounds:


 * OpenGL ES 3.0 seems to cause system crashes in some cases (e.g. in SuperTuxKart). You may try to override the GLES version with an environment variable. For example:
 * If no other workaround works, you may have to use fully software rendering. Use like:.

You can find a full list of environment variables in the Mesa documentation.

Troubleshooting

 * Screen doesn't work in Linux but works in lk2nd.: Your device may have a display panel that wasn't enabled yet as msm8916 team only enables known working display panels. You can check the config files in linux-panel-drivers repository to see if the panel that is listed on lk2nd screen is enabled there. Contact msm8916 maintainers via Matrix. You can also build the panel driver yourself, consult the MSM8916 Mainlining guide for that.


 * CPU runs at most at 998 MHz but it should be capable of running at 1200 MHz.: While the specifications of MSM8916 have 1200 MHz as max clock speed, currently the max MHz the CPU will operate with pmOS is 998 MHz. There are WIP changes available to make it work (https://github.com/TravMurav/linux/tree/cpr).


 * Device is slow to turn display on after it was left for a while. Calls don't wake it up as well.: Suspend is not yet fully implemented, please see the "Suspend" section below.

Suspend
Suspend is not yet fully implemented. For example, incomming calls do not wake up the phone (see pmaports issue #1157). It's recommended to disable suspend.

Kernel config
To make sure you have suspend disabled in kernel config:

Phosh
In Phosh, it can be disabled in Tweaks -> Power.

Or you can execute this in a terminal:

For SSH sessions:

Plasma Mobile
For Plasma Mobile, disabling suspend in the settings currently doesn't work. Use command  in the terminal to call another settings page that works.

Mainlining

 * MSM8916 is a great platform to get started with mainlining! It has a dedicated MSM8916 Mainlining guide that explains how to get started.