Before your device arrives

There is a lot you can do without a device. In this post we will examine some of that.

Get the basic hw info

You’ll need to get basic device information from a place like gsmarena.com. (N100 page, N10 page). Also you’ll need basic familiarity with QCom chip naming from this wiki page. From there we can see that the N100 uses SM4250-AA (460) SoC, and N10 uses SM6350 (690) SoC.

Get the kernel code

Device manufacturers are required by GPL to publish the kernel code of the devices they sell. That is really nice, because otherwise this whole mainlining ordeal will be pretty hard, borderline impossible. Most manufacturers host their code on github, for OnePlus it is here. With our newly acquired SoC information, we can deduce the repo for the N100 and N10. Let’s find out which mainline kernel release are these repos based on.

% # get the mainline Torvalds' tree
% git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
% cd linux
% git remote add op-sm4250 https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250
% git fetch op-sm4250
% git remote add op-sm6350 https://github.com/OnePlusOSS/android_kernel_oneplus_sm6350
% git fetch op-sm6350
% # merge-base returns the last common ancestor between the two arguments
% git log -1 $(git merge-base op-sm4250/oneplus/SM4250_Q_10.0 origin/master)
commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d (tag: v4.19)
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Oct 22 07:37:37 2018 +0100
    Linux 4.19

% # alternative way, suggested by Konrad
% head -n3 Makefile
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19

OK, so the code is based on 4.19, released Oct 22 2018. The N100 is released on Oct 26 2020, and it is one of the first devices on this SoC, so you can see how a brand new device has a two year old kernel. Well, it’s not as bad as it sounds, because this kernel has received security patches in the mean time, and will also receive some security patches in the future. But it shows the general picture.

We can also get the Code Aurora Forum (CAF) kernel, which is what QCom releases and the vendors build upon. It is a cleaner version of the downstream kernel, and is sometimes helpful. For 4.19, the caf repo is this one. Then there are a bunch of tags in the dropdown, LA/LE/LU.XX.NN.NN.rNN is something to look for (thanks Konrad Dybcio), in our case I’ll go for LU.UM.1.2.1.r1.3.

Find DT and Kconfig

Device Tree (DT) is a way to specify hardware, that is extensively used in ARM-based projects. You should get familiar with it, watch some YT videos, you may start here. KConfig is the kernel configuration — it controls which parts of the kernel get compiled, and which get dropped, and in some cases controls some aspects of the code. Sometimes there are multiple implementations of the same hardware in downstream kernels so the kconfig will often point to the one being used.

Device Tree files (.dts and .dtsi) live in arch/arm/boot/dts and arch/arm64/boot/dts. The official ones at least; in our case there is a subfolder vendor. Here, I was expecting to find the device codename (OnePlus 8 Pro is instantnoodlep, OnePlus Nord is avicii), but instead I found other codenames in the folder: bengal and scuba for n100 repo, and lagoon, lito, scuba, avicii and billie8 for n10 repo. After some googling I read this (translated from Japanese), this and this, and with more help from Konrad, I also got:

rumi - emulator for pre-silicon development
qrd - qualcomm reference device
idp - internal development platform (likely)

So, to summarize, on the N100, based on QCom SM4250, with internal QCom codename bengal (bengal is also SM6115), the “latest” DT files start with bengal-idp, probably 🙂 The kconfig is likely under arch/arm64/configs/vendor/bengal_defconfig.

Extract official firmware

When you update your device (hopefully there are at least a few updates during its lifetime), a file is downloaded from “official” servers and installed. Thankfully we can understand the format of those files, and peak inside. I used Phoenix Firmware Dumper, and I got official firmware from OnePlus website (Support -> Software Actualization -> Pick Device) link (this will likely not work after some time…).

When you run the dumper you get out a bunch of stuff, I was mainly interested in some dtb (device tree blob) files, but instead I got a folder with stock (from qcom) dtbs and a folder with dtbo (DT overlays). I was left with the impression that overlays were not yet implemented (maybe I should blame YT videos from 2012), but then I updated my knowledge from here, here and here. To summarize — the new trend is to boot the device with a stock (bare bones) DT that gets only the basic (CPU, RAM, storage) hw online, and then initfs decides what is this device actually, and loads (one or more) overlay DTs. This is very flexible and nice, but I wanted to know the final DT my device was using and instead got a bunch of maybes (I don’t know which of all the DTBOs are loaded by the initfs, so I could only speculate).

Thankfully there is an unobtrusive way to get this data, thanks to those two kconfig options that were selected in the supposed kconfig:

config IKCONFIG_PROC
        bool "Enable access to .config through /proc/config.gz"
config OF_KOBJ
        bool "Display devicetree in sysfs"
        def_bool SYSFS

Which let us read the device tree and kconfig from a running kernel. But this post is titled “Before your device arrives”, so we’ll continue the saga after we get the device 🙂

Edits

2021.02.17 (thanks to Konrad for pointing these issues):

• Add note about extracting mainline version via head Makefile, instead of git-fu
• Fix bengal codename — it stands for both 460 and 662 (they are very similar)