Running Mainline Linux on Snapdragon 410
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/56924 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computing platformGoodness of fitDecimalProjective planeCategory of beingMereologySystem on a chipClosed setComputer animation
00:22
WebsiteWhiteboardComputer-generated imageryBootingCommunications protocolAsynchronous Transfer ModeData miningGoodness of fitVirtual machinePlanningWeb pageFocus (optics)Physical lawGraph coloringSystem callProcess (computing)Single-board computerDescriptive statisticsArithmetic meanStructural loadInstance (computer science)Table (information)MiniDiscMereologyOcean currentImplementationPhysical systemChainElectronic signatureWorkstation <Musikinstrument>Content (media)Rule of inferenceArmBitInformationSmartphoneLie groupCovering spaceCoefficient of determinationFigurate number2 (number)Hand fanLevel (video gaming)Metropolitan area networkVariety (linguistics)Device driverMedical imagingCartesian coordinate systemBootingCase moddingOptical disc driveComputer hardwareKernel (computing)BootingSystem on a chipNeuroinformatikCore dumpSingle-precision floating-point formatInternet der DingeTablet computerProjective planeCodeComputer fileComputing platformMobile WebNetwork topologyLaptopComputer animation
05:17
Computing platformEndliche ModelltheorieProcess (computing)BootingAddress spaceInternet service providerBootingStandard deviationBefehlsprozessorInterface (computing)Process capability indexMultiplication signCore dumpCondition numberFile systemVariety (linguistics)Different (Kate Ryan album)BootingOperating systemMultiplicationAdditionElectronic visual display2 (number)MereologyHeegaard splittingFinite differenceCausalityTelecommunication
06:28
Electronic visual displayKernel (computing)Device driverCodeSource codeMultiplicationFirmwareMenu (computing)ArmNP-hardSequenceCodeGeneric programmingParameter (computer programming)Key (cryptography)Device driverSingle-precision floating-point formatElectronic visual displayFormal verificationMobile WebNetwork topologyKernel (computing)Level (video gaming)Standard deviationBootingMultiplicationRepository (publishing)Set (mathematics)ModemCombinational logicElectric generatorMathematicsPatch (Unix)Core dumpTemplate (C++)Different (Kate Ryan album)Source codeSimilarity (geometry)Menu (computing)HookingArmFirmwareGame controllerEmailProgrammable read-only memoryElectronic signatureInformation securityMereologyVideoconferencingMechanism designSemiconductor memoryProcess (computing)Auditory maskingNatural languageMoment (mathematics)Programmer (hardware)WhiteboardHypermediaScripting languageWebsiteHeegaard splittingVolumenvisualisierungAxiom of choiceCuboid2 (number)Sign (mathematics)Endliche ModelltheorieVirtual machineGoodness of fitTable (information)Symbol tableFiber bundleMultiplication signArithmetic meanChord (peer-to-peer)TrailMedical imagingNumberLatent heatCountingComputer animation
11:39
BootingFirmwareMenu (computing)NP-hardSystem on a chipArmLink (knot theory)Partition (number theory)Generic programmingComputer-generated imageryPhysical systemPhysical systemArithmetic meanNeuroinformatikPower (physics)NumberMedical imagingDifferent (Kate Ryan album)FamilyLogic gateMetropolitan area networkPoint (geometry)BitDampingWhiteboardPosition operatorBus (computing)Product (business)Goodness of fitBoss CorporationNatural languageEndliche ModelltheorieComputer configurationVideo gameCASE <Informatik>Key (cryptography)Inheritance (object-oriented programming)Decision theorySpacetimeLatent heatMultiplication signScripting languageInformationGodInternet forumAdditionProcess (computing)Android (robot)Proper mapHand fanFirmwareRight angleExtension (kinesiology)BootingSingle-precision floating-point formatNetwork topologyPlastikkarteSystem on a chipComputer hardwareElectronic mailing listDistribution (mathematics)Generic programmingMereologyBootingDevice driverModemAxiom of choiceSequenceSoftware maintenanceKernel (computing)Gastropod shellSoftware testingRobotFormal verificationSystem identificationComputer animation
16:49
Physical systemComputer-generated imageryGeneric programmingNumberSoftwareForm factor (electronics)WhiteboardSingle-board computerUser interfacePosition operatorHoaxCoefficient of determinationForm (programming)NeuroinformatikObservational study
18:12
AirfoilMultiplication signLine (geometry)Computer animationMeeting/Interview
18:34
Right angleBitMeeting/Interview
18:57
Endliche ModelltheorieDisk read-and-write headPhysical lawSystem on a chipMultiplication signMeeting/Interview
19:35
CodeOctahedronMeeting/Interview
20:13
Type theoryEndliche ModelltheorieValue-added networkLatent heatVideoconferencingLaptopTablet computerMeeting/Interview
21:20
Galaxy TabResultantLatent heatComputer filePoint (geometry)Structural loadNetwork topologyPartition (number theory)BootingAndroid (robot)Meeting/InterviewLecture/Conference
22:06
Medical imagingLink (knot theory)Physical lawRight angleGoodness of fitLogicForm (programming)File systemDifferent (Kate Ryan album)Order (biology)Forcing (mathematics)Physical systemCodeComputer fileBitPlastikkarteLine (geometry)BootingKernel (computing)Device driverBranch (computer science)Router (computing)Partition (number theory)Meeting/Interview
24:19
BootingBootingWindowMeeting/Interview
24:44
WindowPatch (Unix)BootingBitPoint (geometry)Meeting/Interview
25:18
Kernel (computing)BitSystem call1 (number)FamilySymbol tableTrailSet (mathematics)Coefficient of determinationMathematicsModemComplete metric spaceTouchscreenAndroid (robot)Different (Kate Ryan album)Meeting/Interview
27:11
Proxy serverSpacetimeTouchscreenCategory of beingSystem callDisk read-and-write headSocial classFigurate numberDistanceMeeting/Interview
27:56
TouchscreenRight angleAndroid (robot)Meeting/Interview
28:23
BitBootingDebuggerData storage deviceWindowMeeting/Interview
28:57
Computer animation
Transcript: English(auto-generated)
00:06
Hi, I'm Nikita, and I'm taking part in maintaining various community projects related to Snapdragon 410 system on chip. This includes, close to mainline Linux kernel, as well as various other projects and tools that I want to tell you about today.
00:23
Snapdragon 410, or MSM 8916, is a system on chip, released in 2013 by Qualcomm. It's the first 64-bit system, and can be found in a variety of devices, like mid-range phones and tablets, released around 2015. The reason this system on chip is interesting, however, is that there is a variant
00:43
of the chip called FAQ-8016-E, which is the core that targets IoT applications. One of the devices that is based on this core is Dragon Ball 410C, a single -board computer that, like other Dragon Boards, was brought on topstream Linux by Linero and Qualcomm.
01:00
It doesn't end there. For the Dragon Ball 410C, Qualcomm has released lots and lots of documentation, including things like Technical Reference Manual, a 3,000 pages PDF file that describes many aspects of the system. To my knowledge, there is no OGIS system on chip from Qualcomm with such detailed documentation available.
01:22
Using all of that previous work as a base, over a couple of years, we were able to bring up close to mainline Linux kernel on more than 25 devices, with over 10 of those having most of the features, such as mobile data and phone calls, working to the level of a daily usable device.
01:42
I know certainly from the questions we occasionally get that at least a couple of people rely on those devices as their primary phones, and they personally use a Snapdragon 410-based tablet instead of a laptop for almost a year now. I think some of you might be already familiar with the fact that smartphones usually come with a heavily
02:02
modified vendor kernel, and that the process of bringing upstream Linux, the one from kernel.org, is often called mainlineing. There was a deeper talk by Luca about this process yesterday. But if very shortly, mainlineing is the process of porting or rewriting the missing drivers and reading a device tree for the device in question.
02:26
The device tree is a machine-readable description of all the hardware in the device that is used by the kernel to load and configure all required drivers. My plan today, however, is not to focus on the kernel side of things, as there
02:47
are many other parts within my mainlineing-related infrastructure that I think also deserve some attention. If you want to hear about Linux, you might be interested to see Caleb's talk later today.
03:00
They are going to describe their story of bringing up mainline Linux on some Snapdragon 845-based devices. The first problem that we have encountered is that the fact that the vendors like to customize the bootloader.
03:20
You might be familiar with something odd in mod that replaces fastboot. This means that the very convenient features like fastboot boot are missing. And even if the devices use the more generic bootloader with fastboot, it might also have other quirks, like implementing fastboot in a way that doesn't fully align with the current fastboot implementation.
03:42
In particular, on some devices, flashing images must be done with a special raw flag, which is not a usual behavior. Fastboot in MSM 8916 is implemented in aboot, which is the last bootloader in the chain. We can't replace it due to the fact that its digital signature is verified on boot,
04:04
and even if we did that, it usually provides some information that we want to know. But do we really need to replace it? In fact, we don't. We actually can put a shimbootloader into the boot image instead of the Linux kernel and do whatever we want there.
04:21
The stock bootloader will then load as if it was the Linux kernel. But what we can use for that bootloader? There are multiple bootloaders that can come to mind when thinking about something like this. U-boot would be an obvious first thought. Something like edk-second can also be used.
04:41
However, one would have to bring up the platform on those almost from scratch and adapt to this completely new bootloader usage workflow. Early on, we didn't want to put lots of work into the boot process, so we decided to use something that already has all the required platform code. An already existing bootloader implementation.
05:03
And this implementation is the same aboot. We took the reference aboot code, which is based on little kernel from Coder Explorer Farms, and adapted to boot it on all MSM8916 devices. This project is now known as lk-second. Initially, lk-second was only meant to provide Xena fastboot on Samsung devices as bucket.
05:25
But it quickly became almost mandatory for booting Linux on our devices. It makes lots of different preparations, like giving the MAC address to the device, booting secondary CPU cores to help with the fact that standard PCI interface is unavailable, as well as some other things like condition reputching the device tree, and reading the boot file system.
05:49
Right now, lk-second supports a variety of devices on multiple platforms, including MSM8226, Snapdragon 400, and MSM8974,
06:01
Snapdragon 800, in addition to MSM8916, where using lk-second is almost mandatory to boot Linux-based operating systems. Around the same time when lk-second was started, we also were working on bringing up the display on the first MSM8916 devices.
06:28
On a desktop, where many different displays may be used, there are predefined standards of video communication, like HDMI and DisplayPort. And more importantly, there is a standard of communicating the display capabilities, known as EDID.
06:45
In the embedded world of mobile devices, there is none of that. Who needs to have a display detection code if you can hard-code all the display parameters in the driver itself? As such, even for the common transport, MIPI DSI is used. Every single display
07:02
panel must be properly configured by the kernel. There are special panel drivers for that. Thankfully, making a basic panel driver is easier. Copy a template from another panel and just change the init commands to whatever your downstream uses. Even more conveniently, Qualcomm encodes those sequences in the device tree of the devices, so
07:24
we have really easy access to this data, even when we lock the kernel sources. Well, copying and rewriting a dozen of commands is easier, but sometimes there are hundreds of them. Converting that by hand is not only annoying, but also error-prone.
07:42
And since the data is already in a nice machine-readable format, and making a driver is just copying that into a template, maybe we can automate that. And of course we can. Linux MDSS-TSI panel driver generator, which we often abbreviate to LMDPDG or any other similar
08:00
-looking combination of symbols, is a tool to generate clean upstream Linux-compatible panel drivers just by passing the downstream device tree. LMDPDG generates clean C code with an aim of being upstreamable, and some people already got a couple of displays upstream with its help.
08:24
However, the drivers it generates aren't perfect, as they assume one specific display configured for a single device. With 25 devices, we have over 30 display panel drivers, while we could probably have just a couple of generic display controller drivers.
08:43
The unfortunate reality, however, is that the documentation for those controllers is almost unavailable, so we end up with many more simple drivers tailored for a single device. In some way, how the display vendor decided to leave it.
09:02
You may want to ask, why there are more display drivers in the devices? There is this problem. One does like to multi-source the parts. This means that a given phone may have one of the multiple display panels. Each needs a driver, and there is no mechanism in Linux to select one of those, nor is it usually known how to know which one is there.
09:27
Do you remember me mentioning that LK7 does some device tree patching? Downstream handles multiple panels by passing the command line parameter from the A boot and deciding which init sequence to send to the display.
09:41
We don't want to implement that in Linux. What we do instead is that we read this parameter in LK7 and patch the compatible value of the panel in the device tree. This way, the kernel doesn't need to care that, for example, Redmi 2 is known to be shipped with five different panels. To manage all of the panel drivers that we need for devices, we have even more automation.
10:06
A set of scripts, called Linux panel drivers, which acts as a repository of device tree blobs and automatically builds the required drivers and places them into the proper place in the Linux kernel tree. This enables us to make changes to the generator and apply them to all panels instantly.
10:25
Maybe one day I will hook up Gitsend email to it. While talking about LK2, I've mentioned that the device verifies some digital signatures on boot.
10:43
This is called secure boot, and unlike UEFI secure boot, which should be familiar to many, this one is a bit different. While on UEFI one can disable the secure boot or replace the sign-in key with a special menu in the firmware, on the ARM devices it's often implemented a bit differently.
11:03
The public key, or its hash, is bound into the device's eFuses, one-time programmable memory in the chip itself. Then, the boot ROM, the initial boot loader, which is also bound into the chip, verifies the next stages against that key to make sure that only official firmware can boot.
11:24
All of this basically means that you have no choice other than to use whatever was signed and provided by your device vendor. On MSM8916, this includes all boot loaders, hub-to-a-boot, as well as all of the specialized cores like modem and Wi-Fi.
11:42
Until recently, the solution to this in post-market OS was to just package the blobs for each model, which works reasonably well if you assume that only one hardware model uses a one sign-in key. In reality, however, it's not the case. Samsung, in their greatest wisdom, decided that they should sign the
12:02
firmware for each original variant, even when the hardware on those devices is the same or very similar. For example, if you look at Samsung Galaxy A5, you might find that it can be one of the following models, as some A500F, A400FU, A500H, A500YZ, and so on.
12:23
All of those devices can work with the exact same system image, but Wi-Fi and modem will only work on this one for which the firmware is installed. On other, verification of the keys will fail. Making a dedicated device port and the system image for each variant is a maintenance nightmare, so we have to find a better solution.
12:45
This solution is MSM firmware loader. This is essentially a small shell script that reinvents the wheel by running on boot and mounting the Android firmware partitions, then assembling all of the blobs from them in the correct places so mainline Linux kernel can find those blobs and load them from the expected place.
13:07
Since blobs are now loaded from the device, this firmware fan becomes to some extent transparent to the OS. Right now, the firmware is probably the biggest device-specific part of the system image, and with it being removed, the OS images can be more generic across the devices.
13:24
MSM firmware loader makes the system more generic, but there is actually one very big problem that stops someone from taking an SD card from one phone, plugging it into another one, and expecting it to boot. You remember that Linux needs a device tree for the device it boots on.
13:41
Usually, the bootloader can pick one device tree from a list of given ones and pass it to the kernel. However, the reality is that the vendors often didn't set it up properly, and different device models often throw some identification numbers that the original bootloader relies on.
14:02
Since we can't rely on that, an temporary solution is to add a single device tree to the system image and assume it's the correct one. Obviously, this leads to various small problems, like dealing with almost the same devices or having a possibility to boot an incorrect device tree on the device.
14:20
Those problems is what I'm working on right now. Ok, second, I already can know precisely on which device it has started, as it needs this information for other things. So, we could reuse that to pick the device tree from some container. This will immediately have a lot of benefits. For example, subtly different device variants can be handled seamlessly, the risk of booting
14:47
incorrect device tree is mitigated, and the system image can boot on any supported device. The latter is especially with what I'm interested in to achieve. Not only I have a lot of devices that I have to deal with, but this also implies another very cool thing.
15:04
So far, we were focusing on postmarket OS as a distribution of choice for MSM8916 devices, since it already provides us with a great tooling, and it can handle both device system creation. However, if we are to support our devices with more than one distro, I think the
15:23
burden of maintaining over 25 dedicated device ports in many distros is a bit too much, especially with it being unlikely that all of them can be tested in a timely manner. On the other hand, I think it's unfair for those distros to start from scratch, waiting
15:40
for someone who would make a port and test everything so they can start advertising the device. Because of that, I want our bot infrastructure to be able to support generic system images before we get the devices in different distros. This will allow us to provide a single generic port that will automatically provide all of the devices with support.
16:04
And if someone is interested in polishing a specific device, they can derive from that and expand a device-specific port. Of course, there are other things to work on, for example, cameras and power saving, but those are rather complicated. For cameras, one would need to figure out how to initialize the cameras, because the initialization sequences are encoded in the user space blobs.
16:33
And for power saving, someone would have to check every single driver used in a specific device to make sure
16:41
it supports proper power saving features, as well as make sure that the system on chip can power save properly. In the end, I want to mention that we wouldn't have had a chance to face those problems if not for the amazing community behind the Linux on Phone efforts. There is a person behind each of those devices who did the porting and testing, as well
17:04
as there are all of the people who make the UIs and software for this form factor. I am grateful for all the efforts that were poured in by those people and companies. For those curious, in this presentation, I had following devices.
17:20
There are two tablets, some from Galaxy Tab 8 2015, both 8-inch and 10-inch. There is a Willy Fox Swift, which is this phone. The single-board computer is Genia DB4, which is a single-board computer compatible with the Ragon board 410C.
17:42
Two other devices are based on MSM8226 and are there to showcase LK2. The smartwatch is LGG Watch R and the orange phone is Nokia Lumia 630. Thanks all of you for being interested in this topic and listening to my talk.
18:05
And with this, the future of me should be happy to be answering your questions. So, thank you Nikita for your nice talk on how you went about mainlining Linux for the Snapdragon 410.
18:43
There were a couple of questions, so let's get right to it. For example, Martin asked how many MSM8916 devices do you have now? So, I counted a bit while we were watching the talk.
19:01
So, if you count like head by head, I have 15 devices, but excluding duplicates is like about 5 maybe. Not too much, in fact. We have about 30 models supported, so it's just a little. Sounds like a lot to me.
19:23
DanCT12 asks, aside from the MSM8916, what other SoCs have you worked on, be that Qualcomm or not Qualcomm? So, I spent like almost all of my time working on mainlining with MSM8916,
19:42
but I've mentioned I have a couple of MSM400 devices like this Nokia, the smartwatch, G-Linux by the code name. And while I didn't like work actively on those, I kind of poked at things a little bit. So, maybe I will join people working on them, try to help them to do something possibly on their second side more than on the kernel side.
20:14
And then there's also the question, which of those MSM devices of the couple that you have is your favorite one to use and why?
20:26
So, to use, I have mentioned already that I use a tablet, this one. And this is by far my favorite mobile device, like not only MSM8916, but just a mobile device.
20:44
Because it's basically a tablet and it's a Linux tablet because they have mainline on it. Some clocks like battery saving are not as apparent on the tablet as on the phone because they can turn it off. And I was using it as my main tablet for like almost a year now.
21:07
It will be like a couple of months that I would use it for a year. I put it in my backpack as a laptop and it works fine with Firefox. I can watch videos on it. It's an amazing thing. Which tablet is that? Like what vendor?
21:23
It's Samsung Galaxy Tab A 2015. This specific one is a 10-inch model, but the result is a smaller 8-inch one. So they are both very cool. Cool. We'll have to maybe get one of those at some point. It certainly looks nice.
21:47
Arnoa is asking if LK2 can also load files like kernel, initremfs, device tree files from a normal X4 or a FAT32 partition.
22:05
So LK2 initially was booting basically an Android boot image, but at some point, I think like a year ago, I added basically there is a bit of interest to use it to boot from the file system because it allows us to do system updates.
22:34
Ms012 did a bit of work. He figured out that the file system drivers for my line LK,
22:43
Stefan Mein Krell by the nickname, did a bit of cleanup for that, but it was laying in a separate branch without some business logic to boot. At some point, I took all of this and wrote a bit of code to basically scan the partitions and boot the same boot image but from the file system.
23:04
This allows us to basically reuse whatever PostMarketer uses for system updates and don't refresh eMMC at all. LK2 also supports SD card for MSM8916 for now.
23:20
I basically can take one SD card, log it into the device, it will load the boot image from that SD card and boot the router path. So that was one of my goals to achieve and this work from those other people who also tried to start on it, I finished it and it works pretty good.
23:41
For other files like DTB or dedicated kernel files, it's not really my interest for LK2 for now because we also want to have first boot boot working and in a way unified boot image helps with that.
24:02
But in the future, we could basically just load the kernel file and the DTB. It's a bit more complicated to select which DTB would we boot because we want to support everything. For now, we have nothing but I have some ideas to fix it. Okay, thanks for the exhaustive answer.
24:23
Oli is asking if it's possible to boot LK2 from that Windows bootloader that you showed in the presentation.
24:44
It boots from the Windows boot manager in fact. But it's a bit complicated. The SNW400 Windows Phone people had a couple of shim bootloaders before that. So UEFI boots this shim bootloader, it boots some other thing and it already boots LK2.
25:06
We had to patch LK2 a bit as well to support that but you end up in LK2 and at that point it's basically as any other device with LK2. Okay, interesting.
25:22
Currently, I can't see any other questions but you've mentioned to me that you had a fun story to share. Maybe we can do that now. Yeah, it's like a little bit unrelated to the talk because it's more kernel question in a way.
25:40
But basically, you know that there is a feature of the phone. No, it won't be fun to describe it. Okay, I will describe it a bit differently. Basically, one person went to us in the chat and they asked that their modem stopped working at all.
26:06
They mentioned it stopped working in the middle of the call. So I spent like half an hour debugging it. So what I discovered, my idea of what happened, the modem was basically disabled in the settings.
26:24
And I think what happened, if you look in Posh, you know there is this button. And on Android devices, it's supposed to disable mobile data.
26:41
Here, I think it disables modem completely. I think what happened is that they were talking on the phone and they pressed the button with their ear. And on most devices, we didn't have a proximity sensor enabled at all.
27:00
So the touchscreen was enabled. They were talking and disabled the modem. I didn't understand what was happening until they mentioned that in the settings, the data was off. I was like, is this mobile data or is it the modem?
27:20
So that's basically a very small feature of proximity sensor. We kind of forgot about it in a way. It works in the CFS, but we basically needed one small property for the IEO sensor proxy to know when it's near.
27:40
And without it, we were testing it in the CFS. It works fine, we can keep it and move on to other things. I basically had to figure out why it didn't work in the user space after this person had a problem. Yeah, I've definitely been there, especially before Posh started to actually blank the screen when there was an ongoing call.
28:07
Chris Simons is asking what tools are you using the most to discover how a device boots? Is there ADB, Android Debugger, or even GBB?
28:22
So how a device boots? It's like, basically, I kind of don't get how to answer this question, but in a way, I rely on some previous knowledge from how Android boots.
28:42
Because there is a little bit of documentation, a little bit of other knowledge about which could load it. Based on that, mainly. No special debug tools.