 So today I would tell you something about running Mainline Linux on the Motorola Droid 4, which is an Android-based mobile phone from a couple of years ago. But before doing that, let's have a look at other supported phones. So when I started getting interested in kernel development, I had a free one now, which was pretty well supported by Debian, but the kernel never really reached Mainline. So when I had a new phone, I started working to get everything Mainline, which is the Nokia 9900, pretty well supported nowadays. But it's kind of old, just has 256 megabytes of memory and it's really slow. So since a year or so, I'm working on the Motorola Droid 4 together with Tony Lindgren. And we got quite a bit of hardware working on that one. So why are so few mobile phones supported? I think it's a combination of multiple reasons, but most important, the phone vendors don't care. They don't really work on Mainline support, so it has to be done by the community. And there's lots of code required to get the phone working. The stock must work or the peripherals must be supported. And the code that one can get from the vendors, usually they are vendor Android trees, is really low quality. You can't get those drivers into Mainline and have to rewrite them. Also, once you're done, you have the problem that you don't have any user space, because nobody wrote it and nobody wants to write it because, well, there's no kernel support. Also, usually it's quite hard to get data sheets and you have the problem that you need some sort of serial access because if something fails in the kernel, you want to see what failed and not just get a black screen. So for the N900, this was quite hard to do because the debug access was below the battery. Here there are some pads. I'm sorry, I had to build some adapter to get access to it, which took quite some time for the Droid 4. It's much simpler because it has the serial pins pin-muxed to the USB connector. So you can just use a normal USB cable, cut it, connect it to a standard USB serial adapter and then you have serial. The only important thing is that you don't attach the 5-volt pin because then it will mux back to USB mode. Yes, so for the SOC. And the Droid 4 is an OMAP-based processor from Texas Instruments. This is similar to the Nokia N900, which has an OMAP-3, so most of it was already supported when I started working on it. Which means that it's possible without doing anything to boot into the kernel and get a serial console and I didn't do any work on that part. It was already there. Which means there were clock drivers, reset drivers, timer drivers, interrupt drivers. The memory management unit was already supported, DMA. All of that needs to be done. I think there's a talk from Enric later. He may tell you a bit about that part. Then the GPI was already supported, SPI and I2C, so you can directly start working on supporting the peripherals. What was not supported is the display because in this phone Motorola used self-refreshing display, which is currently not supported by the OMAP-DAM driver. I will come to that later. Also unsupported is the camera interface, which nobody worked on so far. Most importantly, there's no graphics acceleration at all. The chip uses... Can you move your microphone like here or on the other side? Because you're always talking like this and the microphone... Right. But we will put that back later on. Right, the graphics. The OMAP and all of them have power-v-air-based graphics chip. So there's no open-source driver for that one. And apparently even the closed-source driver is currently not working with the current mainline kernel. So far I didn't care at all because there's so much other work to do. The power management chip is a different matter. Usually the Texas Instruments chips are used with a companion chip from Texas Instruments, but Motorola decided against this and used their own, which is named Motorola CP-CAP. And after some reading of their drivers we noticed that it's really similar to a chip from NXP, which is named MC13783 and has a public data sheet, which is quite nice. Especially since all of the drivers from Motorola are really low-quality. So we started rewriting all of them and currently finished the regulators' drivers, the analog digital converters, the battery and charging drivers, the real-time clock and the status LEDs, which is almost all of the supported features of the PMIC, still missing there is the audio support, which is work in progress here. Additionally there are quite a lot of peripherals attached to a phone obviously. The nice thing is that nowadays on the mainline kernel almost all of those already had drivers because somebody required them for some other boards or chips. So we could just enable those in the device tree, which is the touch screen on the keyboard, the buttons, the vibrator, needed a custom driver, which is just like 150 lines of code. It's connected to a PVM output. And right, the phone has HDMI output. The difference to the display, that one is working because it does not need any self-refreshing feature and it's basically exactly the same as on the Panda board, which is well supported by the mainline kernel. Right, not supported as I told you is the LCD panel. Basically it's just a couple of lines missing on the mainline kernel because the display self-refreshes. So you just send it a picture one time when the display changes and then again when the display changes next. This is currently not supported. It's just on the mailing list. I hope that they will arrive on the next kernel release. And also it will only work with XORG and with the normal shell. It won't work with Wayland because Wayland currently has no support for telling the kernel that the framework changed. In addition to the LCD panel, the backlight controller is currently unsupported. We know which one it is and we have patches for it, but they have not yet arrived mainline. There's some discussion going on about the device tree bindings, so it will take some more time. But once those two have arrived, we have full display support. Right, and you know, those are the more important peripherals I guess. The more important ones are already working or the sensors. They had drivers on the kernel, so we just had to enable them. So let's move to the more interesting parts, how to connect to the internet. The phone has Texas Instruments based Wi-Fi solution, which worked from the start on because there were drivers available. And since I think two kernel releases, we also have Bluetooth support. Not yet working is the included FM receiver, but that one is also not supported by Android. So I guess it's not that bad. Then the interesting part, the phone actually has two different modems, one for second and third generation and one for the fourth generation's networks. Unfortunately, the fourth generation network is only supported in the US because the modem is limited to their frequencies. Also, that one is currently not working. I didn't have to look at it because I'm based in Europe, so I don't care basically. But the second and third generation is working pretty well. Tony Lindgren is based in the US, so he's currently working on the fourth generation modem. We currently know that the main problem is that it tries to access the SIM card from the other modem using some weird protocol that is currently not supported. For the normal modem, we basically have GPS working and data connections. And we can send short messages. We can't do voice calls yet because audio is missing, so nobody really tried. We also had to short look at the camera stuff. The problem here is for all the other peripherals we could have a look at the kernel implementation of Motorola and just rewrite their drivers properly. But we could use their drivers as documentation. This is different for the cameras because the OMAP4 has a small processor inside of it which can handle all the camera stuff. It's the one marked... oh, I can't really read it. Anyways, there's a small companion processor and Motorola does all the camera work on that one. And the firmware for this processor is closed, so it's hard to understand what is going on. We know the LED flash chip just by trying to check the registers, reading their values and comparing it to datasheet that are public. So we pretty well know that it's an LM3559 because the reset state of all the registers is exactly the same. And we assume that the main camera and the selfie camera are those chips listed here. We don't know for sure because we have not yet managed to speak with those chips at all with the mainline kernel so far. So there's lots of work to be done here. Yes, so I'm mostly a kernel developer. I can't tell you many things about the user space. What I can tell you is that there are two different implementations which act as an interface to the modem that abstract away different vendor implementations. One of them is the free smartphone.org stack, which is more or less abandoned upstreamed. Last change has been, I think, three years ago. And there's Ophono, which only abstracts away the modem. So Ophono does an abstraction layer for all the peripherals, not just the modem. Ophono concentrates on the modem, but it's still supported upstream. The last change is probably from yesterday or so. And it does support the Motorola. So that one can be used. Another option would be to use Android. I can't tell you anything about it, but later there's a talk from Robert Foss downstairs. It's directly after this talk. He can tell you something about this. And of course, you can run a normal Linux distribution. That's what I'm currently doing. It will only be useful on the Droid 4 and not on other mobile phones. So if you plan to do something similar on those, you will have the problem that they don't have a physical keyboard, which is one of the nice features of the Droid 4. And there are a couple of special operating systems like the stable hybrid release. And that one was a distribution for the FSOS stack. So it's also dead, obviously. Then there's Firefox OS, which is no longer continued. We have SailFish OS, which is not yet fully open source. We have Tizen, to be honest. I have no clue what the current state of Tizen is. And then we have Purism, but they are not yet finished with their development. We have PostMarket OS. It's also currently in development. We have the questions from time to time how to support the Droid 4 or the Nokia stuff. And we have Memo Lester. They apparently sent me a nice screenshot of their current state on the Droid 4. So some people may remember Memo from N900, which is like eight years old now. And here it's still living. So let's come to the conclusion. I think it's an interesting topic to get into current development because you have to touch basically all the subsystems and get in contact with everyone. And you learn about a lot of different hardware. Also, if anyone is working on similar projects, every driver helps. So if you support something, it may help somebody else. For example, well, if you have some temperature chip, it might be built into some phone and then somebody else can just enable it. This was really helpful. Yes, so the big holes on the Droid 4 are 3D acceleration. To be honest, I'm not sure that we will ever get it working because it's basically all the work that we did so far multiple times. Then the camera support because we don't have documentation and it's really hard to reverse engineering on that one. And last but not least, yeah, proper user space. As I told you, I'm a kernel developer, so this is not my department. So let's try it out. I've attached the Droid 4 to my notebook. So at some point, HDMI will enable. Then we will see the kernel booting. At the moment, the display is rotated. This is because I did it in the command line. The reason for that is that currently we have the problem that the internal display is rotated and we just rotate it by command line and that will rotate the shell both on the internal display and on HDMI. Oh, well. I guess we can skip that one. Yeah, there's something, but the beamer is not good enough. Sorry. Yes, yes, it's the login prompt from the devian. Yeah, I plan to show you a couple of things, but I guess we can skip that. The display is too bad. So, yeah, don't go to the start. Are there any questions? So Sushpen does work, but at the moment we don't really use it. There's about six to seven hours. We can use the phone by just running it without proper power management, which was good enough for us so far. So, yeah. It's the high-secure version of the OMAP and the bootloader is locked. Apparently we managed to boot it anyways. That is something that the line address people did. They boot via KXX and we do the same. We are currently trying out to boot differently because you can apply custom kernel parameters to the kernel used by Android so you can skip some parts, but at the moment we use exactly the same system that the line address people use. The OMAP processor has a matrix where you can connect a keyboard to... Yes, both modems are connected to USB. Exactly. Well, I think... It is because for me it's enough to just run Debian on it. I'm fine with that, but I see that most people want something where they can use the touchscreen properly and stuff like that. Most of those projects are either no longer being worked on or are not yet ready to be used. So I guess one of those projects may be fitting for that task. Yes. It will definitely not be merged. That's obvious. So I have not yet tried to work with the second processor on the phone. Technically, you are not required to do so. So I did manage to enable the flashlight for the camera by just talking to the chip directly. It's connected via I2C. What the Android-based kernel does is that it takes the I2C interface and tells the second processor, here, this is the I2C interface. Do what you want with it. I won't touch it. So in the mainline kernel, we have not really touched the second processor, so I can just use the I2C channel and just talk to the chips myself. The problem is that I have to enable them first and I have to know how to enable them. So for the flashlight chip, we managed to find out how to enable it. For the camera chips, we did not yet find out. So if we scan the bus, we won't find the chips. Any more questions? Yes, it is different. For OMAP3, the camera interface is properly supported by the mainline kernel. For OMAP4, they are drivers on staging. I have not yet looked at them because we cannot talk to the camera chips and helps at the moment. So the camera interface is only useful once you can enable the data on the chip. But it's working. So on the N900, we got pictures from the camera with the mainline kernel. I'm finished.