WEBVTT 00:00.000 --> 00:15.720 So, hello and welcome to my talk about the Eola C2 and how it's possible to run mobile 00:15.720 --> 00:18.000 Linux on it. 00:18.000 --> 00:20.560 So what is the Eola C2? 00:20.560 --> 00:29.680 It's a smartphone released by Eola in 2024 as a reference device for the salefish OS community. 00:30.680 --> 00:39.280 And it seems to be a community-seemed as a device mainly targeted at developers and it's 00:39.280 --> 00:48.640 nearly identical to a low-end model sold in Turkey with the UNISOP UMS-9230 system on a chip. 00:48.640 --> 00:57.800 Yes, so with salefish OS, you of course have a Linux system on the phone already and it's 00:57.800 --> 01:04.400 quite nice, but as you can see, it runs a relatively old kernel version. 01:04.400 --> 01:16.320 So yeah, it's a typical situation where the SSC manufacturer releases a vendor kernel that 01:16.320 --> 01:24.580 is a park for Android, made to work with the Android hardware support layer that salefish 01:24.580 --> 01:33.520 OS then uses through Lib Hybris, but my idea was since this is supposed to be Linux first 01:33.520 --> 01:42.860 phone, why not run a mainline kernel on it, so I decided to try something new because UNISOP is 01:42.860 --> 01:48.660 not that well known in the mainline in community. 01:49.660 --> 01:52.980 Yeah, so where do you start? 01:52.980 --> 02:02.820 The phone is pretty complicated, but you have the kernel that is responsible for managing 02:02.820 --> 02:10.620 access to the hardware and I had to start by replacing that from scratch and for that 02:10.620 --> 02:19.020 I had to start getting it to boot first, so I had to find a way to make an Android boot 02:19.020 --> 02:29.380 image that would boot my new kernel and that I could flash and then yes, so the Android 02:29.380 --> 02:35.960 boot loader does a few nice things like setting up the display output and setting up the 02:36.040 --> 02:47.920 storage, but unfortunately it also manipulates the device tree it provides the kernel with 02:47.920 --> 02:52.280 and requires a device tree overlay and things like that and since I didn't want to deal 02:52.280 --> 03:01.880 with that I decided to add another layer with an intermediate U-boot boot loader which provides 03:01.880 --> 03:08.880 its own device tree and has some space to implement various initialization steps. 03:08.880 --> 03:18.160 Yeah, but I didn't spend much time on that, I then had to get the kernel working and 03:18.160 --> 03:23.880 there it's useful to see what is happening on the device to tell if it's booting at all. 03:23.880 --> 03:30.160 The devices have a U-art, but that's usually inside the phone, so I didn't want to 03:30.160 --> 03:39.520 just assemble my phone, it's hard with this glued back cover and instead the Android 03:39.520 --> 03:45.440 loader sets up a display output, you can set pixels in memory first and then once drivers 03:45.440 --> 03:54.440 can load, you can load it, you can create a, you can use a frame buffer console, but then 03:54.520 --> 04:03.920 it's so safe, you need to implement everything step by step, so you have a lot of different 04:03.920 --> 04:14.920 components that implement the different communication features access to the peripherals 04:14.920 --> 04:23.120 on the board and usually you start by writing a clock driver that supplies the components 04:23.120 --> 04:30.400 with a clock signal, allows enabling this clock signal. 04:30.400 --> 04:40.400 Then you already have output from the device, but it's nice to get some interactive debugging, 04:40.400 --> 04:48.760 so one of the first drivers I wanted to get working was the USB driver, there I need 04:48.760 --> 04:58.960 to write different registers, write values to different registers in the SOC to set up 04:58.960 --> 05:04.360 the physical layer, and those registers are quite obscure, so in the downstream kernel drivers 05:04.360 --> 05:14.520 from Unisauk, they have names like test or something, but it's relatively short sequence 05:14.520 --> 05:18.720 of registers you need to write to get USB enabled, but then you also need a controller 05:18.720 --> 05:25.960 driver, and that's where it gets messy here, so it's a relatively old controller from 05:25.960 --> 05:37.680 the MUSB family, and even the upstream drivers there are quite old, I got it to work in device 05:37.680 --> 05:44.240 mode, but in host mode it's still sometimes gets stuck with DMA transfer, I don't know 05:44.240 --> 05:52.640 why, and then also the phone reboots at some point after rebooting the kernel because there's 05:52.640 --> 05:59.280 a watchdog that's supposed to prevent the kernel from hanging, usually you fix that by adding 05:59.280 --> 06:06.720 a driver for the watchdog to periodically tell that the kernel isn't hanging, but here 06:06.720 --> 06:13.320 this didn't seem to have any effect at first, and I'll get back to that later, so you 06:13.400 --> 06:19.360 can start already contributed a lot of, oh, not a lot, but some drivers to the upstream 06:19.360 --> 06:26.840 kernel, and I could use a lot of them directly, so I'll just briefly mention the components 06:26.840 --> 06:37.840 that were just needed a few changes to bring up, so the display driver needed some bug fixes 06:37.840 --> 06:50.120 and it only supported an older SOC, then we have the regulator driver, there was a regulator 06:50.120 --> 06:57.720 driver, the regulators are on the PMIC, not on the SOC, so you need a PMIC driver, which already 06:57.720 --> 07:04.840 existed, and the regulators were implemented for an older SOC, the downstream driver was 07:04.840 --> 07:13.120 extremely similar, so merging the upstream and downstream was relatively easy there, then 07:13.120 --> 07:23.960 to access storage, there was the host controller driver worked with UFS, there was another 07:23.960 --> 07:34.400 case where you need to set up physical layer with another obscure register sequence, but 07:34.400 --> 07:43.160 other things were much simpler like GPIO and post-width modulated outputs, a lot of other 07:43.160 --> 07:56.360 things in the PMIC too, so battery management driver wasn't very complete, but other drivers 07:56.360 --> 08:05.160 were already there, not all the downstream Android drivers, for example, for the UFSBPD protocol 08:05.160 --> 08:19.560 still, they weren't sent upstream, but then also the I2C and so on the standard buses for communicating 08:19.560 --> 08:37.360 with on-board peripherals, like the touchscreen, yes, so now it's time, I want to show a video 08:37.360 --> 09:02.280 where the kernel just boots with a simple frame buffer and a storage driver, so I can skip 09:02.280 --> 09:19.280 this part, the bootloader loads the kernel and then it can boot to a login prompt, but 09:19.280 --> 09:39.920 you can do much else at that point, so now we get to the interesting part, yes, now 09:39.920 --> 09:47.840 besides all these simple peripherals, the SOC also contains entire processors dedicated to 09:47.840 --> 09:58.800 implementing communication features, and after getting a power domain driver to bring them up, 09:58.800 --> 10:11.040 to power them up, you have to write drivers that load the firmware into memory and start them, 10:11.040 --> 10:16.560 the firmware is unfortunately proprietary, but I was able to boot them with the firmware 10:16.560 --> 10:27.680 taken from Android or from self-ishores in this case, because it's the same, and then you have 10:27.680 --> 10:37.360 to communicate with them somehow, and here in the SOC shows a shared memory approach where the main CPU 10:37.360 --> 10:48.600 is established is a ring buffer channel with each of these endpoints, and I had to write a driver 10:48.600 --> 10:55.720 for that in the RPMSG subsystem in Linux, which is quite different from what Unisucked and 10:55.720 --> 11:03.240 downstream. One of these processors is worth noting, because it does some seemingly random 11:03.320 --> 11:10.200 system-related tasks, and it also manages the watchdog, which is why my phone rebooted, so I 11:10.200 --> 11:21.320 had to first load up this processor and tell it to manage the watchdog, and that was required 11:21.320 --> 11:27.960 to get the other watchdog for the CPU to function properly. Bluetooth was relatively easy to implement, 11:27.960 --> 11:36.240 because that has a standard serial protocol, that I could just use over this channel, and 11:36.240 --> 11:43.120 that worked almost right away. Wi-Fi was much harder, and it started implementing a new 11:43.120 --> 11:51.560 driver for that, and it can connect to network, and then it sometimes stops dropping frames, 11:51.640 --> 12:03.000 and sometimes it works. Yeah, then it's a phone, so you want to be able to use it as a phone, 12:03.000 --> 12:13.880 and for that, you need to have sound, and you need to also want to take pictures, so for the sound, 12:13.960 --> 12:26.680 the audio goes through a DSP, and you need to tell the DSP to start a stream. You also need drivers 12:26.760 --> 12:42.360 for the PMIC analog audio codec, and for the PMIC SSC link, yeah, those didn't exist yet, 12:42.360 --> 12:51.880 so I actually wrote those drivers. And for the camera, I was able to write 12:52.520 --> 13:01.560 drivers not only for the camera sensor interface, but also for the image processing pipeline, 13:01.560 --> 13:08.920 because UNISOC has open source downstream drivers that actually have a list of all the registers 13:08.920 --> 13:19.480 in the ISP, and you can, yeah, so it's actually quite straightforward to write the configuration 13:19.560 --> 13:26.840 to the registers, then you set a buffer address, and you need to trigger it to start processing 13:26.840 --> 13:36.360 frames, so the challenge there was getting that integrated with the Linux V4L subsystem. Of course, 13:36.360 --> 13:42.200 yeah, there are parts that are proprietary, where we don't have the advantage of this 13:42.200 --> 13:49.160 register list, like for the hardware JPEG and video encoding blocks, which is unfortunate, and they haven't 13:49.240 --> 13:59.160 looked into implementing those yet. The SSC can do more, of course, it has GPS and sensor, 13:59.160 --> 14:10.680 which are both offloaded to the PMC's co-processor. Now, of course, power management is also 14:10.680 --> 14:25.960 important in phones, and there the phones need to be able to suspend to save power, and the 14:25.960 --> 14:34.840 firmware from UNISOC has standards suspended implementation through PSCI, which turns off, 14:34.920 --> 14:43.560 which is able to turn off the CPU, when the phone is sleeping, which does save quite some power, 14:45.160 --> 14:49.400 but of course, the drivers for all the other subsystems need to take care of 14:50.600 --> 14:57.320 turning off the clocks and power domains when the phone suspends. Also, frequency scaling 14:57.400 --> 15:06.200 and it helps save power. The proprietary firmware is sometimes quite annoying to deal with, 15:07.320 --> 15:14.200 and I have been thinking about replacing it with some open source alternatives, but that is 15:14.760 --> 15:24.120 a lot of work, and yeah, I didn't get far with that at all. Also, before all these changes 15:24.120 --> 15:32.120 become another downstream mess, you need to send them to the mailing lists so that they are 15:32.120 --> 15:40.520 eventually accepted upstream, and I think I started a bit too late with that, so the process is very 15:40.520 --> 15:50.920 slow and it's better to do this early. Finally, not only the kernel needs to be adapted, but also 15:51.000 --> 15:59.080 user space needs to cooperate with the kernel for power management, but also for basic things like 15:59.080 --> 16:08.920 the modem or the in-camera, which like cameras for the camera, I use this lib camera, I also have 16:08.920 --> 16:18.680 a fork there that isn't upstream, and the communication with the modem is also done in user space. 16:20.920 --> 16:27.880 So, I think I can actually have time to show my phone now. 16:50.920 --> 17:19.800 So, I hope you can see this. It's running a 6.19 kernel with sailfish OS. Sorry, the camera is not focused 17:19.800 --> 17:39.640 properly, so you can't see this in our mind. So, yes, yes, it is, then, 17:39.640 --> 17:56.680 yeah, so the result is that this was a very successful experiment, and mainlining a new 17:56.680 --> 18:05.720 SOC with little upstream support is doable, and it can also be a fun learning experience in my opinion. 18:07.720 --> 18:17.160 So, if we have upstream drivers already, that's great because they seem to work, 18:18.040 --> 18:28.200 even if they need a few changes, where we don't have drivers, there's also the nice opportunity 18:28.200 --> 18:34.920 to create a simple driver, much simpler than what we have in the downstream kernel, because usually 18:36.360 --> 18:42.600 those have a lot of features, but it's nice to start with a basic set of features in a driver 18:43.240 --> 18:56.680 that makes it easier to maintain and understand the downstream code from Unisoc was, well, it depends, 18:56.680 --> 19:02.920 some of it was bad, some of it was better, but I was able to use it as a reference for writing 19:03.000 --> 19:13.320 all these drivers, so it's good we have it at all. Now, after a bit more than a year of work, 19:13.320 --> 19:22.120 it's somewhat usable as a daily driver, and trying to daily drive it, but I still affected by the 19:22.200 --> 19:30.280 Wi-Fi problems. If you invest more time in this, of course, it can probably be done faster, 19:32.440 --> 19:39.480 and it's also nice that SEALFISHOS works without lib hybrids, and many people seem to 19:39.480 --> 19:50.440 think that SEALFISHOS always depends on it, but that's not the case, and yes, so I think in the future, 19:51.400 --> 19:59.480 there is a new phone coming up from Yola, maybe I may in mind that too, it would be a shame if it 19:59.480 --> 20:05.400 doesn't get the same level of support, but also, of course, I need to continue working on this, 20:07.000 --> 20:15.320 the patches should be sent, the patches need to be sent upstream, they will probably still need a few 20:15.320 --> 20:26.920 changes, and maybe you could work on replacing the firmware for Wi-Fi to get it working better, 20:28.360 --> 20:38.920 of course, that requires a lot of time, and for SEALFISHOS, and for other distributions, 20:38.920 --> 20:44.760 I've mostly been working on adapting SEALFISHOS, but for example, to get the mode of 20:44.760 --> 20:49.880 working with, I haven't tried yet to get the mode of working with mode of manager, 20:52.440 --> 21:02.760 yeah, but still it's, we already have SEALFISHOS with the downstream kernel, so SEALFISHOS with the 21:02.760 --> 21:12.680 mainline kernel is a nice thing, it's nice that we can compare them, and maybe someday it will 21:13.640 --> 21:27.320 support the same amount of features and be as reliable, yes, so I hope, I hope this 21:28.280 --> 21:39.240 encourages some people to try mainlining, I really hope so, because it's, it might sound complicated, 21:39.240 --> 21:48.120 but you just start by, as I have shown at the beginning, you start with something simple, 21:48.120 --> 21:57.080 and then you do change after change to add more features, yes, so thanks, 21:57.160 --> 22:02.120 thanks, and are there any questions? 22:14.360 --> 22:14.600 Yes? 22:14.600 --> 22:18.360 Do you have any thoughts about working with SEALFISHOS? 22:18.360 --> 22:23.160 The question is whether I have Android app support working inside the mainline kernel, 22:24.040 --> 22:33.880 I have tried to get it working, the package is officially provided for Android app support, 22:33.880 --> 22:43.960 do not work, but it's possible to get some of it working with, by taking parts from way 22:43.960 --> 22:57.560 joy and combining them with Android app support, and way joy, of course, works too, yes, please. 23:05.560 --> 23:11.080 The question is whether the original kernel source from Unisuck was readily available, 23:12.040 --> 23:18.520 and it didn't take quite some time for the source code for this specific phone to be released, 23:18.520 --> 23:28.040 but for the SOC, the kernel was already available for some Motorola phones with the same SOC, yes, 23:28.040 --> 23:32.360 so it wasn't that hard, yes? 23:32.760 --> 23:34.520 Have you tried to ask other people for help? 23:34.520 --> 23:37.160 I mean, you're not supposed to do everything yourself, 23:37.160 --> 23:42.600 because it has a complete choice about camera support, talking phones, you know, in the last step, 23:42.600 --> 23:49.800 so sounds like if you want to do everything from the SOC class and kernel, you know, 23:49.800 --> 24:00.600 the question was whether I tried to ask anyone for help, I didn't think of it because this phone 24:00.680 --> 24:07.320 doesn't seem to be very popular at all, people keep complaining about it instead of 24:08.120 --> 24:11.960 actually being interested. 24:21.160 --> 24:26.040 Yes. Regarding the open firmware, I've been asked for them to the firmware signing issues, 24:26.920 --> 24:30.680 usually these variables need sign firmware, especially modem, they're in poor blood. 24:32.680 --> 24:41.480 Oh, yes, I have run into those, so the question was, have I run into signing issues with 24:41.480 --> 24:49.160 running the firmware? Yes, I have for the modem for the Wi-Fi, there is no signing, it seems, 24:50.120 --> 24:56.440 and there are some issues here, but fortunately on the C2, I was able to 24:58.120 --> 25:09.320 work around them and thanks to some help. So, yes, those issues will occur, but there is always 25:09.320 --> 25:14.360 some way with UNISOC, especially I don't think their security is that good. 25:15.160 --> 25:24.040 They already have this boot, Rome exploit where you can boot unsigned orders through USB, 25:24.840 --> 25:26.440 and there you can disable the signing. 25:36.760 --> 25:38.200 Any other questions? Yes. 25:39.160 --> 25:46.360 If somebody were to want to do something similar to this with maybe different thought, would you be willing 25:46.360 --> 25:51.720 to get a tip for you, or is there a place that you would recommend them going? 25:55.800 --> 26:06.120 Is there any place I recommend for people who are interested in mainlining other phones? 26:08.200 --> 26:20.280 Or am able to provide help? I can try to provide some help myself, of course, I also have my time 26:20.280 --> 26:32.120 is also limited, and I don't know actually, so there is a large community for other SOCs. 26:32.120 --> 26:42.120 Yes, but, I'd like to get rid of the boot from the one. Sorry? 26:46.120 --> 26:48.120 Plants to get rid of the boot? 26:48.120 --> 26:56.120 I would rather replace the Android boot loader. 27:02.120 --> 27:04.120 Thank you.