 So I'd like to thank everybody for turning up right after lunch, hopefully don't fall asleep. And if you haven't had a chance, try the food cart here. They are absolutely fantastic. There's a whole cluster of them and there's not just the one cluster close to here, but there's a couple of other spots around the city that have just some fantastic food that you're never going to get in most other places in the US. It's a really good ethnic variety and a good combination of different things to try. So thumbs up to the food carts in Portland. So I'm Jeremy McNichol. I'm from Red Hat and I decided to take on the large task of trying to get the Nexus 5X and 6P mainline. So here's a brief overview of who am I. So if you recognize me and you were ever at an Ottawa Linux symposium, I grew up in Ottawa and I pretty much went to most of the OLSs in Ottawa. I was a repeat offender and a regular attendee of the local Linux community in Ottawa. So if you've been to Ottawa and attended an OLS, you probably recognize me. These are some of the toys that keep me sane beyond playing with bits and bytes. I love being outside. I love bikes and riding bikes. I recently went to, maybe a year ago, two years ago I went to Europe and while I was there I went to Amsterdam. It was absolute bike heaven. So this is, on the left that's my trike that I used to ride in Ottawa. I only had a cycling season of four months. Whereas now I'm in California and I get 12 months a year, which is just great. And on the right hand side that's the Brompton I purchased when I was in Amsterdam. And as I was purchasing it, I took a picture of it. It folds up into that suitcase and I can travel with it anywhere. I recently went to Japan and took it with me and traveled everywhere on bike. It was just awesome. I have it with me here. I did some riding this morning. And there's my bike at the top, my Brompton on top with a picture of it, the Golden Gate Bridge in the background. I live a couple of blocks from the Golden Gate Bridge right now. So that's a little bit about myself and what makes me tick. So why do I take on this effort? To people here, I think it's really obvious. The answer to people here because I know you guys get it is why not? There's no mainline support for it and the really simple answer is why not? Let's just do it. It's fun. I enjoy it. It's interesting. It's challenging. It's stuff that just keeps me... It's better than watching TV or playing video games. It's more intellectually stimulating than watching TV. But you can do both at the same time. That's the sort of attitude that I have towards this. It almost feels like a hobby more than work. And when it feels like that, it doesn't really... It's not tedious. It's not difficult to motivate yourself because you're not being forced to do it. So that's why I didn't mind taking it on. When I took it on, it was the current latest generation phone. And I thought it would be a lot of fun because I know at some point Google's going to drop support for it. And at that point, when they drop support for it, there are people in the community here that are going to want to keep playing with it. For example, the XDA community continues to hack on these phones long after they've been dropped by the mainline people or by Google or by whoever else that's pushing these phones. As well, I thought it would be useful to do the flagship phones so that other vendors would hopefully get inspired to follow suit and say, okay, look, this phone is mainlined. Maybe we should try to put in the effort to mainline our phones as well. So it's sort of like saying, okay, look, here's the cookie cutter example of how you can go about getting your phone mainlined and the types of things you have to concern yourself with. Maybe other vendors can follow suit and follow the path. That's maybe inspire them to do the right thing instead of just putting their code somewhere to follow the letter of the GPL, actually trying to get it into the main kernel and running. There's no other reason for me motivation-wise other than it's fun. I work for the platform enablement team at Red Hat. Our job descriptions are kind of like we do whatever. We don't really have a set job description. So my job is typically supporting a rel. So that's our bread and butter. That's where we make our money. But my boss has said to me, okay, I want you to support rel, but I want you to find things in the community that you find interesting that you want to work on. So I took this on. I thought this would be a lot of fun. And it's been very challenging and it's quite interesting. I'm learning a lot about phones. I had a fair background in the embedded world and the power PC world. And then jumping into the phone world was a, I guess some people would say a rude awakening or an absolute eye-opening experience that how the phone world does things compared to the simplistic power PC world is very, very different. I was quite, it was definitely eye-opening. I just decided to jump in wholeheartedly and very naive kind of view, go for it, let's see what happens. And I'll tell you the story about what happened. So here are the specs. I decided to actually include a slide when I post these with the specs for the phone themselves so that if you want to look at it, I just took it from XDA arena and I grabbed the 5X as well. It's pretty small, but I made it small on purpose so I could fit everything in. So if you can't read it, I'm sorry, later on you'll be able to pull it up. The specs are pretty straightforward. They're all on the web, publicly available, nothing hidden. I've got a list at the end of my presentation with links and references and I've included these links and references with that so you can just pull it up and look at it there or just Google it. Exactly. Same thing here is the specs, what it came with at the time and things like that, the dimensions, so much memory to add to the storage. Before I begin, there's some terminology, there's some marketing terminology and then the terminology that the common engineers, normal folks tend to use. I'm probably going to use 8992, which is on the 5X. The marketing term is Snapdragon 808, so just bear with me. I'm going to constantly use 8992 versus 8994. That's why I put, I can't seem to remember the marketing terms. I stick to the more technical terms. It's easier to remember for me. And then the other term you're going to want to get used to is downstream. So downstream is anything that's not in kernel.org, be it MSM310, the one that's published on Google or published on Kotorora, I consider that downstream. And those are the terms that I'm going to use throughout this just so that you're familiar with it. And the integration branch is something that the linear folks who are doing a fantastic job at mainlining things, they have something called an integration branch. And that's also a term, and I've got a link to it at the end of my presentation. They use the term integration branch where they put all the different pieces that people are working on into one common spot so people can work as a team in Lunero on these sorts of things. So where did this all start? The last ELC in San Diego that I attended, I think there was other ELCs or other conferences. The one that I went to was in San Diego and I was kind of poking around at the idea of trying to get the Nexus 5X mainline because I was looking at it and I said, okay, maybe I'll go take a look and see if the phone is working with the latest and greatest kernel. Sure enough, it wasn't there. I saw different bits and pieces about things that were working and weren't working. I was like, okay, what is this? Maybe it'll actually just work. So I went and bought the phone and I turned up to the conference. It was like a week before the conference. Turned up to the conference and ran into a bunch of people from Ottawa that I knew that were working for Lunero or other people that different companies from Ottawa that I'd already knew and talked to them and said, hey, I've got this phone. I'd like to try to get it to work on mainline. Their initial reaction is a little chuckle and then they're like, are you sure? Yeah, why not? It'd be great fun. So they're like, okay, so how do I get serial console? As an embedded person, the first thing out of my mind is I need serial and that was the first challenge. Because of the great people there and the great people within the community, it was a matter of me talking to these people and saying, you know, okay, I want to actually try to get this phone working. I mean, I said, well, how hard could it be? You've got downstream support. You've got a kernel that's already published by Qualcomm or Google. I mean, it's 310 based. It was at the time it was 4, 3 or 4, 4. I said, oh, it's pretty small delta. It can't be that bad. I mean, nothing's really changed. I mean, how hard can it be? It's just do a diff and you're off to the races. And then I ran into other Steven Boyd's presentation on the MSM fork and it was like 1.5 million lines of code. Okay, that's when I sort of reality set in. I'm like, this may be a little bit more challenging than I originally anticipated. So I said, you know what, why not? This is, I'm a glutton for punishment. So let's just do this and have fun. So I actually decided to go at it whole hog and have fun and see what would happen. So I talked to the people at the conference. I said, you know, what do I do? Where do I even start? So people were just so helpful and considerate and kind, typical of the Linux community. And it's something I can't emphasize enough that regardless of the fact that people are in all these different companies and every other company has got, you know, they're all differing opinions about how to do things at the upper levels. But the people that attend these things and the Linux people within these companies all have the same sort of mentality of helpfulness, willing to offer advice, even if you don't want it, you know, reach out to people whenever somebody asks for help. I mean, this is typical of the community that I was used to in Ottawa. And I'm seeing it continuing on, you know, obviously it's not perfect, but it's actually a very good thing to see and to be part of. And that's what, one of the reasons why I wanted to do this. I thought it'd be fun to give back to do something that, you know, there was no support for it's fun. Let's just get it working. The typical Linux mentality of why not? And at that embedded conference in San Diego, at the end of the day that I was asking about building a debug cable, I was able to walk away that night I drove to Fry's. There's a Fry's in San Diego. I literally drove to Fry's that night and bought the board that the Linairo folks suggested that they use for a lot of their targets for their lab. And it was simply one of these boards that you get for like, I don't know what you call it, Arduino or those BeagleBone Blacks. And it's just an FTDI chipset with 3.3 volts and 5 volts switchable. And you just had to, I just had to buy a cable with the ear jack that plugs into the phones. Let me grab the two phones here. So here's the two phones. When I turned up to San Diego, I literally had the Nexus 5X in my hands and I said, you know, this is what I want to do. I just got a phone. I got a charging cable. How do I get to the real console? And they said, you know, somebody that I knew that was part of Linairo introduced me to somebody else, introduced me to somebody else. And that person was like, this is what you need. Here's the equipment that you need, you know, cut the wire here, split it. These are the colors that go here, here and here. And literally that night, every time I travel, I carry duct tape and, you know, toenail clippers. And literally that's the picture of that night when I got back after the conference. I cut the wire, stripped it and attached it to the board that I bought at Fry's in San Diego. And I had a fully functioning debug cable within five or six hours of asking how to get it to work. So that's a true testament to, you know, duct tape and the helpfulness of the community. So that's a picture of, yeah, you can get it working without all kinds of fancy soldering and electronics and all this fun stuff. Just, you know, it's the way real work happens. And then the, while I was there, I was talking to different people and they said, okay, you know, once you get up and running, you're going to have various problems that are things that at the time things weren't mainline. So Steven Boyd, there he is right there, was kind enough to put me in touch with a guy in Germany by the name of Bastian Kosher. And he had done the global clock support or the baseline support for clocks, which was common for, allowed, was common between the 5X and the 6P or the 8992 and the 8994. So I contacted him. And while I was, you know, contacting different people and contacting the guy in Germany and trying to get the information from him and get his patches, I started looking at the delta between 310 and whatever mainline was to see, just a diff to see what I could do and see if it was possible and think through possible scenarios. And I thought, okay, I could try to do the whole phone at once, which is kind of foolish. I've been in this industry long enough and I've done enough embedded work that trying to do the whole phone in one fell swoop would just be almost impossible. So I thought, okay, what would be the best way to approach this so that it's the least amount of work to get people going who would possibly want to help. And I thought, okay, the easiest thing would be one CPU running off an NDRD with serial or debug serial. So that's the way that I approached it. I thought that is the least amount of work to allow things to happen in parallel and get that mainline, getting that mainline. Once that's mainline, then people can start adding pieces and can start looking at other stuff in parallel. And that's the whole idea. If you try to do the whole thing yourself, it'll take you six months, you'll have to rebase, things will change so much, whereas if you get some initial work in mainline, your stuff is going to get carried forward and anybody that changes an API or an ABI or whatever you want to call it has to make sure that your stuff continues to work. And that's sort of the agreement, the unwritten agreement within the community, that if you make a sweeping change, you've got to verify that everything is working or at least contact the person, somebody that has the hardware that can test it for you to make sure you haven't broken anything. So this is why I wanted to get it in early and often. One, people will change it for you and maintain it for you. Two, it's going to allow other people to get going and to help out as much as possible. And that was kind of my goal. So I put together a quick list of what's working. Instead of saying this is what I need help with or this is what's remaining, I thought why don't I just make a quick list of what I know is currently functioning as of two nights ago, three nights ago and where things stand. You'll look at, so we have one CPU going on both phones. I tested it and it's fully functioning. So I got both phones fully functioning at this point. I can test both of them now. I've got an IDRD or RAM disk, whatever you want to call it. I've got debug serial through the debug port. That should be here somewhere. I didn't bring it with me. I forgot the debug cable back in the hotel. I've got onboard storage going. I sent out some onboard SDHCI and MMC patches. I'm not sure if they've been picked up. I have to loop back and see. I know the clock work for that was merged. But the actual DT or device tree changes, I'm not sure where they stand. If they haven't been merged at this point, I'll loop back around in a couple of days and do a resend of the latest version of the DT changes to get some more eyes on them for review. The pin control stuff from the Lanero folks, I did maybe 85% of it myself. Then the Lanero folks, I think they had already started it or they had something which was close. They were able to, I believe it was Michael Scott, send something out and it got merged. The pin control stuff is fully functioning now. After I sent out the MMC or SDHCI stuff, I was discussing different ideas with people of plumbers and I looked at the various things that were working or were not. I wasn't sure what was the next piece I wanted to tackle and I had some discussions. I thought that instead of me standing around and talking to you guys and just saying, this is where it's at, this is what we've done, here's a few things, I would like to have sort of an open discussion or brainstorming session with you guys for the different pieces that we could potentially, notice how I said we, I don't want it to be me, I'd like you guys to help, so we could potentially tackle next or some of the pieces that would give us the most bang for our buck. Yes, all the patches have been submitted, SDHCI or the onboard storage, I don't know if it's been mainline but literally, as you can see here, it's in 410 RC1 and got picked up. And if you want to use, all you need is a debug cable and do an INIT RD. You can take a look at the end of my presentation, I've included a list of references and as part of those references I've got my lead into my initial changes had a bunch of details on the compiler I used, the branch and things like that. So it's just a matter of getting a cross compiler going from linear or for whatever you want and compile it up and then load it onto your phone. It's pretty straightforward, it's actually working. That is one commit, it didn't go into one big chunk, it went in through device tree, through DT bindings, through, what else, some config changes and then the actual device tree changes themselves. But it's all been mainlined and the clocks are there as well, the clocks went through the clock tree. So I just want to give full credit and thumbs up to Bastion Koshar. He did a, hopefully I didn't mispronounce his name, he did a fantastic job in getting the global clocks working. If it wasn't for him I think I would have been scratching my head a lot longer and he really pulled it together and he did a great job. I was quite impressed with his effort in getting the clocks, being able to pull the clocks together and working. It's a true testament to geographically diverse people talking and working together for a common interest was actually quite nice to see. Here's an example of what was needed for the yellow. I highlighted the yellow on purpose. It's there to show you that the string that I highlighted, if you look it's all the same string. It's blsp1 underscore ur1 underscore apps underscore clock underscore source. If you're forward porting anything at all, please try to keep the names similar because it's going to make people's lives when you're grepping two trees a little bit easier and it's going to make, from my perspective, grepping trees and looking at an older kernel versus a newer kernel trying to understand what was done before versus now, for example, on the MSM8996, trying to look at the older kernels comparing it to what's there now, keep the names the same to make people's lives easier or at least as close as possible so you get some kind of clue as to what this variable or what this thing does or is. That was the one problem I had. This is an example of what was done on the left is mainline and that is what he used as a reference, the 8916 because it was in the 310 kernel at the time and there's the mainline version. You can see it's fairly similar but there's enough differences that you're sort of like, okay it's not quite the same but it's similar enough that you can kind of guess. But there's other problems, there's other little subtleties and some of the names aren't quite similar and some of the clocks aren't quite similar so that's where you start getting tripped up. It is the other issue that we had and the other issue that he wanted me to bring up to make sure people are aware of is the lack of documentation. There's nothing out there produced by the vendors to give to the public so when I first set out I wanted to go and find the documentation for this before I started and I couldn't find it anywhere. I knew people in Qualcomm who had the ability to provide the documentation to us and even on an NDA they still wouldn't provide it to us. It's unfortunate, I'm not going to judge either way that's not why I'm here, I'm just trying to let people know that having the documentation would be a nice thing but it's not essential. If the code is published you can use the code as a reference it makes life a little bit more difficult but it is doable so I don't care either way. Ideally documentation and having it available freely in opening and being able to sign an NDA would be even better but using downstream code is fine. That way when somebody reviews your code and says hey you haven't done it quite correctly well that's how downstream did it, sorry. Unless somebody from Qualcomm or Kotorora or Lanero can explain to me why it was done like that before that's what you're going to get so that's what happens. It just benefits everybody if somebody can explain it or if the documentation available but to Qualcomm and Kotorora and Lanero's credit they've been fantastic at providing not documentation but answers on IRC and through email and they've been very cooperative and collaborative from the different people I've worked with. I've got nothing but praise for them as a company to work with and collaborate with as well as the people at Lanero. This is an example. It kind of looks close but it's so slight. It's different enough that it's not something you want to tackle after a couple of years. You want to be a cup of coffee and then scratch your head a little bit and you can see there's some subtleties and some similarities that you can probably tackle it. Here's another example of the downstream version versus the mainline version of... That actually should be on the left. It should be 96. That's a typo. I'll fix that before I post it. As you can see... Actually, no, it's not. This is the version that I'm looking at because I'm looking at PCI and I'm trying to figure out because one of the things I'm thinking about tackling next is Bluetooth and PCI is one of them and I'm trying to figure out what PCI clocks and what branches do I need and I know that the 8992 clocks are fairly similar I think they're fairly similar to the 8996. I'm trying to find some breadcrumbs in the current version of the 8996 that I can use to understand the 8992 version in the downstream. These are the kind of things that you can brace yourself for when you're looking. You have to guess and maybe hope that some of the breadcrumbs of what's there match up what you can find and see if you can connect the dots. Here's a quick sampling of the files that are available in downstream. On the top is downstream. On the bottom is mainline. Mainline, there's not that many clocks. We'll get the clock people to add a few more but that's just my hopefulness and wishful thinking and then the top window is what's there for the downstream stuff and you'll see that there's a lot of them and there's a lot of various clocks and a lot of different things that you try to match them up and try to piece it together and it can be kind of difficult. I was using 310 as a reference but somebody from Lanaro pointed out that there was actually a 318 version which matched up with the 89.96. Now I've been using that and it's been kind of helpful. I couldn't find it before but it took some click here, click there, click there, go to quarter or click there, click there, do this, click there. Oh, there it is, sweet. So then once I finally found, somebody showed me where to find it, I was able to find the 89.96 stuff and match that up. Some of the things that I've learned along the way, some of the things I'd like to pass on to you guys that I think to be useful if you wanted to tackle something like this is try to get things sent upstream as fast as possible. Don't let things sit stale in your trees or in your repos or whatever it is. The faster you get it to some kind of mailing list for review, the faster other people can pick off patches and try them for you. So that's one of the things that I've been doing actually. I've been looking at some of the stuff that the narrow folks have been doing or the quarter or and I'm like, oh, off a mailing list. I'm like, oh, let me try that patch. That could be useful for me. I'll go and grab it, put it in my tree and either make a change to my code and it'll turn out something that actually works and then I can add my tested by or I can offer some suggestions to them or like the pin control, I found some errors in some initial versions of the pin control that I had done myself without documentation pointing out that, yes, you missed two or three little things here and they were able to update it. So be active, get involved, try to see what's there and try to keep an eye on the mailing list and also jump on to IRC periodically because that's where a lot of the stuff gets resolved or a lot of the questions get answered. The people on IRC, the MSM IRC mailing list, it's at the end of the presentation. Fantastic and answering questions. I encourage you to join, ask them questions, be active. Even if you don't have a phone or you're not interested in forward reporting, get in and look at some of the patches, ask questions, get involved, introduce people that want to be part of this into that. There's thousands of ways that you can get involved as a contributor to the community, not just by submitting code, but reviewing code, maybe putting together some instructions, looking for typos, spelling mistakes, just eyeballing things. I can think of thousands of things that you can do as an individual. So some of the things, so somebody asked me at one point when I was at Plumbers, what's the end goal or what's the final thing that I want to see happen with this? I'm not necessarily interested in seeing this thing fully mainline or working 100% mainline. The thing that I think would be more important to me or what I'd rather see and be more rewarding is that somebody from the community or somebody not necessarily from the community, somebody that's new to Linux, that wants to try kernel hacking or wants to consider going down the path of working on the Linux kernel, maybe has a phone like this and says, okay, I'm going to go and build this debug cable following the instructions. They put it together, they see some of the downstream code, they get it working, they create their own patch, and then they submit it upstream and they would get it into mainline. It would encourage them to consider the path of going down the kernel hacking or the kernel development path. That to me would be a far more rewarding and be far more interesting to me to see somebody do something like that versus getting the whole phone working because it's just a phone, it's just a device, but having people inspire somebody or motivate somebody to actually get involved in this community that's never been part of it before, I think that's far, far more rewarding as a person. Maybe 10 years ago I would have said, yeah, we can cure world hunger, we'll get the whole thing working. I'm a lot more realistic now. I've been around, I know full well that sometimes your rose-colored glasses aren't necessarily as rosy as you think they are and sometimes you can't necessarily get everything going, but I would love to see people new at the community get involved and actually be part of it. That to me would be a lot more rewarding than seeing the phone fully functioning. Some of the things that I'm kind of summarizing that some of the things that I see is everybody's sort of hell bent on getting their name on X number of lines of code changed in the kernel. I am just as happy seeing my name on reviewed by or tested by or I helped with whatever or provide feedback to people or being able to be a number two in somebody's patch that they've put in a lot of effort into. That to me says, you know, taking a step back and actually being the guy on the side providing support to somebody else is very valuable because when I was going through this, I was like at V4 or V5 and I was getting frustrated and believe it or not there were people who never knew were paying attention to these, I would have dreamed they were paying attention to these patches and the mailing list and they actually sent me an email directly and said, it's great to see that you're working on this, keep going, I see that you're getting, it looks like you're getting frustrated. Continue on cheerleader rah rah rah toward a mentality. That's just as valuable as submitting code into the kernel in my opinion. The guy that's been sort of beaten on trying to get the stuff done is frustrated and having somebody motivate them or giving them that inspiration is very valuable. So consider that as a contribution as well. A lot of people that I talk to or their mentality is okay, it's big and scary, it's ugly, it's not. People are very supportive, they're willing to help. My experience in doing this was actually very positive and I was like, please, give it a whirl, try it. Don't be afraid, it's something that you have to try and you have to do this. So at this point I was going to kind of bring what I wanted to do was brainstorm, we've got 15 minutes left. I want to brainstorm with you guys ideas and reasoning behind the next subsystem that hopefully we as a community could tackle, but I guess it will be me, if you guys could ideally try to help, it would be fantastic. So the reason why I did the initial one CPU and NRD was because, and get it mainline as fast as possible so other people can get involved. Now I'm thinking, okay, I've got the onboard storage working, the patch has been out there, they have it mainline or not, I'm not sure if they got picked up, I'll loop back around and get them, let's pretend that they're fully functioning and they are mainline. So what's left? What are some of the subsystems that we could tackle next? And it would be the screen, okay? So if somebody, having the screen there, yeah, that's all fine and dandy, but how do you type, what do you use to type? USB, I was thinking at plumbers, USB would be a good candidate, Wi-Fi, IDC, spy, I'm just reaming off different subsystems. Can anybody think of a different, a subsystem that would be, I guess we have to need a microphone, or speak loud and I'll repeat it so that the recordings can capture it. Go ahead. Yeah, I leave mine connected to my computer the whole time. I don't actually, okay, to be honest, I don't consider this a phone, I just use it as an embedded board. So if I take it to a coffee shop, it's not a bare board and it doesn't look that bad. To me, it's just an embedded target. There's no difference between a bare board and this phone. It has serial, I have CPU, I treat it like an embedded target as an embedded guy. I can just leave it on a table and it looks like it's being charged. So you're right, battery charging, so maybe the narrow folks could start tackling that. I wanted to, I was thinking more in terms of a subsystem, oh, I turned it on somehow, a subsystem that would allow people to build off of the stuff that's already there, maybe not having a debug cable. Maybe if they wanted, I was thinking maybe Bluetooth would be the next one or USB. I'm not sure what state USB is currently in mainline or if it's close enough because you could, if USB was close enough that we could maybe use that, get that working and you could actually log in to the device and work like that and then you could use crash dump and then what would be the, what would be a common sense order of things that could be tackled. I'm thinking Bluetooth, USB, Wi-Fi so you can get maybe, you could log into the device with maybe a drop bare. I'm trying, okay, so I'm trying to do everything using an NRD and that has proved to be very difficult. I've run into problems with it. I can't seem to get a RAM disk bigger than 2.1 megs for some reason. I've moved the RAM disk around in memory in different places. I've tried all the different combinations. When you do a make boot image, I just can't seem for the life of me to get anything more than two megs working. So if anybody here knows how to get a large, the reason being is I don't want to wipe out what's on the phone. I want to keep it intact so I can go back and look at what was done in 3.10 so I can get, because I don't have documentation, I need 3.10 to be functioning. So I need a fully functioning phone so I can poke at Bluetooth or poke at PCI, print stuff out in the serial console so I can see what's going on. That again is something that I encourage you to, it's a great skill to learn is that figure out the subsystem you want to tackle and then try to track down old code because you can learn a lot about different subsystems by forward porting it. So if you want to learn something on PCI, forward port PCI, you can track down the code and the old code and then you can put all kinds of prints all over the place and then try to get the new stuff working. That's an amazing way to learn how this stuff works. I would definitely encourage everybody to try something like this. It's an unbelievable, great learning experience. So I decided to tackle Bluetooth because I thought all right, USB at a time when I was thinking about it may not have been all that stable, may not have been quite there yet or mature so I thought Bluetooth, I'll tackle that. So here's the logic behind Bluetooth and the path that I took and the way that I did it. Hopefully some of the tips and the way that I'm doing it will be beneficial to others and you can maybe learn something from it and I would like to learn something from you guys for me to me as well. So if you look at it, the first thing I did was I went to the teardown site. There's a place in Ottawa where I'm from, it's actually Canada, ChipWorks who does reverse engineering of products to describe what's in each of these different ones. So I went to the teardown site, I went to ChipWorks and I found what was actually on the phone for Bluetooth. The 5X and 6P apparently have different Wi-Fi modules but this phone has the QCA 6174 and that's the device itself. And it also, putting breadcrumbs in the older kernels it also actually has using TTY HS0 as its way of communicating. So it goes through PCI, this chip is on a PCI bus and the Bluetooth software, the Bluetooth Android Bluetooth stack talks to it through TTY HS0. Then I looked at different things on the web to try to figure out, okay, how does this all fit together? I don't really know much about Bluetooth so I decided to go and poke around and try to understand these things. So I found some stuff on the different Kotorora in different places for Lib Bluetooth and I found that there's different reset commands. You got to hit it with a GPIO to turn on Bluetooth, you got to send the reset command and then all the data starts flowing when you get through the serial console after you do this initial stuff. So these are some breadcrumbs that I'm able to actually get some logic and try to understand the different things. So here's kind of the thing after poking around and looking around here's the things that I think I need. I'm sure there's gonna be a lot more. I'm sure I'm gonna trip over all kinds of different things that I never anticipated. But this is kind of the logic behind the start. Poking around, kind of looking at downstream the basic flow. So here's what I think I'm gonna need. PCIe clocks. The PHY clocks as well. I'd like to thank another linearo person for pointing me at their PCIe enablement for the MSM 8996. It gave me some clues as to some of the things I'm gonna need to get going. So again, another thumbs up to the and kudos to the linearo folks. So I'm gonna need to get the PHY working. I'm gonna need to get, again, the PCIe. There's the chip. And after beating around Google, I found that the QCA6174 is supported by the Athros 10K chip. I don't know much about the code. I'm still kind of trying to figure it out. What I think I'm gonna do is I'm gonna try and use the back ports. I'm gonna try and get the Athros chip working on the the 10K code. I'm gonna try and get it working on the 310 kernel using the back ports. I mean, as an experiment to see if that works. If that works, and that tells me that the code is actually functioning. And I can use the mainline version of that. So I found that the back port people have support for the Athros, the latest and greatest Athros 10K driver working on 310 using the back ports project. So that's something that I'm gonna actually look at and try to understand the code to verify that it's actually functioning. I know I need to get RPM, SMD communication working. That's another thing. It sort of works. There's some gotchas here and there that I need to iron out and discuss with Bjorn. I don't know if he's here. I'll track him down. There's also some loser space work for blues and the firmware that I need to look at. I haven't quite figured out those pieces yet. I'm thinking the easiest way at this point would be to use blues instead of the Android bionic because it seems like there's more information about blues. So this is where I'm trying to get. I'm trying to use I'm trying to avoid modifying the onboard storage as much as possible. Or because I can't get an NRD running, I'm trying to figure out, okay, is there a partition on the phone that I can use to put the stuff that I need on there because there's like 45 partitions or something like that. So I would like to maybe put a RAM disk on there and then maybe do a charoute once I boot from a RAM disk charoute into one of the partitions and go from there because I kind of want to leave the phone alone. So that's where if anybody has any suggestions or any follow up with me, I would very much appreciate it. Send me an email, come and talk to me afterwards and raise your hand and offer suggestions. So I'm here to solicit help. Anybody that wants to participate, anybody that wants to help, I have debug cables that the Google folks are kind enough to give me. They've made them. They didn't have the duct tape versions. They did it more professionally looking but I prefer duct tape. That's just my way of doing things. That's the way I roll. There's so much things to be done. If you have a phone it's no longer the latest and greatest so you can sacrifice it. Maybe if you want to play with it, let me know. I've got some debug cables I can give to people. I made a couple. I've given one or two away. I've got a bunch at home. I was going to bring them with me to give them out here but I forgot them at home unfortunately. I'll mail them to you. I don't mind spending three or four dollars mailing them to people and hopefully people will be willing to help out. So here's a few things that I can think up at the top of my head that I know need some help or some work. The RAM disk, I need help with that immediately so that I can continue my work or point me to a partition that I can explode a RAM disk to so I can charude into as I said earlier. Anybody who wants to take on a subsystem please do so. Don't look at me as owning this thing completely myself. That's not something I'm doing. I did the initial heavy lifting. Now it's up to you guys to help out. Hopefully you guys can find ways to help out and be part of this just because it was one serial and it sounds like one CPU serial and an NRD. Oh no, that's not very much. Oh yes it is. It's a lot more work than you think. When there's nothing coming out of the console you have no idea what's going on. At least now you have a console and some serial debug so you've got some ways of finding out what's going on. You can always use KGB over serial but depends on your view of KGB and let's not go down that road. You can help me investigate various subsystems explain some of the different aspects of Android that I may not be familiar with because I'm coming from the embedded systems background and roll my own NRD. I haven't really had a chance. I tried building Android the full AOSP and it took I think half a day and I gave up. I just kept building and it was just too long. I said I can't do my own NRD in like 25 minutes. I don't want to wait half a day for this thing to build. So I gave up on that. If you have any interest in playing with the kernel or getting involved please come and talk to me. I would like to work with you. I would love to see as I said I would love to see somebody who's never tackled this before express an interest and get involved and learn and turn it into a potential career. That to me would be more rewarding than seeing the whole phone functioning. That speaks volumes for the community and that's just my opinion. I guess maybe as I get older I kind of see more of the getting people involved rather than changing the world. It's more seeing people learning and growing than necessarily getting everything functioning and changing the world. Documentation is also an area that people could help out with. A wiki updates some wikis or point me to some wikis that I could add things to that I've tripped over or I've seen or there would be a value. Here's my list of references and links and I mentioned of Steven Boyd's presentation on YouTube link and the debug cable I put together the link there as well as Google has published the Gerber files and all the like the actual schematics for it so if anybody knows how to build anything like that or is willing to do that come and talk to me because it would be really cool if we could do a run of a hundred of them or 200 of them or 300 of them and for a cheap price and then maybe we could get a company that's got some money to build them and then we could give them out to people in the community as a community donation or something like that that was something I was discussing with the linear folks a while ago doing a run of two or three hundred finding a company to pay for them and then handing them out to people that are interested in volunteering. That's pretty much all I wanted to discuss any questions or comments or suggestions I've got two minutes left I can repeat it I don't think it's a microphone I'll just repeat what your question is so that people recording at home so anybody have any questions or comments or suggestions anybody willing to volunteer question here they're low hanging fruit I agree they're low hanging fruit but what would it buy us a touch okay I can see peripherals okay but I gotta figure out what the peripherals are I don't have any documentation I gotta figure out what peripherals are hanging off of I2C first touch okay so there's a lot of things that I don't know that I'm just trying to figure out as I go along so I'm not gonna pretend that I actually know how this works I just look at it and say okay this looks like an interesting thing maybe I'll go learn this and that's what I find fun and interesting and motivating and that's one of the reasons why I did it is there any other comments or questions anybody way back there that I can't see anybody you have to come spy I2C sensors what would the sensors give us what would it buy us I'm thinking like bluetooth so people can log in and start developing but what would be the motivation for doing I2C spy and sensors what would be the motivation low hanging fruit okay so that other people can pick off different peripherals you can't access the sensors I can repeat it because it's not I didn't catch all of it okay mainline IMU code so after this come and talk to me and I'll give you my card and send me some more details I'd be great that's something that I'd like to see I don't know enough about it I'd have to start learning something so any other questions I literally am out of time we started two minutes late but that's fine anybody else any other questions concerns anybody want a free cable for volunteering to help anybody anybody come on you'll take one okay come and talk to me so see me outside I'll stand outside obviously I'm pretty easy to find with my orange shirt so come and see me outside after this so the next people can get in and we can discuss things further thank you very much and thanks for attending I appreciate everybody's time