as we did, so we try to cover as many, it's unfortunate, there's so many topics to cover
when you do mobile, for Linux mobile phone stuff.
Okay, welcome Luker, we have seen the first pair of phones being used as a presenting
device this morning, so now we are going to learn how to put the kernel on it.
Thank you, yeah so kind of very quickly who am I, my name is Luker Weiss, I've been learning
phone since like 2017, I'm a post-marketers core team member and also my day job is Android
platform engineer at Fairphone, kind of about the background of how the whole situation,
so I mean Qualcomm has a lot of lot of SOCs like system on the chip, there's quite a lot
of actually already supported, so you see all these wonderful numbers here, the ones
launched since 2018, so like in the last four years, and they are already supported in Mainline
as in they have a DTSI file and you can build something on top of this and it's booting.
But of course there's also many, many others that aren't supported, especially mid-end
ones like the high-end ones are normally very quickly supported by Linaro, so like for example
the SM8550 is the newest one, it was basically supported in day one or the same with the
SM8450, but yeah the other ones are not, but you can of course do it yourself.
So the device, Fairphone 4, used the Snapdragon 750G, the SM725, yeah launched like a year
and four months ago, running the 4.19 kernel, so which is already, I mean we had 6.2 nearly,
and yeah like what I have so far working on the 4.9, on the 6.1 or 6.2 kernel is like
all the basics that you can see here, USB including nearly the USB role switching, so
you can actually plug in for example a keyboard into the device and not just use it like as
a gadget, and internal storage in the SD card, so the UFS and other things.
Display with backlight control which is separate components, touchscreen GPU, Wi-Fi, the remote
prox which is like separate cores on the SoC, they are actually all booting, but at least
for the modem one I'm actually not really able to communicate with it.
Mobile data could also in theory work, so the Linux driver initializes it actually gets
the remote prox up, it already does some initialization things there, but it's not really testable
without actually having the modem up, so it's kind of untested, it's upstream already.
Vibration motor, the flash and torch LED which is actually was upstreamed recently or is
in the process of getting upstreamed, the camera I2C bus, so I can actually talk with
like the I2C set and I2C get commands, I can talk with the camera, and like get the
chip ID, so that works, but yeah, not really much more useful with the camera yet.
And also lots of other plumbing which includes like, yeah, of course all the I2C bus, interconnects,
like the bus scaling, cache scaling, and yeah, bunch of other stuff that's useful.
So kind of what isn't working yet after this one year and four months that I've been sort
of working on it, I have some parts that are actually sort of working, it's like the speaker,
I do have, I can get sound out of the speaker, it is super quiet for some reason, I don't
know why, and also for some of the audio formats it actually doesn't play at all for some reason,
I know.
One of the problems with the speakers also like not very many phones in Mainland actually,
like Qualcomm phones have audio working, so it is still kind of a new area where this,
yeah, where a lot of things are kind of unknown.
In Bluetooth I have based on some patch set that I found, you can get it on the Bluetooth,
you can make the phone discoverable, so you can see it on other devices, you can actually
connect other devices to it, but when you try to like on Bluetooth CT area, do the scan
on command, like it just fails.
So which is a bit weird, I don't know why, probably need to spend some more time on it.
And also like of course all the other parts that don't work, so the modem as I said before,
I can talk with the modem via QMI, so the Qualcomm protocol, but when I say please enable
yourself, it says nope, and doesn't say anything else, so it's kind of difficult.
The microphones which are like also kind of, it's a different part of the audio stack.
The camera sub system which is used for receiving image data from the sensors, it's not working,
including the time of light sensors, like for autofocus it can be used.
And the video encoding, decoding hardware which is for, so you can play MP4 for example,
without actually doing the decoding on the CPU, NFC, the fuel gauge, so for battery percentage
and the charging driver, they are not working, they are actually, I was able to port the one
from the 419 kernel to mainline, like just import it.
It does sort of work the fuel gauge driver, but apparently there's some weird, really
weird things going on on Android where like a user space component writes something to
the kernel driver, and without this like nothing works basically, it's super weird.
And also this part of the USB-C, what Alfred already demonstrated before, like it works
in the hardware, but it doesn't work with mainline, just with the downstream kernel.
So kind of what is the things that you need to have when you're trying to get a new SoC
network, it's like one of the first steps is kind of also figuring out how can you make
this boot loader boot what you want to boot.
Because in the Android case, like Google requires some special things going on, and also the
way that many SoC manufacturers implement it is kind of sometimes working, it is working
for Android, and that's good enough for them.
And for example, the DTPO partition, which is device tree blob overlay, on some devices
you can just fast-boot erase it, and then it doesn't try to apply some overlay for the
old kernel on top of the new kernel, which doesn't work and doesn't make any sense.
On some devices just crashes and burns, and yeah, it is not fun.
So mostly you can do this, and there's also on new devices with GKI, the generic kernel
image from Google, there's also the vendor boot partition, I actually have no idea what
this one does, and how you need to wipe it to be able to do something.
The serial console is actually quite useful if you can have access to it in the boot loader,
if it doesn't boot.
Like if you cannot even get Linux booting, normally on a serial console it will say what
it's doing and why it's not doing the things that you want to do.
It's like, yeah, on the Fairphone 4, on the new SoC, I got the first boot actually after
some hours of working on it, which contains the early console, it's just basically already
set up area where Linux driver can write to it, and you get serial output, and also the
display via simple frame buffer, which is actually now way more easy than getting USB
up or getting actually proper serial console up, so it's super nice.
Simple frame buffers where the boot loader already sets up the display hardware correctly,
so Linux actually just has to write to some memory area, the bytes for the pixels, and
it will just magically appear on the screen.
It is very nice, very useful, and yeah, the first boot was in like 180 lines of the DTSI
for the SoC and 40 lines for the device, so yeah, total 220, and no single driver change
was necessary for getting a completely new SoC booting anything, basically.
Yeah, I was basically just following what Iskren wrote on his blog, mainline.dev, super nice,
it really contains useful steps for the very, very first things that you need to do.
Yeah, so if you want to go a bit further, you very quickly start to need the clock driver,
which is GCC, global clock controller, driver, now you can basically just take whatever Qualcomm
gives you, for example, for the 419 kernel, copy it over, modify a few small things, but
then it works.
You also, at least for the 419 kernel, also these power domains, which is like, is some
concept in Linux, it's also called GDSCs, you need to, they were a bit differently
implemented, not in the GCC driver, but you should put them in the GCC driver for mainline.
Now there are more clocks with the RPM edge, also like various other bits you should add
to the DTS, because otherwise it just won't, like random things won't work, which are dependencies
that are not really expressed in the device tree, but the drivers still need, for example,
access to the S-MEM for like doing various things.
These definitions are basically all the same in downstream, so you can also mostly copy
them over.
Don't blindly copy them over, because it will be slightly different, but you can definitely
get good inspiration of what you need to do.
USB is, of course, kind of the next step, because just staring at the tiny text on the
screen is not very good debugging, and you also don't have any input.
You can do surprisingly much with simple framework, but at some point you, of course, want USB,
at some point also a pin control driver, which is for the pin multiplexing.
This really only starts getting used for once you get to more advanced components, let's
say, for like I2C and other things, and also regulators are important at some point.
I think that's actually, I don't know if you already need this for USB or not, but these
are kind of the basic components that you need, and then you can start building actually
enabling various components that you find, like the flash driver, the vibration motor,
and things to talk I2C and things to talk other protocols.
Of course, lots of things that can go wrong, the IMU is especially on new Qualcomm chips,
it's kind of annoying.
I mean, it's less annoying than old ones, but it's still annoying, because a lot of
things, like some things that you do, or yeah, let's talk about IMU directly first,
so like what's a bit different between downstream kernel and also mainline, is the bootload
already initializes something in this memory seguration, or like SMMU is also called.
I initialized some things for the bootloader to use, for example, for the internal storage,
it already initialized it.
This normally gets on downstream kernel, it just continues using those and adds some
ones on top.
On mainline, they actually get wiped completely, and they need to be reset up by Linux, which
causes some problems if the downstream kernel doesn't express like which IMU to use, for
example, for UFS, it's a very good example where it is bad.
So you kind of need to find out there is a patch, there you can actually dump the mappings,
and yeah, you can use this to figure out what it is.
Also, the device really likes to reboot when anything is not really right.
If you access some register in the clock, and some clock isn't on that it requires,
it just reboots.
It doesn't give you a kernel panic, it just reboots.
If you're writing to a wrong register, it reboots, the IMU is defined wrong, it just reboots.
Actually a thing for the IMU is that it sometimes gives you a message of why or at least that
something isn't correct, but yeah.
For printing, what I've actually used sometimes is just printing the current line where this
in the driver, like sprinkling this everywhere, adding a sleep of like half a second, and
then seeing like, oh, this is the last line that I was seeing, so it's probably messing
up there.
And maybe also increasing the sleeps, because sometimes the flushing doesn't happen, like
printing it on the screen actually is a bit slow.
Also, for like once you have like more USB up, you can actually also build various drivers
as modules, and this way actually, yeah, it's not built in, and if it's built in, it loads
like it's, I don't know, it like kernel locksack and 0.5, which is quite early, and if it then
crashes immediately, you don't really have any time to be the debug, but if you build
this module, you can load it later and actually have something set up already.
Yeah, like what is important to do if you work on this, actually if you have anything
working, if you have something working progress, just commit this into your repository already
to have a reference point to go back to, because sometimes one single line change will fix
everything or break everything, and like you can, your first commit doesn't have to be
perfect, obviously.
But also don't let this sketch branch that you have lying around want to have something
working, don't let it sit around in your local repository on your GitHub fork or in your
GitHub repository wherever, forever, and don't upstream it, because then it will just drop
there and nobody will know that it's there, and they will probably, like this next person
has to do exactly the same thing again, even though you have already got it working.
So like already starts upstreaming your patches early, like if you have simple framework for
booting on the device, upstream it.
It would be very nice, because there's also a better overview of which SSCs have already
been worked on, and it's very nice.
Of course like when you upstream it, you also have to do some extra things, for example,
adding the new compatible strings that are used in the device tree added to the documentation,
and do some things there, but it's normally, it is, yeah, some extra work, but it's really
not too bad.
And also patches just because of how Linux development works, just takes some time to
get upstream.
So like two months later, if you go to, if you re-basement new version, your patches
already there, so you can build on top, and don't have like 100 patches lying in your
own tree.
Or it's like get send email is not difficult, if there's a wonderful guide, get send email.io
from the source developers.
It explains it super nice, once you have configured once, it just works, yeah.
Thanks for listening.
We basically have one minute for questions.
When you get GPU working, you should also actually get the display hardware working
properly.
But yeah, this was fortunately done for, for this SOC was done by Konrad, who is, who
knows a lot there, like he got the display hardware completely up in the GPU also.
This is used for actually, because simple framebuff, you cannot turn off the screen,
you cannot basically do anything except just write pics of some memory, write data to,
or write bytes to memory area, and that's it.
Yeah, so you actually need to get the display hardware also up, but then you also get, can
get the GPU up.
And yeah, this one works really well in mainline.
Like I run performance benchmark on it, it's actually, not too bad, it's actually relatively
close to the downstream version.
Yeah.
I've contributed to the SDM 625.
Mm-hmm.
Like, you know, how to up the screen and manage the complexity of partners, generated partners?
Are there panels? Yeah, the panel drivers are still, I think in general, a question of
like how they should be handled upstream, because in theory, I think the panel drivers
are not really generic, I mean, they are not generic.
But in theory, they are relevant to the, to the display controller, and not actually
a panel itself, which is two separate parts, but like, without having actually access to
like all the documentation that are like internal to the company, you won't find out
which, which driver this actually is.
And currently, let them sit around in your tree, they are, I mean, most of them, you
can also just generate from a downstream DTB, and it works, so good enough for, for now.
At some point, we probably figured out, but the MSM8916 people also, they, they have like
already like 20 or 30 panels there.
I think trust is always running, so like the boot loader, which is like, it is a signed
binary, and you cannot really replace it without having access to the, to the signing keys.
It is running, I think, and it also, I think this is the thing that kills your, that kills
the phone, like when you're doing something wrong.
I don't know, you cannot get rid of it, I, you can probably somewhat communicate with
it.
I know that normally the fingerprint sensor is handled via Trustone.
I was like, you actually talk to Trustone for the fingerprint, but I actually don't
know how this works.
Okay.
Thank you very much.
Thank you.
Thank you very much.