Hello everyone and welcome. I hope you've enjoyed FOSM so far. In fact, I hope I have too.

This is actually my first time attending, so I'm really excited to be here. Thank you for having me. This is from Android to mainline on the Snapdragon 845 or how I learned to love Android phones. So a little context, my name is Caleb. I'm a post-market OS developer and

kernel hacker. I'm a university student in the UK and for as long as I can remember I've really wanted to see the Linux boot splash on my phone. So I maintain a close to mainline kernel fork for Snapdragon 845 devices.

This kernel is used by PostMarkLOS and Mobian as well as some other distros to enable mainline Linux distro support for phones like the OnePlus 6 and Pocophone F1. I am also currently an intern at Linero where I work somewhat ironically on Android for mainline devices. We'll get to that in a little bit. So to properly understand what it means to run Linux on a phone,

we first need to deal with the complicated fact that technically speaking Android phones already run Linux. Chances are if you visited enough forums, you'll have already read a snarky reply along the same lines. But if that were already true, how come it's almost entirely unheard of to have standard Linux distributions on our mobile devices?

Well, it's for one big reason, which is that the Linux kernel that Android devices run is not mainline. Your PC or laptop may have at most a few patches applied by your distribution or kernel flavor, but for Android it's an entirely different story. How different? Well, you can see for yourself, open up a new tab, head over to not.mainline.space

and you can see the kernel that Qualcomm shipped on Snapdragon 845 devices has about five and a half million lines of code which aren't in upstream Linux. Most of this is drivers for hardware. Some of it is also Android patches and in my opinion

it's more than enough to suggest that this isn't really a Linux kernel anymore. These kernels also depend on proprietary user space blobs in the form of Android house to enable all of the hardware components like graphics, cameras, sensors and of course the modem are all completely non-functional without this. Google have been doing a lot of work over the past several years to improve the

situation as they want to be able to provide kernel upgrades on smartphones almost as much as we do. As a result, many of the Android specific patches which were required on these old kernels have now landed in one form or another in upstream Linux. This means it's now very possible to run Android on top of Linus Torvalds master branch, assuming your device is supported that is.

A bit about Linero and Qualcomm. Linero have been supporting mainline Linux on Qualcomm devices for over a decade. They have a dedicated team who work with Qualcomm to enable new SoCs. As a result, we've seen some level of support for almost every flagship SoC from the last decade from the Snapdragon S4 series all the way through to the 400 and 800 series up until today

where we recently started day one patch series providing basic support for the new Snapdragon 8 Gen1 and bringing up Qualcomm's internal reference device. This kind of initial bring up by developers who are familiar with Qualcomm hardware and upstream development practices is absolutely fundamental to having any functional devices. However, it's only really the first step

towards being able to ship mainline kernels on devices. For that we need support for a myriad of other hardware found in SoCs. Stable graphics support, wi-fi, audio, to name a few. In fact, let's make a quick list of all the other hardware blocks that you can find in an average Qualcomm SoC. To start with, there are lots of clock controllers which are basically hardware blocks

responsible for setting up and managing clocks which other hardware blocks depend on like the multiple clocks used to send data to the display. Then there are several other hardware blocks which are responsible for managing kind of generic things which you'd expect to find on most SoCs.

Qualcomm platforms all feature Qualcomm PMICs or power management chips which are responsible for a lot of the hardware and peripherals too. For example, the PMIC on the Snapdragon 845 is responsible for generating a lot of power rails which are used by various components on the SoC.

One of those is the LCD backlight power rail called WLED which is required for all LCD display panel devices. The PMIC also features other things like ADCs to measure the charging voltage and current as well as the actual charger and battery fuel gauging hardware.

One of the PMICs also features a hardware block which is responsible for driving the haptics found in devices like the OnePlus 6. In addition, Qualcomm platforms feature remote processors. These include the modem and multiple other DSPs which are used for compute and audio processing

as well as the sensor core or sensor low power island or SLPI. All of these remote processors run their own firmware and communicate to the host over shared memory using several layers of custom protocols designed by Qualcomm, namely QRTR and QMI. Qualcomm SoCs also feature the IPA

hardware block which is a custom packet router designed in hardware which is responsible for setting up and managing mobile data connections as well as doing all sorts of complicated network packet filtering and processing. There is of course a video encoder decoder in

Qualcomm platforms. This is called Venus and it requires a driver in the kernel as well as required proprietary user space components to work. Thanks to the work done by Rob Clark

and Fried Reiner we've been able to run Qualcomm GPUs with completely open source kernel and user space components for quite a few years now. One of the more interesting features of Qualcomm SoCs is the LMH or limits management hardware. This hardware block is responsible for

managing the thermal and power properties of the SoC including the CPU cores and other hardware blocks. Previously we were not really aware that this hardware even existed and so on all devices it was using the firmware programmed default values which were extremely conservative.

Tara Gopinath, I hope I'm pronouncing that correctly, created a upstream driver for the LMH and using that driver to program new default values we are able to gain anywhere between 20 and 70 percent performance uplift depending on the task. This was huge in terms of

benchmarking mainline versus downstream Linux performance comparisons. One of the larger components of a Qualcomm SoC is the Atheros Wi-Fi. On the Snapdragon 845 and some other platforms this connects over QMI and the modem is primarily responsible for booting the Wi-Fi hardware and loading the FELMA from user space. Enabling support for this hardware is a huge

effort and it would not be possible at the current rate without direct support from Qualcomm either in the form of patches they send upstream or by allowing developers at companies like Lenero access to documentation for the hardware. The Android team at Lenero are largely

responsible for ensuring that the Snapdragon 845 support in the kernel doesn't break. They collaborate with Google and upstream to fix bugs and cache regressions in AOSP and in mainline Linux. Recent examples of this include a regression in the DWC3 USB driver which caused the Pocophone F1 to crash immediately during boot.

There's also been a lot of work done to help debug and fix graphics and display issues on SDM 845 devices during the transition to enabling FELMA devlink. By my estimation this has taken three to four kernel releases to properly iron out but it has led to a much more reliable probe ordering of kernel drivers. Let's talk a bit about Post Market OS. What is it? Why is

it? Maybe even where is it? Post Market OS is an Alpine based Linux distribution for phones. It's designed to be lightweight, fast and to run on 10 year old devices. In fact every single year it gets better and better running on 10 year old phones. I wonder why. Jokes aside though, since its humble beginnings in 2017 Post Market OS has

become not only one of the most stable and well-designed mobile oriented distros, it has also created one of the most helpful and welcoming open source communities I've come across. From the get-go Post Market OS has had some straightforward and well-specified goals.

You can read about them in more detail on the About Post Market OS wiki page. For developers those are to be easy to modify, sustainable and to be built and maintained exclusively using free software. As much as possible software and fixes are upstreamed into Alpine or into the kernel. The use of hacks to enable features is heavily discouraged and always requires

extensive debates before implementing them. It's heavily privacy focused, in fact originally it wasn't even possible to install it without using full disk encryption. This was great, except there was no software to enter your unlock key, so you had to plug your phone in and use USB networking and telnet to type in your decryption key.

Post Market OS is largely driven by the PMBoostRep tool. PMBoostRep is a CLI application written in Python which makes development and testing extremely simple. It handles cross-compiling packages, creating change routes and generating the root file system used on devices. It's used both by developers and by the automated tooling in the Post Market OS

build system to generate release images which you'll find on the download page. Like almost all Post Market OS tooling it has extensive automated testing. The distro is designed such that supporting a new device requires creating at most three packages. One provides device specific

support via the device info abstraction as well as any other device specific changes like a custom scale factor. Device info is a config file which specifies all the device specific features and tells PMBootstrap how to create images for the device. The second package is the kernel which can either be device specific or in the case of the Snapdragon 845 be a single

kernel which is shared between all SCMA45 devices. Finally the firmware is packaged in the same way as upstream Linux firmware. Back in 2020 Bart aka PureTryout said about Post Market OS you can boot the system but you probably won't be able to use it as a phone. It's now two

years later and I think we can challenge that. There are now over 350 devices which have Post Market OS booting in one form or another. The latest stable release supported 23 devices which are in the community or main categories. That's 23 devices which run mainline Linux and support all or almost all of the features that you'd expect from a phone. Before we can get to

boosting Linux we first need to understand a bit about the boot process on Qualcomm devices. Android phones like computers contain a bootloader which is responsible for initializing the hardware, loading and eventually executing some operating system. On Qualcomm devices with a

Snapdragon 800 or newer this bootloader is called the XBL or Extensible Bootloader. It is based on EDK2 with modifications by Qualcomm to support the hardware. Whilst EDK2 is open source Qualcomm's fork is unfortunately not. For Android devices the bootloader contains

a second part the ABL or Android Bootloader. The ABL is simply a UAFI, yep you heard that right, a UAFI application which contains code for loading the Android boot image and DTBO, performing Android verified boot steps and implementing stuff like fastboot.

Qualcomm provide a reference ABL which is open source however most device manufacturers don't provide the source code for the ABL they ship. Device vendors often implement a lot of hacks in their ABL whether it be due to time crunch or just poor quality code. This can make booting mainline a really frustrating experience especially if you're unable to obtain logs from

the bootloader. For example on the Pixel 2 we have to craft a custom DTBO partition with a single empty DTBO with the correct ID. This functionality is completely undocumented and took dozens of hours of work to reverse engineer, made even more difficult when UART is not available and the only feedback is how quickly the phone reboots. Google do now

provide a reference schematic for their custom USB dongle which exposes UART via the USB port. Pixel phones don't support the SUSEQ debug standard. The Pixel 3 is a similar story but simpler in that it only requires a blank DTBO which contains the matching board ID.

The OnePlus 9 was a huge mystery. It took several developers over a month to figure out how to make it boot. The DTB included with the kernel has to give the ARM timer node a very specific label. If the bootloader can't find the labeled timer then it will crash due to a bug. Thankfully it's possible to dump the contents of RAM after a crash using reverse engineered tools for interacting with the device in crash dump or EDL emergency

download mode. There is at least one exception to the no ABL source code rule which most vendors seem to follow. That is Shift who ship their Shift 6 MQ with secure boot off and release their ABL source code. This means that experienced developers can compile and flash

their own custom bootloaders and it will allow us to create features like a rich multi-boot support for end users where on other devices we have to make do with hacks which work around the bootloader provided by the vendor. However this does require trading off end user security as without secure boot it's trivial for an attacker to dump the contents of the internal

storage and rootkit the device to obtain encryption keys. To the best of my knowledge Qualcomm don't provide any method for user-owned secure boot where the end user would be responsible for managing their own secure boot keys. This is a huge shame and something that I think we should encourage more SOC manufacturers to support. Even so it's great to see more vendors supporting

open source alternative OS communities and I'm incredibly excited to see where this can go in the future. So how do we go about mainlining a Snapdragon 845 device? Well the first step is to prepare a device tree. For those who don't know what device tree is it's basically a language for

describing hardware. What it is, where it is, and what it's connected to. The example here is slightly simplified. It shows a Synaptics touch screen which is connected to some I2C interface at address 20. The compatible property is used to match the device to a driver which can control it. It has a single interrupt which is IRQ25 on some interrupt controller the TLMM. There are many

better talks on device tree if you're interested in knowing more about it then I'd highly recommend that you track one down. Back when I first ported the OnePlus 6 there was not very much knowledge in the community around how to actually boot mainline on these devices. There is a partition called the DTBO which stands for Device Tree Blob Overlay and Android kernels store

most of the device tree contents here. We didn't quite understand how they worked and I spent a long time getting stuck with absolutely nothing happening when I tried to boot mainline

and it turns out that the bootloader takes the device tree blobs from the DTBO partition and tries to overlay them on top of the DTB that you provide with your kernel. With the mainline device tree it's completely different to the one that Android uses so the bootloader was failing and it was just simply not even trying to boot the kernel. We realized that you can simply erase

the DTBO partition and it booted. When I first got the device to boot it was amazing getting to see the Linux kernel logs appear on the screen however after about two seconds the screen ran black and it rebooted again. I got stuck on this issue for about a week until

eventually I found some patches from Bjorn Anderson which fixed a bug where when the memory management units are initialized it would touch memory which the hypervisor thought was protected and so it would fault and reboot the device. Once we got the device

booting into a rootfs with some basic frame buffer graphics I started work on the touchscreen. I did this by looking at the Android kernel sources looking into the device tree and seeing where to find the touchscreen to know what I2C bus it was connected to and how it was powered

etc. I spent a long time with absolutely no luck until eventually I realized that there was some random GPIO which was defined and referenced and the driver would toggle it high.

This was actually the final clue to making it work and is also why I'm really glad that we have very strong standards for device tree and mainline because with most vendor provided kernels it's an absolute mess and often requires looking deep into drivers to actually understand how a given

property works. For any device we need to take some development board as reference, strip out almost everything except what's needed to boot and then we can add a reference to the frame buffer which the bootloader sets up in memory so we can output some picture on the display. For most Snapdragon 845 devices this is enough to get the kernel booting. Almost all devices

are based on some reference board design from Qualcomm for example the MTP or QRD boards so it's usually fairly safe to copy the MTP board, verify that the regulators all match up and then take it from there. In the two years that I've been working on mainline Linux for

SDM 845 devices the process has definitely gotten a lot easier. We understand a lot more about the hardware and the bootloaders and so bringing up new devices is getting faster and faster every single time. For example we recently bought up Linux on the Shift 6 MQ and we went from

having nothing to having the device booting with full graphic support, display support and touchscreen working in about three days. So why should you mainline your Qualcomm device? Well most SoCs already have basic support it's usually fairly straightforward to adapt features from others if they don't and once you get over the initial humps of learning how the bootloader

works and getting the kernel to actually boot and spit some stuff out it's much more steady progress from there. Almost all of them have at least UART and other basic features implemented and many of them have GPU support too. SDMA45 and newer SoCs are being actively developed upstream

but are largely missing platform support. By working on enabling new devices you help encourage upstream to maintain these SoCs and devices and you also make it easier for more people to get involved in development. Mainlining is a really great hands-on learning experience from learning to build and flash your own kernel to spending days trying to figure out why the

touchscreen isn't working if you're into that sort of thing. Before working on mainline for the OnePlus 6 I had zero prior experience with upstream Linux or Linux development at all really. But by working on the device I was able to learn so much about kernel development, device tree and Android. If you like me struggle with following tutorials and doing quizzes this

is a really great practical way to learn embedded kernel dev. It's just so rewarding to spend weeks writing a driver to enable a feature like haptics and finally get it working. It's also really good for the environment. Bringing mainline support to a device extends

its lifespan almost indefinitely as it's no longer dependent on support from a vendor who would probably much rather you just buy a new device. It lets us support many devices with a single kernel which will remain up to date for as long as there are people to test and catch regressions. Alright I think it's time for a demo. I apologize for the horrible

lighting but it's about the best I can do to have the phones be like somewhat readable. On the left is the shift 6mq and on the right is a OnePlus 6. Both devices are running Linux 5.16 and we get to see them boot. The reason that most Android devices don't support

Rainbuffer console as I mentioned earlier most kernels break config vt and core coms downstream graphics drivers don't implement support for fbconsole. But on mainline we get

to see it in all its glory. As you can see they boot pretty quickly. Both of these are running post market os flash. The shift 6mq has my spare sim card in it and it has working mobile data and sms. Unfortunately cool audio doesn't work right now however Joel has recently

managed to make it work on the poker phone f1 so we should see support for cool audio and proper working calls coming to post market os relatively soon. I've heard for a lot of

people this is the last thing that they're really missing for this to be a daily driver phone for them. We'll bring up post market os tweaks and you can see maybe just about in the about section both devices running 5.16. As of right now I think these are the most powerful devices you

can buy which can run fosh on mainline Linux. So that's quite a nice achievement. Hopefully we'll be able to run newer core com socs with this kind of functionality in the not too distant future.

Here I'm just demoing some random youtube videos. Despite not having working video encoding and decoding we do actually have pretty good youtube performance. It can do 1080p and even 4k

without stuttering just on the cpu. In addition we also have android app support via wageroad so we can run apps like crossroads or you know slightly more useful android apps.

The android performance is about on par with what you'd expect it's fully hardware accelerated. Features like android audio are missing unfortunately. It's worth noting that whilst wageroad is basically linear us in a container it doesn't use any of

the device specific features so this doesn't mean that for example you'd be able to use the camera in wageroad. This is a question that I've been asked before. Whilst we have networking bridge to the android container features like audio still don't work yet unfortunately but

hopefully that's something that we can fix soon. The main benefit of wageroad is that it gives us the opportunity to bridge from our old ecosystems of android and ios specific apps such as banking apps and some messaging apps where they don't provide any linux clients

and we're able to use them on a linux phone until service providers can create linux native solutions for us or even better just open source their protocols. Thanks a lot for coming to my somewhat rambly talk on mainline linux on the snapdragon 845

and other Qualcomm platforms. I hope you've enjoyed your weekend so far and I hope you enjoy the rest of your sunday. If you have any questions I'll be more than happy to answer them in the Q&A session after this talk. If you'd like to get involved please feel free to join us on the postmark OS matrix channels and if you'd like to follow the work that I do then

feel free to follow me on twitter or mass it on. Hello, still good? Yes, I think we're ready

to go. Thank you very much for this very interesting talk and I'll pass on the

questions from the chat now. So Martin asked what is the progress on video encode and decode on the Qualcomm SOCs? All right, yeah video decoding does kind of work. The kernel side mostly works however there's like kind of broken support in Gstreamer right now so

the linux user space sort of thing doesn't entirely work. There's been some work to make it happen on android which is is good but yeah Gstreamer kind of needs to be cleaned up. To get that working properly unfortunately. Okay, is that a stateless code like the

the hunter ones or does it need special support? I'm pretty sure I need special support. There is kind of support in Gstreamer but I think it's like bit rotted a bit as last time I tried it it just about worked but all the colors are like completely messed up.

Okay, so Pranas, is it known how exactly the STM845 with Android kernel handles deep sleep and waking from it? Do you have any details there? That is a good question. I know the modem is

obviously like responsible for waking up the phone when you receive a text message and that is handled by interrupts for like mobile data stuff. That's always a bit of a mystery on android. I'd suspect that it does not keep a mobile

data connection active all the time but it'll like regularly revive it and check for notifications and wake up the the system to do that but yeah. Okay, still to figure out. Do you think the new android generic kernel image will help? All your android devices will

run the same kernel which Google promises will be close to mainline? That's a pretty big question. GKEA is definitely a move in kind of the right direction because now Google are aiming to enforce that actually the core kernel will be very very close to

mainline and it won't have any like random vendor drivers in it and they're just forcing all of the vendors to add support for their hardware via kernel modules. So this kind of sounds good in theory but what it means is that we're going to see SoC vendors make a driver and then every kernel version they just need to apply whatever

changes are needed to make it work again but there's no incentive for them to like upstream the driver support because now they don't even need to like keep it in the kernel and another feature of GKEA is that Google are going to maintain their own stable kernel API

so the vendor modules don't have to be like changed for Google to upgrade the core kernel so Google will go from say like 5.10 to 5.15. I'm not sure if they'd make that big of a jump but hypothetically they would do that jump a few kernel versions and they would have to then

like forward port the old API so that the old kernel modules can still work for devices that still use them so it kind of creates a lot of cruft and it doesn't really land us that much closer to upstream. Being able to upgrade to new kernel versions is good but yeah it's still a

lot of like changes. Okay next one is from Sebas. With regard to unlocking boot loaders, retrieving GPL kernels and such can you suggest any techniques that you found particularly effective in convincing manufacturers to cooperate? Well as far as I know OnePlus don't even

know that I exist so I can't say I've had very much luck with that kind of stuff. My suggestion really would be to find a manufacturer that actually share your values and then cooperation is kind of easy so like for example with Shift they produce a Snapdragon 845 device

and they've been like super helpful in encouraging like mainline development. They've been able to help with like getting UART on the device and building modified boot loaders to make booting

mainline easier and stuff like that so yeah really it kind of sucks for a lot of devices where that isn't really an option but I have just yeah I've not had very much luck with it. Okay which part of hardware is supported? Can we use it as a phone modem connection GPS camera

maybe for the devices used the most? Yeah so the modem works, mobile data and SMS work. Cool audio is like coming soon. I'm having some issues with the AP speaker but you can make a speaker call phone call now so that support will get merged quite soon.

GPS like works with some patches which have been trying to get into GPSD for like well over a year now and unfortunately haven't landed yet. The camera is work in progress on the Pocophone F1 we've seen some some early success and I've put some time into making it

work on the OnePlus 6 but yeah I'm very hopeful that we'll get the camera to work but it will take some time. Okay GLES is the hardware acceleration, is the next question

is web rendering hardware accelerated? Yes if you use a browser like Firefox it will be hardware accelerated. Okay I think we touched the camera support already which is the next question in case you don't want to add something more so maybe you kind of like

do the reference designs kind of like specify some specific sensor that is suggested to use or are they all different over the Qualcomm? Most devices use different sensors the OnePlus 6 and the shift 6 MQ both happen to use the IMX 519 the Pocophone F1 uses some other IMX sensor.

Yeah so it's basically a case of like reverse engineering sensor support and then getting the Qualcomm camera drivers to play nice which are in mainline again thanks to work done by Lenero to get initial camera support in mainline. Okay then there's a question do you think there

will be a port of LK 2nd to the 845 similar to the 8916 as the bootloader is somewhat broken on some devices? I don't imagine that we'll run LK 2nd because there's no support for the hardware where LK 2nd mostly supports much older Qualcomm SoCs. We do have two options which are

to chain load U-boot there's initial U-boot support where you pack it into the android boot image format and you tell the stock kernel that it's like a Linux kernel and it boots U-boot. Alternatively there's also work on EDK 2 which is actually the same bootloader

that the phone runs.