 Hey, my name is Craig. This is the first time I've been to Osmond DevCon. I want to thank you all for having me here, and I've learned a ton of things from everybody, so I really appreciate that. So I'm going to talk about porting Osmond CommBb to media tech chips. I've been working on it for a couple of years, maybe, maybe a year. So about eight or so years ago, I started working with Osmond CommBb on the Motorola phones. I was just trying to make myself a phone that I enjoyed more, that was open. I wanted to know what was inside of it and try to make a phone that was less distracting, so not all the screen and Android and whatever else. So just some background on things I've done over the past eight years. I've messed around a lot with Android, and pulling Zygote out, so that's the Java UI and just stop that process, and then do devion change route and some terminal stuff and CLI tools. I did it on this Moto Active watch and Geeks phone key on, and then I also messed around for a while trying to pull layer one into NuttX, which is something some other people worked on too, NuttXBB. Didn't really make a whole lot of progress there, but in that currently the thing I was working on mostly, besides this are post-market OS, so just trying to make like a frame buffer console with some other things. I wrote a gesture recognition thing, kind of like palm pilot graffiti to work on that. That's just kind of background of the stuff that I've done. So the target devices for what I'm working on. The first one is the Siphon Dream G2, which has 6235 chip inside of it that previous people have developed U-boot that you can load into it. There's Osmocon or in Osmocon BB can interact with a boot ROM protocol that's available on most MediaTek chips. So you can do things like read, write memory, load a big chunk in a memory, as well as jump to an address in memory. So that's how they kind of formulated a way to load things into RAM and run them, and that's how they run U-boot. There was some code for just that loader in Media in Osmocon BB for that phone. Fernvale is a project by Bunny Kwan and Sean Cross. They developed open hardware platform that includes MediaTek 6262 chip. They spent some time reversing. It uses the same boot ROM protocol, so you can load code into it and run it. There's a little project called Fernvale that interacts with a little program that they load to let you experiment with reading and writing and manipulating like a screen and things like that. There's also lots of CIM 800 modules that have 6260 or 6261, and they're just barely different. I have many watch phones that have 6261 inside them. My personal phone has a 6735 in it, which I don't really have direct source for, but some corollary source for it. It's 4GLTE, and then there's this newer Orange Pi 4G IoT, which has almost the same chip as this thing. It's also 4GLTE, and then there's some other leaked sources and stuff. I'll get to that in a second. So those are the target devices. My hope is to get stuff working on the Siphon Dream G2 since there's a data sheet that's rather complete. I don't know of any other data sheets that are complete for the other ships. Then from there, move on to Fernvale and CIM 800. CIM 800, you can buy that like five to 10 bucks on eBay. So I think it'd be a really great platform for people to keep working on getting layer one, working on it and different experiments that people want to do. This is my fancy org mode presentation. Okay, so what I've done so far. So I've poked around on lots of different MediaTek devices with a brawn protocol. I can interact with this phone and pull out of memory where it keeps its config registers, and it tells me that it's got this 6735 chip, and I've got this simple Python script that I've searched around on different devices to find that config block in memory. Because it starts with the chip. So that's this simple serial script that I wrote, part of somebody else's project, MTK Open Tools. So I did that. Actually, okay. So the other thing I've done is I've, so Fernley has support for the serial. UART, actually it's serial over USB device in 6260, and I took some of that code and a little bit of like a Blinky Lite code that they had, and put that into firmware for Osmocom, and maybe I'll just show that real quick maybe. So it's funny because I was describing some of these things and then Powell had all these questions about like, how does it work, so let's see, I'll go in their screen and better make it bigger. Is that big enough? Maybe make it bigger, so. Okay, that's probably big enough. All right, so I'll have the common source. Not that one. I want to go into Fernley. So here's, this is Fernley, and so this is the host program. It tells it to wait for the serial device to come up. This is the serial device. It's a USB serial device. This is an initial firmware that gets loaded inside the device that then lets them interact with it, kind of like our Osmolode stuff. Then the second one is a little bit more extensive firmware. You can just run that one by itself, and then it just automatically connects right here on the host, and then you can just type in read-write and different things like test the screen or detect button pushes and things like that. Then you can also specify a third arg that's another firmware to load then after that, and you can see here I've got some firmware compiled for the 6260. It says Layer 1. It's not Layer 1. Not hardly. Yeah, it wants to, yeah. So then, see if I can get this to work. Huh? Oh no. Of course. Let's see if it's there or not. Let's see. Ford, Fernvale. It's there. So what was this a deal? Demo, God's, be nice. Cat, cat, cat, cat. Yeah, should be good. Oh, okay. I think I know what the deal is. So, I'll just do this real quick. There we go. Okay, that's probably the deal. Hopefully. Yeah, okay. Try this again. Yeah, okay, great. So, you can see that I'm sending out 1s and 0s from the firmware, and it's Blinky Light. I added in this too, which reads out the chip number out of the config block. So, yeah, if you notice, this is not any one of the, what is it, eight different training sequences. Yeah, right. I don't know. That's a good question. I did actually observe, I was trying to print out a whole bunch of debugging information via serial when I was trying to bring up the RF system, and it seemed like the things were out of order. So, maybe there's some problem there somewhere. I'm not sure. Oh, yeah. So, how do you make it load your custom firmware? How do you interrupt regular booting process? Right, yeah, I think a diagram of this would be pretty nice. So, there's a boot ROM, and it's like a first-stage bootloader. If you interact with the UART port in a certain way with some magic numbers, it initiates this protocol, and then you can read and write memory and jump to an address. So, it just writes a block of firmware into the RAM and then jumps to it. So. So, it's something similar to what we have with Calypso phones. Absolutely. You have to briefly press this red button and okay. Absolutely, yeah, yeah. Okay, so that's one thing I've done. Another thing I've done is taken the code that's in U-boot. So, in the U-boot code that they made for the Siphon Dream G2, there was a TX burst kind of demo command that you could run, and there was little bits of some support for the transceiver chips in Osmocom already that they copied and put in there and added to, and then I took that and pulled it back into Osmocom. So, now we have more header files and things like that in my branch for the MT6235. So, I got that TX burst thing working back on the in Osmocom firmware on the Siphon Dream G2, and today actually Piotr helped me understand that all that does right now is it has the like the ARM core controls the transceiver and just turns it on to transmit. There's no DSP that's generating any kind of data yet. So, that's the next thing I would probably work on there. And then try to do another demo. Hopefully, there's not too many demos. I mean, I figured demos are good, right? Let's see. So here, I'm gonna run this loader, which is gonna load onto this Siphon Dream G2 I have here. It's kind of picky, so it doesn't always, it's not always nice, but hopefully it'll work. Ah! Okay, that was just the antenna, good. There we go. I can reconnect the antenna. I have to hold the button down on this device in order to get it to load all the firmware. Okay, so now it's loaded. Can reconnect the antenna that I have, which actually disables the antenna on the device. And then I can interact with the device. So, yeah, you can see here, I got received a Pong, so I just ping Pong. And then I added the TXBurst as a command for the MTK loader, just because it was the easiest way to get it in there. And actually, I need to start the other bit here, this one. Okay, so here, I've got my SDR connected up with a couple of tenuators, and I should be able to do a transmit. And so if I change the AirCN, you can see that it's going along in little chunks and it's something. And that's something that, I really just copied the code from you back into Osmocom, but I mean, I've been spending most of my time after I got this done trying to understand every little bit of code, so, yeah. Okay, so there's another demo, that's that one. All right, so let's go back to here. So there's that bit. And what's that? Oh, well, it's, yeah, it's all kind of contained, right? It's not on the air, it's, I had to go find this fancy connector somewhere that plugs in, so it turns off the antenna. Yeah, right, yeah, thank you. I was very concerned about that when I came here. I got like a year or so ago, I got my ham radio technician class license because in America, there's a 900 meter band that's open for technician class license. Obviously not open for the kind of transmissions, but I thought I'd get a little bit legal. Yeah, right, there you go, fairly legal. Okay, so, yeah, so the next thing I've been working on a lot, actually a while ago I made a, there's, oh, okay, I should probably show this first. This is kind of a collection of all the leaked sources that I know about. So all those are either 6260 or 61. And then there's also this one here, which is for 6795, it's quite a bit newer. It's got things that look like baseband firmware for LTE. So it also has some things that look like they interact with the transceiver that they use with that, which is this MT-61-69. So theoretically, if I can get enough information and it's similar enough, I could maybe do that same TX burst with the much newer chips. Okay, so that's, I don't wanna go back up here. Yeah, so a little while back, I took one of those leaked sources and I made a little make file that I can define different chips. I include a whole bunch of stuff that I figured out. And so a few more ifs in here and there. And this allows me to not build anything that I can run, but I use save temps here and that lets me, there's a lot of if-defs all over the place, tons. And so it was really hard to follow the code. So I did this to kind of follow the code so I could look for the function I'm looking for, see what other functions it calls, try to figure out what addresses it was using for registers and whatnot. So that was one strategy I used to try to figure things out. I did recently start to use this Gehidra provided by the NSA so that I can reverse engineer. I don't know, this is my first entry into reverse engineering, so I know that I should be using IDA Pro, but I don't have that. I've tried that a little bit and it should be good for me because I actually use ED to do most of my editing. So it's similarly obscure. But so, and actually I guess I was looking at some other stuff here. I found this function called, okay so to explain this, one of the resources has a .elf file that's got the symbols in it and so this is what I'm decompiling here and I found this great function. It's a L1D, which I think is layer one daemon, DSP put transmit data. So this should be the function I need, it'll just be, as Holger was saying the other day, it should be easy. I just have to take this function and just take the facts out and re-implement it and it'll be easy. But I started with this other, this one, L1D. You started with the init thing. Yeah, right, yeah, I know. Well and the thing is some amount of things are already in it with the code that people have already worked on, but I suspect that they didn't do anything with the DSP at all. So I'm wondering if maybe, so this is this L1D init, which is different than, so the code that already exists in that TX burst does some RF init and there's a function called L1D RF init and what they did pretty much matches with what the leak source code does, which I don't think probably includes this one, which is the DSP init and then later on there's a, or well there's a, yeah there's a DSP init, oh DSP wake up, that's the other one. So obviously there's some things here. What I was looking in here for initially was the next step was gonna be like try to get the device to sync with the BTS. So looking at the frequency burst in like the SCCH and SCCH. So I started trying to find that in the source code and there's just nothing there. So what I suspect is that the leak source code doesn't have any of the C code that interacts with the DSP. I haven't really confirmed that yet, but I suspect it because I found a lot of references to things that aren't available in C files. And so looking here, I'm hopeful that by looking through here and maybe I can get, and actually I think I got that TXT. Oh, I was doing a search for L1D DSP and that's how I found that transmit data stuff. So yeah, so I'm looking through this, I'm gonna look through this and try to figure out what it's doing. I found one really exciting discovery is that a lot of the DSP codes manipulating an address that I've never seen referenced anywhere. So that's kind of exciting because I feel like there's probably just a whole block of registers that are communicating with the DSP. So that's kind of exciting to kind of know where it is, even though I don't know what it is. Let's see, what else? Yeah, so the leak sources and then so that there is a data sheet for the 6235 that pretty well describes these two interfaces to the transceiver, I think, so the baseband serial interface and baseband parallel interface. The way I understand, I don't actually know what the system on chip architecture is precisely, there's certainly an ARM core. I don't know if there's a separate core. I'm not much of an expert with hardware. So maybe a separate core for baseband or not, but I think there's not. I think there might be an ARM core, a DSP core inside the SOC and then outside that is the transceiver chip. That's kind of my idea right now. So this BSI and BPI, which is parallel interface, interact with the transceiver and this is what that TX burst is using to configure the transceiver to open things up. Both, so there's baseband serial interface and baseband parallel interface. The way I understand it right now is that for both of these, there's a TDMA driven mode that you can use and there's also a immediate mode that can be used and the code currently is using the immediate mode and like the TX bursts when they initialize things and when they do the burst, they have a lot of things where they wait a little bit of time based on the TDMA clock. So they've got a function to basically pull the TDMA clock and wait five qubits or something. Depending on, and those numbers that they put in there I don't even know what they are. I tried to add them up, tried to match them with some particular burst type and it just, I don't even know what it is. There's a whole bunch of configuration in the source and I also found a GSM layer one document, it's like a, here's how you interact with the layer one firmware document for MediaTek that I had not seen until like a month ago and that had a whole bunch of really interesting information. It describes a whole bunch of kind of like timing diagrams, the TDMA and various like tuning adjustments that you can make for the basic timing of different things inside of layer one of their firmware. And I found the .h files for different transceiver chips where they have a big chunk of qubit timings for different aspects of transmission and reception, ramp up, ramp down, stuff like that. Yeah, and the parallel access is like just like kind of immediate like on off directly connected to the pins of the transceiver. So like in the transmit, there's one where you turn on the PA or something like that. Yeah, and so I have a whole bunch of notes on like what all the code means in the transmit burst and I've done the static analysis like I was showing with the Gehidra. My plan is to probably work on the synchronization with the BTS, the kind of RX stuff next. And I definitely want to take the many, many pages of notes that I have and call less them into wiki entries and stuff on the Osmocom site. And that's pretty much it for the real things that I've done that aren't vaporware. I have lots of vaporware ideas, so we'll share those for another time. So that's it, right? Span, yeah, yeah, bye. Yeah, we are first off, thanks for the presentation and continuing the work that started, I mean, nine years ago when first looking at the MediaTek platform. And what I just remembered from back then is that there's this, I think there was a separate firm where for calibration purposes, there's Cal, KAL stuff, I think. Okay. Which implements a rather minimal layer one. So maybe it's easier to look at this. And that's like a binary somewhere? Or? I think so. So I think relinkable object somewhere with debug information. Oh, okay, yeah. So because it's a lot, yeah, simpler. Right, yeah, yeah, right, okay. Cool, awesome. So maybe it's a hypothetical feature. I was just thinking, so it's maybe a next step or a lot of steps afterwards. So at some point, so now we are running layer one only in there, but so it seems like actually you can run a lot of stuff there, like as in a mobile phone, let's say. So at some point, I guess you can run even Linux there. So I'm just wondering what could be the interface like? So if you basically run layer one on the same sock with... So is there some kind of interface available for this kind of communication or we should create one? What do you mean by interface? You mean? Well, I mean, so you want to communicate probably from user space to the kernel and then the kernel has to set up some registers or whatever, I guess. You mean like on the device? Yeah. Okay. Yeah, I mean I certainly thought of like two things. Certainly I felt like it might be important to maintain the ability to run like the mobile app on the host and do experiments like that. So maintain that kind of Osmocon connection there. And then, yeah, certainly I would plan on trying to run something, some OS like NutX. I think the 62, 60 and one maybe don't have enough something to run Linux. So maybe it'd be NutX, I don't know. They already have NutX for it. The Bunny and Chris, Sean did that. So yeah, the plan would be definitely to have a usable system just on the phone. Yeah. If I can add to that, I think, of course, it's like talking about step 30 before. I mean, since the protocol between the layer one and layer two and higher is right now spoken over UART, you could actually have the layer one in the kernel and then have something like a serial, virtual serial port to user space. So you can run the unmodified mobile program on user space talking not over real serial line to a remote processor, but really talking to over virtual serial port to the local layer one inside the kernel. But that's normal. That's great, yeah. I mean, I imagined that maybe at some point I would do something in a phone, no, for example. I don't know. I'm not gonna do much. My goal is to make a phone that I like and the phone that I like is extremely minimal. So I'll do the bare minimum, especially if it's also helpful to others. And somebody else can take that serial port and make it a phone adapter or something so that it can be used for people that want a UI. So thanks. Thanks. Yeah. Thank you.