 So, hello and welcome to Media Tech Upstreaming from Ringup to Task Coverage. I'm Angelo Joaquino del Regno, but please call me Angelo. I'm a software engineer working for Collabra, and I've always been working on Qualcomm SOCs. Hey! Then, well, I started going with Chromebooks and Media Tech SOCs. Yes, Media Tech really. This is because, apparently, there's not a huge community around Media Tech, despite, well, in comparison to the Qualcomm community, at least, and it's for some reason not really well known. So, let's start with some background around Media Tech. So, it started with OpenWRT people, Upstreaming Rallying SOCs, which were MIPS architecture, that Media Tech acquired Rallying in 2011, and, as you know, MIPS is dead, so now it's all ARM and ARM64. That's the same for Reuters, now. And then, shifting a bit forward, yes, a wide laptop appears, and these are Chromebooks. With the first Media Tech Chromebook being released in year 2016 with a pretty old SOC, it got fully, almost fully upstreamed by more or less year 2020. And things have improved quite a lot with a current Media Tech Chromebook, which got released in 2022, so really recently, and right now it's upstreamed. It just misses some external display support on literally nothing else. Yes, Media Tech devices are literally everywhere. It's easy that you probably have some Media Tech smartphone somewhere in some drawer, with probably some Chinese Alchipo device, you know. These are really, really common, which are basically the same device, but in a different shell, but it's ultimately the same board. So maybe all of you have the same device. Regarding Media Tech and upstream, there is a really small community around it, as I said before, because the vast majority is on Qualcomm. It would be really nice if we would see more people on Media Tech smartphones trying to upstream them, because that would enrich the Linux kernel and the ARM and M64 support beyond just basically the usual SoC manufacturer. Because then, yeah, there is a myth for some reason for which Media Tech SoCs would be slow. That's not the case at all. If you look at the latest Dimensity chip, that's beating the Snapdragon Gen2, so, you know. So let's go for some real action. We'll start light with some hardware tools for both bringing up Chromebooks and smartphones. You obviously need a power supply unless you have something that doesn't require power. I don't. That's important for taking care of your battery other than actually powering on your board. That may look obvious, but if you choose the wrong one, you will encounter countless issues. I'm getting to something more interesting. Yes, you need to, of course, find a UART or some way to actually check the kernel logs, because that's obviously... Your only way to actually know what's going on. And at least for Chromebooks, there's a Susie cable that is a Type C to Type A, or whatever, that will expose three UARTs so that you can actually check logs from the embedded controller and the AP, in this case, the Media Tech SoC, run in Linux. Unfortunately, there have been some shortage issues for this kind of cable. But no fear, because even debugging tools could be an open source. Thanks, Google. You can actually make your own. You just need a Breakout Type C, a Type C Breakout Board and some resistors. Basically, that's it. You may require some soldering abilities, but you can even breadboard one even if I don't really recommend doing that, but that's possible, anyway. And regarding smartphones. Yeah, I had to actually solder and, well, find and solder tiny, tiny wires to actually find that UART port. That's from a smartphone that I have recently upstreamed, featuring a Media Tech Helio X10 SoC. You don't really require actually soldering skills even for that, because you can easily poke at the pins. It's uncomfortable, but you can do it. It looks scary, but once you actually pop off that cover, it's not that bad. You just navigate through it and you'll eventually find it. It's anyway a 1.8 volt signal, so it's easy to find. And let's go for some software tools. In the case of Chromebooks, you have a reference downstream kernel source code that is usually not too old. It always includes Git's history, and this means that you can actually see what's going on. It's publicly browsable at Google's Repus. And in case you, unfortunately, do something that is really, really bad, you can recover the Chromebook. That is a Chromebook recovery utility that only, unfortunately, only runs on Windows and Mac. That is a Chrome extension. But if you are a developer, probably you don't really need automated tools, so you can go on your own on Linux. There's Chrome in Dash from which you can download your recovery image, and you will have to DD it on a SD card or any kind of external USB mass storage device. And it's as easy as inserting your USB mass storage into the Chromebook and start the recovery process. It just goes on its own. As for smartphones, the story changes a bit, where your reference kernel source code is really old. If you can even find it, it rarely includes Git's history because it's a copy left turbo drop. Of course, if there's no Git, it's not browsable. So you will have to download a gigabyte of stuff to check on 10K, but developers live. As for recovery, that's also a bit harder because very, very old phones don't really have fast boot, at least on MediaTek. Then it will start it actually, reinforcing that so everyone has fast boot. But in case you will have to find a recovery image which has not granted you, it's not like you go to the OEMs website and download one. That's not how it happens. So good luck finding one. You can find something, I won't tell you how, but you can imagine. You can find it in shady places. Let's go for development tools. Obviously, you need your hands, of course, a text editor across tool chain unless you are building ARM64 for ARM64, on ARM64, and allow the patients, not just because you have to wait for that thing to actually build, but because of the many issues that you will have later. And then yes, you should never underestimate, like I did, some scripts and commodities that will help you through your development journey because we all want to just go there, implement our thing and just see it working. That's not really how it works. That will actually make you lose a lot of time. If you care about building your development environment and making you comfortable in that, that will save you a lot of time. Let's check some. For Android, of course, it expects a custom boot IMG. I'm saying nothing new, probably, but it's a bit, you know, not really straightforward as coping a kernel binary and booting it. You need to know some parameters from your bootloader because it expects the kernel to be at a certain memory address to actually jump to it. So you can easily find these parameters by disassembling, actually, not decompiling, but you can read these parameters from your device by pulling the boot IMG for your device. And then for, well, Chromebooks, yes, but basically everything, actually, it's not really only related to Chromebooks. We have some scripts at Calabra that are public and open source and they will always be public and open source. The advantage is that everything would be in one folder. There's no system-wide install required whatsoever. It will automatically download your tool chain, set it up, manage any kernel configuration fragments that you don't want to be into the kernel tree. And yes, it also helps you to verify the code and bindings built. And if you let me use that word flash, on an external storage device for easy booting, this would also work with smartphones, actually. These scripts are available at the Calabra Guild Lab and you're free to use them, contribute, do whatever you want. And yes, I'm saying something obvious here, maybe, but there are some people that really don't use check patch. They forget about it for whatever reason before sending a patch upstream. A good way would be to actually automate it. It may be annoying sometimes while developing, but if you automate it and get past that annoyance, that will guarantee that you have run check patch. So please do get into something more serious. There are times in which you're trying to optimize code size while developing your driver or doing perhaps a huge restructuring of something, of some driver in the kernel. There's the bloatometer, which helped me a lot in actually performing a big restructuring that I've done for media tech locks. And it's actually easy to use. You just build the kernel with, of course, all your drivers, save the old binaries that were compiled, make your changes, build again, use the bloatometer, which will compare the actual binary size between the old one and the new one, so that you will know if you are just reducing the code size or the actual binary size. Because smaller is not always better. It's not granted that if you have less lines of code, the binary is smaller. That's totally not granted. And smash, smash has helped me a lot. That's the lifesaver of the tarry engineer. When you actually make some stupid mistakes, it happens to everyone. There are some tools like smash and with static analysis, you can actually avoid a lot of stupidities. But now let's actually bring it up. So, of course, you want some serial. As I said before, you want a pin control driver because you have to switch those pins to actually be a your port. You maybe need some clocks and obviously a device tree. If you wanna go to certain lengths, then you can also get out of the early bring up with some regulators support, and that would be required for EMMC and SD, and of course for the display. So let's check something about the UART on MediaTek. Well, as you can see, the downstream device tree node is a little unusual, maybe. You don't really have to have support in Linux for your UART IP because if the bootloader leaves it open before booting Linux, which is most of the times the case, you just need to know where to raw write your random characters, which would be your kernel log in that case. That would be slow, but effective, I would say, because that would be anyway the only way to get knowledge of what's going on in early bring up. So why not? Let's get on with pin control. That's a bit of pain and suffering because on older kernels, that's like you find the code but it's apparently random. It's not really pleasant, but if you get your grep skills going, then you will actually find everything that you need to actually bring up, to actually write a driver for upstream because the information, even though it doesn't appear to be all there, it is all there, it just takes some time to actually find it. Luckily, if you get something that is more modern with a downstream media tech kernel that is more or less 318 or something newer, that's basically a 60 minutes of work because it's basically the same as upstream. You, of course, need to fix this and that, but the format is the same, so. And of course, you can see an example of downstream, up and downstream, oh, sorry. I have upstream down and downstream up. You can feel the pain, that's a 3.10 kernel, by the way. Same for the clocks. It's still the same pain and suffering, and it's still the same 60 minutes of work for 318 on words, but again, the information is always there. People are always scared about finding that information on old kernels. They often think that the information is not there, but it is there. You can find it and you can literally, if you get smart enough in navigating that downstream stuff, you can actually write an upstream driver in no time. And the device tree, the device tree downstream is your primary source of information. It contains something that is really odd compared to the upstream ones because you can find basically the entire ios-based layout in one node many times. So that's really convenient and I mean, you will just have to translate this and that to upstream language and well, making it proper, actually. And that's about it. If you wanna go to different lines, it's always the same pain and suffering when you are looking at old kernels for MediaTek also because the code is also a bit subpar honestly. And it's again, always the same for 318 on words where MediaTek actually started to use the upstream drivers in their downstream kernels. So that's way more convenient. Of course, if you want EMMC as the support to actually make your platform useful upstream, you will need some regulators which may be scary, but I mean, if you take the right precautions, take your time, you're not gonna release that green smoke. This is especially required for EMMC where you have this voltage signaling switch from 3.3 volts to 1.8 volts for the HS mode, high speed modes. And I can give you one recommendation which for some may be obvious, but no optimizations yet. There are too many people trying to just do everything in one shot, everything just perfect, just spot on. That's not how it works. First, you have to get it working. It can be dirty. That's a thing, but it's better if you get something that is actually working than actually getting failures fast. So first do it, then you clean it up. It's fine. And well, besides, even if on trading, the media tech actually uses upstream drivers basically, it's never really just a copy-paste job anyway because the code is always a bit dirty, you know, but it's probably easier to read. That's a plus. Test coverage, test coverage has helped me a lot. And it's way more important than you think. So there's the kernel test robot that everyone has encountered in their lives, I'm sure. That's actually complaining because you are testing your code on ARM64 if you're compiling your code, sorry, for ARM64 if you're developing for ARM64, you don't really care about Spark or x86 or other architectures. But the test robot does. And kernel CI, which monitors Linux stable, Linux next and also more, monitors the collaborators media tech integration kernel, which is always upstream like kernel we will talk about it later. And it does test on the real hardware. So the zero day, it's obviously here to help you. It's not something that, well, if you receive that email, it doesn't mean that your patch doesn't get accepted. It means that you have to fix something, but just don't be scared, just look at what's going on, fix it briefly. For kernel CI, which is, in my opinion, a bit more interesting, this is catching issues dynamically, meaning that on this match and the others, yeah, you're doing a lot of static analysis and preventing certain stupid mistakes, but kernel CI actually tests on the real hardware. It tests on multiple devices and multiple SOCs. So you're sure that you're not causing any regression and if anything happens, because it will happen, it also out of bisects. It's not 100% smart, but it will reduce your time bashing your head on what went wrong by at least 50%, at minimum 50%. And regarding the collaborative media tech integration kernel, that's mostly feature complete kernel that is always based on Linux next, so that's gonna be the stay blessed of them all, right? And yeah, we are of course testing that on kernel CI, so we test all the pieces together on the real hardware and of course, well, we're not just testing it on kernel CI, I'm also testing it personally with my own hands on my own Chromebooks. This is a development kernel, so it's always updated and it's open to everyone, so if anyone wants to use this kernel, you can find it on our GitLab. You're free to use it, you're free to contribute in case you want, it's up to you. That's in case you wanna port any media tech SOC, any media tech platform, any new media tech platform upstream, you will probably find nice goodies in this integration branch, which will help you out quite a bit in some cases. And that's about it, thank you for being here. If there's any questions, please. I have two questions, one of them, the media tech X29 support, how does that look? Do you know? The X29 is for smartphones, right? That's correct, yeah, so it should be your domain, I guess. There is some support for the X29, but that's because of the legacy that we have in the kernel, so it's not directly supported but it's gonna be relatively easy to add it. And the other question is GPU support on these devices, these mobile devices, how does that look? Well, I've been upstreaming one, that is the MT6795, quite recently, currently upstream, I'm waiting for some series to get picked. But on my tree, I have basically everything working. The only thing that is not working is the modem because I didn't have time to look into it. And what else? Oh, the battery charging, that's quite important, I understand that. There's a huge discussion that we can do about battery charging. And well, that's one of the devices that require Linux to manage any and every aspect of the battery charging, so you can imagine that's not really comfortable to ride a driver for that. So the GPU actually works on these devices. Is that the Mali GPU or is there something else? The 6795, that's PowerVR, but all the Chromebooks, apart from the MT8173, so MT8183, MT81295, they are all on Mali GPUs. The last one that is 8155 is on Valhalla architecture. And yes, that works fine. Cool, thanks. Oh, Pamfrost, that is. Thanks for your talk. So you mentioned that you have access to some code drops from MediaTek and vendors, where they have their reference source code. I think this has been a long time issue with MediaTek that they didn't respect the GPL. Now we're seeing that since they started working with Google, they are improving on that. Can you comment on whether they now release publicly code SDKs for new platforms? Do they do it for? You can find MediaTek's code around. For Chromebooks, you can find them on the Google Kit, so that was obvious, but they're becoming more and more open. They're not really breaking the GPL as they were doing before, which was poor. You can probably find easily some MediaTek kernels for smartphones on GitHub. They don't have something like Qualcomm. Right, yeah, so is it like people who happen to find it and release it, or is it actually the vendors? No, it's the vendors. Okay, all right. It's the vendors. There's at least Xiaomi that I know that actually releases the kernels with Git history on GitHub. They sometimes miss some device, but it's slow, but it gets there anyway. Okay, I have a second question, if I may, which is about secure and, well, signed boots, essentially. So MediaTek SOCs have also been known for shipping with Fuses enabled that don't allow you to install your own bootloader. So you have to use something pre-signed with their keys, which is non-free, so this has been also a huge issue in general for free software. I know that the SOCs that Google use are not signed. They don't have this problem. Do you have any idea if MediaTek is now selling these kind of non-signed chips in the wild if they have development boards with those versions of the chips, or what's the general situation about that? There are some IoT boards from MediaTek. Obtaining them can be done by the regular consumer. You don't have to be a big industry. It's not really straightforward, but that's for SOMs and such, it's never been really that much straightforward, unless it's a Raspberry Pi anyway. But yes, these kind of boards are accepting unsigned code, so there's a lot of freedom in case you wanna use one of those boards. All right, friends, thank you. Hey, I just wanna do a plug for a tool called Patman, which will send your patches and check them and so on. I'm surprised how few people have heard of it. Anyway, do you know what bootloader they're using on the phones, and have you got involved in that side of things, or is it simply just reusing whatever's there? No, I have never been involved in the early bootchain for smartphones. I've made my own research, and from what I have understood, they are using LK, little kernel, that's a very old bootloader, at least on old platforms. I really don't know if they are using any kind of UEFI, uh, EFI, sorry, newer smartphones like Qualcomm does. I literally have no idea, but I'm sure that both from the firmware perspective and the actual bootloader, the smartphones and Chromebooks do differ. Though, I can tell you that the evaluation boards and the SOMs and demo boards and SBCs that are obtainable from Editec, they use the same bootloaders and the same bootchain as the Android smartphones. Thank you. Sure, when nobody asks questions, that means that you have been exhausted, right? It also means it's nearly lunchtime. Yeah. Okay, so thank you much. That was a fantastic talk. Learned a lot more about Editec than I ever knew before, so thank you very much. Thanks. Thank you.