Difference between revisions of "Qualcomm mainline porting"

From postmarketOS
Jump to navigation Jump to search
(Add SoC-specific guides)
 
(15 intermediate revisions by 7 users not shown)
Line 1: Line 1:
==WIP==
+
{{note|Work in progress and untested. Please improve this page (or merge it together with the non-Qualcomm-specific [[The Mainline Kernel|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 ===
 +
{{#cargo_query:
 +
tables=Socs
 +
|fields=CONCAT( '[[', _pageName, '|',Manufacturer,' ',Name,']]' )=SoC,Arch,Year,StatusUart=UART,StatusUsb=USB,StatusStorage=Storage,StatusDisplay=Display,StatusCpu=CPU,StatusGpu=GPU,StatusPinctrl=Pinctrl,StatusI2c=I²C,StatusAudio=Audio,StatusVideo=Video,StatusThermal=Thermal,StatusWiFi=WiFi,StatusBluetooth=BT,StatusModem=Modem,StatusGps=GPS,StatusCamera=Camera,StatusSuspend=Suspend
 +
|order by=Socs.Manufacturer, Socs.Name
 +
|where=Mainline="1" and Socs.Manufacturer="Qualcomm"
 +
|format=table
 +
|limit=9999
 +
|more results text=
 +
}}
  
 
== Prerequisites ==
 
== Prerequisites ==
* A working device-tree based downstream kernel
+
* Downstream kernel source code: This is the main source of reference when porting the mainline kernel.
* You know the location of the uart port on your device ([https://www.youtube.com/watch?v=_aedd8SUBgY this video] shows how to find it)
+
* 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.
* A device that has one of the following snapdragon processors
+
* Having the mainline source code of a similar device can be very helpful: https://wiki.postmarketos.org/wiki/Mainlining#Supported_SoCs
** S3
+
 
** S4 Pro
+
== First steps ==
** 800
+
You must find a method for getting feedback from the device when booting the mainline kernel. This will be necessary for debugging.
** 801
+
=== UART ===
** 805
+
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.
** 410
+
You will have to find the location of the UART port on your device, see ([https://www.youtube.com/watch?v=_aedd8SUBgY video tutorial] | [http://www.devttys0.com/2012/11/reverse-engineering-serial-ports/ Identifying serial ports]) and [[Serial debugging]]
** 808
+
=== Simple Framebuffer ===
** 810
+
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.
** 820
+
=== 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 <code>msm8974-regulator.dtsi</code> in devices android kernel tree
 +
* Look for <code>pm8841_s1: regulator-s1</code> 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:
 +
**<code>pm8841_s2: regulator-s2</code>
 +
**<code>pm8841_s3: regulator-s3</code>
 +
**<code>pm8841_s4: regulator-s4</code>
 +
**<code>pm8941_s1: regulator-s1</code>
 +
**<code>pm8941_s2: regulator-s2</code>
 +
**<code>pm8941_s3: regulator-s3</code>
 +
**<code>...</code>
 +
**<code>pm8941_l1: regulator-l1</code>
 +
**<code>...</code>
 +
**<code>pm8941_l24: regulator-l24</code>
 +
* 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:
 +
* [[MSM8916 Mainlining]]
 +
* [[MSM8996 Mainlining]]
 +
* [[SDM845 Mainlining]]
 +
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 ==
 +
* {{issue|153|pmaports}} crosshatch: mainlining attempt: progress and questions
 +
* [https://elinux.org/Qualcomm_SOC_Mainlining_Project Qualcomm SOC Mainlining Project]
 +
[[Category:Guide]]

Latest revision as of 17:12, 10 August 2021

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 N Y P Y Y
Qualcomm MSM8916 aarch64 2014 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y P
Qualcomm MSM8939 aarch64 2014 Y Y Y P Y Y Y Y Y Y
Qualcomm MSM8953 aarch64 2016 Y Y Y Y Y Y Y Y Y Y Y Y Y P P P
Qualcomm MSM8960 armv7 2013 Y
Qualcomm MSM8974 armv7 2013 Y Y Y Y P P Y Y Y Y Y P
Qualcomm MSM8976 aarch64 2016 Y P Y Y N Y Y Y N N Y Y Y P N N
Qualcomm MSM8996 aarch64 2016 Y Y P Y P Y Y Y Y Y Y - - P N
Qualcomm MSM8998 aarch64 2017 Y Y P P N Y Y Y Y Y P Y
Qualcomm SDM630 aarch64 2017 Y P Y P P Y Y P P
Qualcomm SDM636 aarch64 2017 Y P Y P Y Y
Qualcomm SDM660 aarch64 2017 Y P P P Y
Qualcomm SDM845 aarch64 2018 Y Y Y Y Y Y Y Y Y Y Y Y P N
Qualcomm SM8150 aarch64 2019 Y Y Y P Y Y Y
Qualcomm SM8350 aarch64 2021 P Y P

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