Qualcomm mainline porting

From postmarketOS
Revision as of 09:02, 4 July 2021 by Tooniis (talk | contribs) (Add first steps section and info about schematics)
Jump to navigation Jump to search
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.


  • 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.


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

See also