So, hello and welcome to my talk about the Eola C2 and how it's possible to run mobile
Linux on it.
So what is the Eola C2?
It's a smartphone released by Eola in 2024 as a reference device for the salefish OS community.
And it seems to be a community-seemed as a device mainly targeted at developers and it's
nearly identical to a low-end model sold in Turkey with the UNISOP UMS-9230 system on a chip.
Yes, so with salefish OS, you of course have a Linux system on the phone already and it's
quite nice, but as you can see, it runs a relatively old kernel version.
So yeah, it's a typical situation where the SSC manufacturer releases a vendor kernel that
is a park for Android, made to work with the Android hardware support layer that salefish
OS then uses through Lib Hybris, but my idea was since this is supposed to be Linux first
phone, why not run a mainline kernel on it, so I decided to try something new because UNISOP is
not that well known in the mainline in community.
Yeah, so where do you start?
The phone is pretty complicated, but you have the kernel that is responsible for managing
access to the hardware and I had to start by replacing that from scratch and for that
I had to start getting it to boot first, so I had to find a way to make an Android boot
image that would boot my new kernel and that I could flash and then yes, so the Android
boot loader does a few nice things like setting up the display output and setting up the
storage, but unfortunately it also manipulates the device tree it provides the kernel with
and requires a device tree overlay and things like that and since I didn't want to deal
with that I decided to add another layer with an intermediate U-boot boot loader which provides
its own device tree and has some space to implement various initialization steps.
Yeah, but I didn't spend much time on that, I then had to get the kernel working and
there it's useful to see what is happening on the device to tell if it's booting at all.
The devices have a U-art, but that's usually inside the phone, so I didn't want to
just assemble my phone, it's hard with this glued back cover and instead the Android
loader sets up a display output, you can set pixels in memory first and then once drivers
can load, you can load it, you can create a, you can use a frame buffer console, but then
it's so safe, you need to implement everything step by step, so you have a lot of different
components that implement the different communication features access to the peripherals
on the board and usually you start by writing a clock driver that supplies the components
with a clock signal, allows enabling this clock signal.
Then you already have output from the device, but it's nice to get some interactive debugging,
so one of the first drivers I wanted to get working was the USB driver, there I need
to write different registers, write values to different registers in the SOC to set up
the physical layer, and those registers are quite obscure, so in the downstream kernel drivers
from Unisauk, they have names like test or something, but it's relatively short sequence
of registers you need to write to get USB enabled, but then you also need a controller
driver, and that's where it gets messy here, so it's a relatively old controller from
the MUSB family, and even the upstream drivers there are quite old, I got it to work in device
mode, but in host mode it's still sometimes gets stuck with DMA transfer, I don't know
why, and then also the phone reboots at some point after rebooting the kernel because there's
a watchdog that's supposed to prevent the kernel from hanging, usually you fix that by adding
a driver for the watchdog to periodically tell that the kernel isn't hanging, but here
this didn't seem to have any effect at first, and I'll get back to that later, so you
can start already contributed a lot of, oh, not a lot, but some drivers to the upstream
kernel, and I could use a lot of them directly, so I'll just briefly mention the components
that were just needed a few changes to bring up, so the display driver needed some bug fixes
and it only supported an older SOC, then we have the regulator driver, there was a regulator
driver, the regulators are on the PMIC, not on the SOC, so you need a PMIC driver, which already
existed, and the regulators were implemented for an older SOC, the downstream driver was
extremely similar, so merging the upstream and downstream was relatively easy there, then
to access storage, there was the host controller driver worked with UFS, there was another
case where you need to set up physical layer with another obscure register sequence, but
other things were much simpler like GPIO and post-width modulated outputs, a lot of other
things in the PMIC too, so battery management driver wasn't very complete, but other drivers
were already there, not all the downstream Android drivers, for example, for the UFSBPD protocol
still, they weren't sent upstream, but then also the I2C and so on the standard buses for communicating
with on-board peripherals, like the touchscreen, yes, so now it's time, I want to show a video
where the kernel just boots with a simple frame buffer and a storage driver, so I can skip
this part, the bootloader loads the kernel and then it can boot to a login prompt, but
you can do much else at that point, so now we get to the interesting part, yes, now
besides all these simple peripherals, the SOC also contains entire processors dedicated to
implementing communication features, and after getting a power domain driver to bring them up,
to power them up, you have to write drivers that load the firmware into memory and start them,
the firmware is unfortunately proprietary, but I was able to boot them with the firmware
taken from Android or from self-ishores in this case, because it's the same, and then you have
to communicate with them somehow, and here in the SOC shows a shared memory approach where the main CPU
is established is a ring buffer channel with each of these endpoints, and I had to write a driver
for that in the RPMSG subsystem in Linux, which is quite different from what Unisucked and
downstream. One of these processors is worth noting, because it does some seemingly random
system-related tasks, and it also manages the watchdog, which is why my phone rebooted, so I
had to first load up this processor and tell it to manage the watchdog, and that was required
to get the other watchdog for the CPU to function properly. Bluetooth was relatively easy to implement,
because that has a standard serial protocol, that I could just use over this channel, and
that worked almost right away. Wi-Fi was much harder, and it started implementing a new
driver for that, and it can connect to network, and then it sometimes stops dropping frames,
and sometimes it works. Yeah, then it's a phone, so you want to be able to use it as a phone,
and for that, you need to have sound, and you need to also want to take pictures, so for the sound,
the audio goes through a DSP, and you need to tell the DSP to start a stream. You also need drivers
for the PMIC analog audio codec, and for the PMIC SSC link, yeah, those didn't exist yet,
so I actually wrote those drivers. And for the camera, I was able to write
drivers not only for the camera sensor interface, but also for the image processing pipeline,
because UNISOC has open source downstream drivers that actually have a list of all the registers
in the ISP, and you can, yeah, so it's actually quite straightforward to write the configuration
to the registers, then you set a buffer address, and you need to trigger it to start processing
frames, so the challenge there was getting that integrated with the Linux V4L subsystem. Of course,
yeah, there are parts that are proprietary, where we don't have the advantage of this
register list, like for the hardware JPEG and video encoding blocks, which is unfortunate, and they haven't
looked into implementing those yet. The SSC can do more, of course, it has GPS and sensor,
which are both offloaded to the PMC's co-processor. Now, of course, power management is also
important in phones, and there the phones need to be able to suspend to save power, and the
firmware from UNISOC has standards suspended implementation through PSCI, which turns off,
which is able to turn off the CPU, when the phone is sleeping, which does save quite some power,
but of course, the drivers for all the other subsystems need to take care of
turning off the clocks and power domains when the phone suspends. Also, frequency scaling
and it helps save power. The proprietary firmware is sometimes quite annoying to deal with,
and I have been thinking about replacing it with some open source alternatives, but that is
a lot of work, and yeah, I didn't get far with that at all. Also, before all these changes
become another downstream mess, you need to send them to the mailing lists so that they are
eventually accepted upstream, and I think I started a bit too late with that, so the process is very
slow and it's better to do this early. Finally, not only the kernel needs to be adapted, but also
user space needs to cooperate with the kernel for power management, but also for basic things like
the modem or the in-camera, which like cameras for the camera, I use this lib camera, I also have
a fork there that isn't upstream, and the communication with the modem is also done in user space.
So, I think I can actually have time to show my phone now.
So, I hope you can see this. It's running a 6.19 kernel with sailfish OS. Sorry, the camera is not focused
properly, so you can't see this in our mind. So, yes, yes, it is, then,
yeah, so the result is that this was a very successful experiment, and mainlining a new
SOC with little upstream support is doable, and it can also be a fun learning experience in my opinion.
So, if we have upstream drivers already, that's great because they seem to work,
even if they need a few changes, where we don't have drivers, there's also the nice opportunity
to create a simple driver, much simpler than what we have in the downstream kernel, because usually
those have a lot of features, but it's nice to start with a basic set of features in a driver
that makes it easier to maintain and understand the downstream code from Unisoc was, well, it depends,
some of it was bad, some of it was better, but I was able to use it as a reference for writing
all these drivers, so it's good we have it at all. Now, after a bit more than a year of work,
it's somewhat usable as a daily driver, and trying to daily drive it, but I still affected by the
Wi-Fi problems. If you invest more time in this, of course, it can probably be done faster,
and it's also nice that SEALFISHOS works without lib hybrids, and many people seem to
think that SEALFISHOS always depends on it, but that's not the case, and yes, so I think in the future,
there is a new phone coming up from Yola, maybe I may in mind that too, it would be a shame if it
doesn't get the same level of support, but also, of course, I need to continue working on this,
the patches should be sent, the patches need to be sent upstream, they will probably still need a few
changes, and maybe you could work on replacing the firmware for Wi-Fi to get it working better,
of course, that requires a lot of time, and for SEALFISHOS, and for other distributions,
I've mostly been working on adapting SEALFISHOS, but for example, to get the mode of
working with, I haven't tried yet to get the mode of working with mode of manager,
yeah, but still it's, we already have SEALFISHOS with the downstream kernel, so SEALFISHOS with the
mainline kernel is a nice thing, it's nice that we can compare them, and maybe someday it will
support the same amount of features and be as reliable, yes, so I hope, I hope this
encourages some people to try mainlining, I really hope so, because it's, it might sound complicated,
but you just start by, as I have shown at the beginning, you start with something simple,
and then you do change after change to add more features, yes, so thanks,
thanks, and are there any questions?
Yes?
Do you have any thoughts about working with SEALFISHOS?
The question is whether I have Android app support working inside the mainline kernel,
I have tried to get it working, the package is officially provided for Android app support,
do not work, but it's possible to get some of it working with, by taking parts from way
joy and combining them with Android app support, and way joy, of course, works too, yes, please.
The question is whether the original kernel source from Unisuck was readily available,
and it didn't take quite some time for the source code for this specific phone to be released,
but for the SOC, the kernel was already available for some Motorola phones with the same SOC, yes,
so it wasn't that hard, yes?
Have you tried to ask other people for help?
I mean, you're not supposed to do everything yourself,
because it has a complete choice about camera support, talking phones, you know, in the last step,
so sounds like if you want to do everything from the SOC class and kernel, you know,
the question was whether I tried to ask anyone for help, I didn't think of it because this phone
doesn't seem to be very popular at all, people keep complaining about it instead of
actually being interested.
Yes. Regarding the open firmware, I've been asked for them to the firmware signing issues,
usually these variables need sign firmware, especially modem, they're in poor blood.
Oh, yes, I have run into those, so the question was, have I run into signing issues with
running the firmware? Yes, I have for the modem for the Wi-Fi, there is no signing, it seems,
and there are some issues here, but fortunately on the C2, I was able to
work around them and thanks to some help. So, yes, those issues will occur, but there is always
some way with UNISOC, especially I don't think their security is that good.
They already have this boot, Rome exploit where you can boot unsigned orders through USB,
and there you can disable the signing.
Any other questions? Yes.
If somebody were to want to do something similar to this with maybe different thought, would you be willing
to get a tip for you, or is there a place that you would recommend them going?
Is there any place I recommend for people who are interested in mainlining other phones?
Or am able to provide help? I can try to provide some help myself, of course, I also have my time
is also limited, and I don't know actually, so there is a large community for other SOCs.
Yes, but, I'd like to get rid of the boot from the one. Sorry?
Plants to get rid of the boot?
I would rather replace the Android boot loader.
Thank you.