Qualcomm mainline porting

From postmarketOS
Note Work in progress and untested. Please improve this page (or merge it together with the non-Qualcomm-specific mainlining wiki page) when you try any of this.

Devices with Qualcomm SoCs are generally good candidates for porting mainline Linux, considering the great support those SoCs have. It usually doesn't take a lot of work to get a device running mainline with a decent amount of working features, provided the SoC is already supported.

Supported SoCs

SoC Arch Year UART USB Storage Display CPU GPU Pinctrl I²C Audio Video Thermal WiFi BT Modem GPS Camera Suspend
Qualcomm APQ8064 armv7 2013 Y Y Y Y Y N Y Y N Y Y N
Qualcomm MSM8212 armv7 2013 Y Y Y P Y Y
Qualcomm MSM8226 armv7 2013 Y Y Y Y P Y Y Y N N Y Y Y N Y P N
Qualcomm MSM8909 armv7 2015 Y Y Y P Y Y Y N P N N N
Qualcomm MSM8916 aarch64 2014 Y Y Y Y P Y Y Y Y Y Y Y Y Y Y P
Qualcomm MSM8917 aarch64 2016
Qualcomm MSM8929 aarch64 2014 Y Y Y P P Y Y Y Y Y Y Y Y Y Y P
Qualcomm MSM8937 aarch64 2016 Y Y Y P Y Y
Qualcomm MSM8939 aarch64 2014 Y Y Y Y P Y Y Y Y Y Y Y Y
Qualcomm MSM8940 aarch64 2016 Y Y Y P Y Y
Qualcomm MSM8953 aarch64 2016 Y Y Y Y Y Y Y Y Y Y Y Y Y P P P P
Qualcomm MSM8960 armv7 2012 Y P P Y Y P
Qualcomm MSM8974 armv7 2013 Y Y Y Y P P Y Y N N Y Y Y P N N N
Qualcomm MSM8976 aarch64 2016 Y P Y Y N Y Y Y N N Y Y Y P N N
Qualcomm MSM8992/MSM8994 aarch64 2015 Y Y P P Y N Y B B
Qualcomm MSM8996 aarch64 2016 Y Y P Y P Y Y Y Y Y Y - - P P N
Qualcomm MSM8998 aarch64 2017 Y Y Y P P N Y Y Y Y Y Y P Y
Qualcomm QM215 aarch64 2019
Qualcomm SC8280XP aarch64 2021 Y Y Y Y Y Y Y Y P P Y P P Y P P
Qualcomm SDM630 aarch64 2017 Y P Y Y P P Y Y N Y Y Y Y Y P
Qualcomm SDM636 aarch64 2017 Y P Y Y P P Y Y N Y Y Y Y Y P
Qualcomm SDM660 aarch64 2017 Y P Y Y P P Y Y N Y Y Y Y Y P
Qualcomm SDM670 aarch64 2018 N P P Y P Y P Y P P Y Y Y N
Qualcomm SDM845 aarch64 2018 Y Y Y Y Y Y Y Y Y Y Y Y Y P Y Y Y
Qualcomm SM6115 aarch64 2020
Qualcomm SM6125 aarch64 2019 Y Y Y P N Y N N N P N N N N
Qualcomm SM6225 aarch64 2021 N N P P N N N N N N N N N N
Qualcomm SM6350 aarch64 2020 Y Y Y Y Y Y Y Y N N N Y N P N
Qualcomm SM7125 aarch64 2020 Y Y Y Y Y Y Y Y Y Y P
Qualcomm SM7150 aarch64 2019/2020 Y Y Y Y Y Y Y Y P N Y Y Y Y P P Y
Qualcomm SM7325 aarch64 2021/2022 Y Y Y Y Y Y Y Y N Y Y Y Y N N N
Qualcomm SM8150 aarch64 2019 Y Y Y Y Y Y Y Y P Y Y Y
Qualcomm SM8250 aarch64 2020/2021 Y Y Y P Y Y Y Y Y Y Y Y
Qualcomm SM8350 aarch64 2021 P Y P Y
Qualcomm SM8450 aarch64 2021 Y Y Y Y Y Y Y Y
Qualcomm SM8475 aarch64 2022 Y Y Y Y Y Y Y
Qualcomm SM8550 aarch64 2022 Y Y Y Y Y Y Y Y Y
Qualcomm SM8650 aarch64 2023
Qualcomm X1E80100 aarch64 2023

Prerequisites

  • Downstream kernel source code: This is the main source of reference when porting the mainline kernel.
  • Board schematics: An additional source of reference that can be really helpful considering the usually poor quality of downstream code including the device trees. Will allow you to confirm the wiring of all components, and will also show any hardware that is misrepresented in the downstream device tree, such as fixed regulators which are often modeled as enable pins.
  • Having the mainline source code of a similar device can be very helpful: https://wiki.postmarketos.org/wiki/Mainlining#Supported_SoCs

First steps

You must find a method for getting feedback from the device when booting the mainline kernel. This will be necessary for debugging.

UART

Perhaps the most useful method, since it allows for getting early kernel messages, and even bootloader logs which can help when the device is not finding or refusing your DTB. You will have to find the location of the UART port on your device, see (video tutorial | Identifying serial ports) and Serial debugging

Simple Framebuffer

This should be the easiest method to get working, provided you have a video-mode panel and your bootloader leaves a framebuffer configured for continuous splash. It will allow Linux to print its logs to the screen, and it will also allow you to actually make use of the screen before writing a panel driver, although to a limited extent.

RAM Console / ramoops

This method is more of a last resort, considering it is usually unreliable and in many instances quite difficult to get working.

Relevant chat log

Thanks to opendata and bshah for the following log. Let's make this more wiki friendly once we try it out.

  • Copy fairphone2 DTs and change device info
    • (alas, if you are using Nexus 4, apq8064 based device would be good start i.e Nexus 7 2013 (yes, it's most complete device now))
      • Not sure about 8064, I would do the same thing but base off yuga
  • Look for a file named msm8974-regulator.dtsi in devices android kernel tree
  • Look for pm8841_s1: regulator-s1 then look at the voltages and make sure your DTS is the same, if not change it.
  • Do the same operation for the other regulators:
    • pm8841_s2: regulator-s2
    • pm8841_s3: regulator-s3
    • pm8841_s4: regulator-s4
    • pm8941_s1: regulator-s1
    • pm8941_s2: regulator-s2
    • pm8941_s3: regulator-s3
    • ...
    • pm8941_l1: regulator-l1
    • ...
    • pm8941_l24: regulator-l24
  • Then look in your devices android DTSi and look for any regulator configs if you find any change the corresponding regulator in the dts
  • This should be enough to boot with USB telnet

SoC-specific guides

There are detailed guides for some SoCs:

The mainlining procedures are quite similar, so you should be able to follow them to some extent even if you have a different SoC.

See also