From Android to mainline on the Snapdragon 845
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Title of Series | ||
Number of Parts | 287 | |
Author | ||
Contributors | ||
License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/56925 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
00:00
Internet service providerComputer hardwareElectronic visual displayNormed vector spaceGamma functionData managementStandard deviationForm (programming)Water vaporMedical imagingLaptopDistribution (mathematics)Dependent and independent variablesBitRule of inferenceCuboidData miningAddressing modeReading (process)Game controllerSmartphonePatch (Unix)Disk read-and-write headSpacetimeConnectivity (graph theory)ResultantPower (physics)Electronic visual displayComputing platformData managementGeneric programmingComputer hardwareCore dumpBranch (computer science)Multiplication signSystem callAdditionGame theoryOcean currentLevel (video gaming)Series (mathematics)Software developerCopenhagen interpretationContext awarenessAndroid (robot)ModemComa BerenicesFlow separationStudent's t-testStability theoryMultiplicationHacker (term)CodeUniverse (mathematics)AreaDifferent (Kate Ryan album)Complex (psychology)Computer configurationBlogLine (geometry)BootingPeripheralKernel (computing)Internet service providerShared memoryClosed setCoprocessorBlock (periodic table)Mobile WebSystem on a chipTorvalds, LinusCommunications protocolAverageProcess (computing)Device driverAnalog-to-digital converterElectronic mailing listFirmwareDiagramComputer animation
06:06
Electronic visual displayGame controllerCloud computingKernel (computing)SpacetimeBootingAbstractionSystem on a chipCategory of beingComputer hardwareLatent heatBefehlsprozessorGroup actionDevice driverForm (programming)Connectivity (graph theory)BitMathematicsComputer clusterDistribution (mathematics)DivisorBlock (periodic table)Scaling (geometry)Core dumpData managementEstimatorQuicksortSoftwareComputing platformSoftware developerFirmwareWeb pageSoftware bugSoftware testingMedical imagingPatch (Unix)ModemGraphics processing unitLinear regressionPhysical systemInformationPower (physics)Limit (category theory)Cache (computing)EncryptionTask (computing)Term (mathematics)BuildingPairwise comparisonOcean currentRootRoutingTelnetRouter (computing)Electric generatorType theoryBit rateDirection (geometry)Configuration spaceDefault (computer science)Computer fileCartesian coordinate system2 (number)Open sourceData compressionComputer programmingInformation privacyHacker (term)Electronic visual displayMiniDiscCASE <Informatik>File systemAndroid (robot)Control flowGoogolMessage passingFood energyData structureLogicOperating systemDescriptive statisticsAuthorizationDigitizingNP-hardService (economics)Doubling the cubeConservation lawNeuroinformatikVideoconferencingSystem callComputer animation
12:05
BootingAndroid (robot)Open sourceNeuroinformatikExtension (kinesiology)Operating systemComputer hardwareBitCASE <Informatik>Order (biology)System callStatisticsComputer animationLecture/Conference
12:42
Cloud computingPhysical lawTraffic reportingBeat (acoustics)Standard deviationPixelMultiplication signSupersymmetryCodeColor confinementRule of inferenceInformation securityException handlingContent (media)DivisorSoftware developerCrash (computing)Fiber bundleKey (cryptography)Functional (mathematics)FeedbackWave packetBootingOpen sourceMereologyLine (geometry)Source codeSoftware bugStability theorySoftware protection dongleRootkitData storage deviceArmKernel (computing)Medical imagingWhiteboardCartesian coordinate systemAndroid (robot)System on a chipAsynchronous Transfer ModeLoginCore dumpHacker (term)Partition (number theory)Shift operatorComputer animation
15:21
Extension (kinesiology)Interrupt <Informatik>Cloud computingAddress spaceCodeExterior algebraOpen sourceNetwork topologyFormal languageSemiconductor memoryArithmetic progressionSystem on a chipDevice driverKernel (computing)Standard deviationMultiplication signBootingIntegrated development environmentSoftware testingPartition (number theory)Category of beingProcess (computing)Patch (Unix)Software bugTouchscreenQuicksortAdaptive behaviorExecution unitSoftware developerBus (computing)Shift operatorFunction (mathematics)LoginWhiteboardFormal verificationContent (media)Regulator geneMemory management2 (number)Computing platformOverlay-NetzLinear regressionSource codeAndroid (robot)Interface (computing)Exception handlingDemo (music)Game controllerComputer hardwareAddress spaceElectronic visual displayInterrupt <Informatik>Task (computing)Boss CorporationFrame problemWordSingle-precision floating-point formatVideo gameBlogMetropolitan area networkSystem callEstimatorService (economics)Line (geometry)PlanningFile viewerComa BerenicesComputer configurationNeuroinformatikTurtle graphicsTerm (mathematics)Prisoner's dilemmaStatement (computer science)FreewareAuthorizationLecture/ConferenceSource code
21:38
Cloud computingGame theoryControl flowCore dumpoutputConfiguration spaceSystem on a chipComputerComa BerenicesLatent heatFunctional (mathematics)Mobile appAndroid (robot)ImplementationClient (computing)BootingGoodness of fitShift operatorRandomizationBefehlsprozessorYouTubeDevice driverService (economics)PlastikkarteCommunications protocolSystem callInternet service providerOpen sourceAdditionSimulationVideo game consoleRight angleKernel (computing)Arithmetic meanBridging (networking)Sheaf (mathematics)VideoconferencingComputer hardwareUltraviolet photoelectron spectroscopyStreaming mediaComputer-assisted translationProcess (computing)Graph coloringBit rateComputer animation
25:38
Computing platformTwitterMassLecture/ConferenceComputer animation
26:12
VideoconferencingArithmetic progressionCore dumpMessage passingCodierung <Programmierung>Kernel (computing)Data compressionComputer animation
26:51
Android (robot)CodeQuicksortSpacetimeLecture/ConferenceMeeting/Interview
27:22
VideoconferencingBand matrixRow (database)1 (number)BitGraph coloringMultiplication signData recoveryKernel (computing)ModemDependent and independent variablesMessage passingComputer animationLecture/Conference
28:05
Figurate numberBitMobile WebAndroid (robot)Message passingInterrupt <Informatik>Physical systemCASE <Informatik>Multiplication signLecture/ConferenceMeeting/Interview
28:36
Android (robot)Generic programmingKernel (computing)Line (geometry)GoogolDirection (geometry)Core dumpRandomizationRevision controlDevice driverGoodness of fitModule (mathematics)TheoryComputer hardwareData conversionGame controllerMeasurementMathematicsComputer animationLecture/Conference
29:18
VideoconferencingBand matrixKernel (computing)Hydraulic jumpMathematicsCore dumpStability theoryDevice driverRevision controlModule (mathematics)BootingInformation retrievalEndliche ModelltheorieData conversionCollisionGroup actionCountingGoogolSound effectComputer animationMeeting/Interview
30:28
Kernel (computing)Computer configurationShift operatorOnline helpBuildingSoftware developerComputer hardwareStructural loadMereologyBootingComputer animationMeeting/Interview
31:36
ModemConnected spaceMobile WebComputer hardwareMereologyEstimatorMultiplication signArithmetic progressionSystem callPatch (Unix)Meeting/Interview
32:35
Web browserRight angleComputer hardwareWeb 2.0CASE <Informatik>Shift operatorDevice driverReverse engineeringMereologySystem callCore dumpDifferent (Kate Ryan album)Meeting/Interview
33:40
Computer hardwareBootingComputer configurationKernel (computing)Medical imagingStructural loadChainFile formatSystem on a chipAndroid (robot)Meeting/Interview
34:29
Computer animation
35:05
Computer animation
Transcript: English(auto-generated)
00:38
Hello everyone and welcome. I hope you've enjoyed FOSM so far. In fact, I hope I have too.
00:43
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
01:03
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.
01:21
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,
01:42
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?
02:01
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
02:22
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
02:42
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
03:02
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.
03:23
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
03:43
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
04:01
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
04:22
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.
04:42
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.
05:02
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.
05:25
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
05:45
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
06:07
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
06:24
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
06:42
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
07:01
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.
07:21
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
07:41
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
08:05
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
08:20
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.
08:42
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
09:03
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
09:26
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.
09:41
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
10:01
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.
10:21
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
10:42
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
11:01
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
11:24
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
11:42
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
12:07
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
12:25
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
12:44
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.
13:02
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
13:21
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
13:42
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.
14:00
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
14:25
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
14:41
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
15:03
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
15:24
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
15:40
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
16:04
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
16:27
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
16:40
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
17:04
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
17:24
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
17:45
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
18:06
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.
18:22
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
18:41
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
19:03
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
19:22
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
19:41
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
20:04
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
20:21
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
20:43
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
21:06
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
21:20
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
21:43
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
22:09
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
22:24
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
22:50
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
23:02
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
23:27
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.
23:46
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
24:02
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.
24:25
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
24:45
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
25:05
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
25:26
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
25:44
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
26:07
feel free to follow me on twitter or mass it on. Hello, still good? Yes, I think we're ready
26:35
to go. Thank you very much for this very interesting talk and I'll pass on the
26:41
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
27:04
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
27:26
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.
27:45
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
28:05
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
28:23
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
28:43
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
29:00
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
29:24
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
29:42
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
30:04
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
30:23
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
30:44
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
31:06
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
31:21
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
31:43
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.
32:04
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
32:25
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
32:44
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
33:01
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.
33:22
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
33:43
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
34:06
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
34:28
that the phone runs.