 It's supposed to start at 1130, right? OK, cool. So how many of you were just in Jason's talk previously? OK, so some of you, not all of you. So I'm Drew Fustini. I'm part of the BeagleBoard.org Foundation. I'm one of the board members. We have two other here at the Amidolinix conference. We have Jason Kreidner, who's the co-founder of BeagleBoard.org. And we also have Robert Nielsen here, who does our Debian images and handles kernel builds and all that wonderful stuff. So they're both around as well. And we also have the technical showcase this evening. So I want to talk to you about Google Summer of Code and some of the past projects that we have done as part of BeagleBoard.org. So how many people have heard of Google Summer of Code before? OK, so most of you. So yeah, basically it's a global program for students to get stipends for writing open source projects. So a pretty cool thing. It's been around for 12 years. Over 100 countries have participated. Over 500 open source projects. Over 12,000 students and over 30 million lines of code have been written. In this past year, in 2016, there was 178 open source projects, such as our BeagleBoard.org. There were over 1,200 university students, 67 countries. Over 1,000 students completed it successfully, so around 85%. And each student that completed it successfully got $5,500. So the timeline lists here. A few weeks ago, organizations applied. This next week, coming week, we'll find out what organizations were accepted. And then between that period and March 20th is when students should hopefully be talking with the mentoring organizations that have been accepted, figure out what projects they might want to work on, what the needs of the mentoring organizations like we've been in the past might be looking for. And then March 20th, this is probably the most important date right now, is students can start applying on March 20th. And then the beginning of May, the students' proposals that have been accepted by the mentoring organizations are announced. And then the students actually start coding at the end of May. And then there's a few points along the way during the summer. There's midterm evaluation in June, final evaluation in project submissions in August. And then finally, in October, for the mentors from the different mentoring organizations, they'll come to Google's headquarters in California and have a mentor summit. So there's a few requirements for students that are going to participate in Google Summer Code. One is they have to be 18 years of age and older. They must be a full or a part-time university student or be accepted for the fall term of this year. And it has to be an accredited university. So I've seen some questions on the mailing list from students that are from maybe an online university or something like that. So if it's not accredited, then, unfortunately, they can't participate. Fewer things like that to be eligible to work in the country that they're in. And they can't have done it more than once. So they can't have been accepted to a previous Google Summer of Code project. And that's different, because in the past, students were able to do it more than one year. But now it's just you can only do it once. Though the cool thing, a lot of students will then become mentors in following years. So the way the stipends get paid out is incremental. So there is the first evaluation in July, second evaluation in August, and then the final evaluation in September. It's changed a little bit this year in 2017. So instead of just being a flat amount for every student, the amount is actually based on the country they're in. So on the Google Summer of Code website, there's a chart of depending on the country and the actual amount. Another thing I should mention, the slides are up on the conference website, also the e-linux wiki. So there's a lot of hyperlinks in these slides. So if you're interested, you can grab the slides and click on the links. So beagleboard.org, how many people have heard of beagleboard.org before? OK, pretty much everyone. So beagleboard.org is a community around building open source hardware for makers, educators, and professionals. So Beagleboard originally came out back in 2008. And it was one of the first affordable arm development boards. Jason was the co-creator of that platform. And then in 2011, the Beaglebone came out, which was a smaller version of the Beagle board and more focused on doing DIY projects that had more reasonable headers for doing interfacing with external circuitry. And then the most common Beaglebone you'll probably find in projects out there is the Beaglebone Black. And that came out in 2013. So because the Beaglebone is open source hardware, there is a wide array of different variations of the Beaglebone from different manufacturers like Aero, Element 14, Seed Studio. And our most recent one is the Beaglebone Black wireless. So if you notice that big chip there in the middle, that's a system in package from Octavo, which is a new company in Texas. This came out last year. And it integrates a lot of the silicon that was in the Beaglebone Black into one package. So the advantage of that is now we have room to have Wi-Fi and Bluetooth. Also reduce the complexity of the board. It's designed in Eagle now, which is a much more accessible CAD package than the previous one. And tonight, at the technical showcase, we're going to have the Beagleboard X15. And we'll also have a preview of the Beaglebone Blue. So come check that out this evening. So Beagleboard.org Foundation, we're a US nonprofit. We provide education around the design and use of open source software and open source hardware. We foster communication between individuals interested in open source. So probably one of my favorite Google Summer Code projects was the BeagleLogic by Kamar Abashik back in 2014. So this turns the Beaglebone into a logic analyzer and a pretty good logic analyzer. 14 channel, 100 mega sample. Has 320 megabytes of buffer space. So you can get 3.3 seconds of 8 channel data. Also integrates with SIGROCK. So you have capability to decode all sorts of different protocols. So to get started, one of the things that's nice about this is if there's an SD card image, you just put the SD card in your Beaglebone, turn it on, and you can pull it up in your web browser. This is an example of how you'd hook it up. So there's a cape there, a BeagleLogic cape. Now, you don't need the cape. It's just if you have 5-volt signals. The Beaglebone's 3.3 volts. So if you want to hook it up to a 5-volt system, like maybe an Arduino, you would need the cape. But the cape's not required to use the BeagleLogic software. And that's another interesting point about Google Summer of Code, is it's really about code. So you can have hardware be a part of your Google Summer of Code project, but it can't be the main output. The main output has to be a software. So this is the web interface for the BeagleLogic. You can choose the sample rate, select what channels you want to use, and then you can see the waveforms there. So this is a nice interface for people that are maybe new to logic analyzers, but it also integrates into SigRock, which is a great open source project that will decode all sorts of different protocols. So here it's decoding audio data. So it's nice that there's an option there for beginners and also for more advanced users that want to decode all sorts of different protocols. So one of the things that makes this possible is the fact that the Beaglebone has these programmable real-time units, or PRUs. So how many people have heard of the PRU before on the Beaglebone? Okay, so about half of you. So these are microcontrollers that are on the same die as the main ARM processor. So they're 200 megahertz, 32-bit microcontrollers that have access to the same peripherals in the main DDR system memory as the ARM processor. So it allows us to do really high-speed, real-time tasks, and that's what the BeagleLogic leverages to be able to handle this 100 mega-sample 14-channel logic analyzer use case. So BeagleLogic is composed mostly of there's PRU firmware, there's a Linux kernel driver, that presents it as a character device slash dev slash BeagleLogic, and then there's a Node.js server that provides that web interface that I showed earlier. So Kumar kept on working on this, which was great. So in 2015, he submitted it to the Hackaday Prize and was chosen as one of the best product finalists. And he was also a mentor at that point, so he traveled out to the Mentor Summit in 2015 and also went to the Hackaday Super Conference. So he has a great blog post on his website that talks about that journey, and I recommend checking it out if you grab the slides and click on that link. So he kept on working on BeagleLogic and was wondering what people wanted, additional features they wanted, and a lot of people wanted analog, it turned out, analog sampling. He also in 2016, last summer, was an intern at Google in Mountain View. So it was kind of cool to see the progression there from being a Google Summer of Code student to being a mentor to then being an intern at Google's offices. So it turned out that there was also a group at Google and Google Research that wanted to have a high-speed data acquisition device. So they had created something called the PRU DAC, which is a cape for doing high-speed data acquisition, and it turned out they realized that they could leverage BeagleLogic. So they were able to use Kumar's BeagleLogic software, and it turned out that performed actually much better than the sample code that they had originally written. So another project I think that had a good impact was BeagleRoss. This was back in 2013. How many people are familiar with Ross, which is the robot operating system? Okay, so this was basically integration of Ross into the BeagleBone, and the implementation was as an OE layer, an open embedded layer. So the BeagleBone part of it is he created a few Ross packages. So the ability for Ross to be able to talk to different sensors that you might connect to the BeagleBone and also control motors. And then that same student, Victor, followed up the next year in 2014 with BeaglePilot. So this is a Linux-based autopilot for flying robots based in the BeagleBone. So part of that was he ported RGPilot to be able to run in Linux on the BeagleBone and also did Ross integration. And one of the nice things was at the end of this, he wrote a paper with some other people describing the possibility of open source Linux autopilots for drones, which I think in 2014 was still kind of a more of a newer thing. Most people were using microcontrollers, I think back then. And one of the interesting things is they showed that Linux can perfectly be used to meet the real-time requirements needed by an autopilot requiring only about a quarter of the processor on the BeagleBone Black. So I think that was pretty interesting. There was lots of interesting graphs and metrics in the paper, so I recommend checking that out if you have interest in that. And he then went on, Victor went on to create a company called Early Robotics to commercialize the BeaglePilot. So they have a product called the Early Brain, which is an artificial brain for making robots and drones. And you can see there's a quadcopter with the Early Brain, which is essentially a cape that goes on top of the BeagleBone along with the BeaglePilot software. And there's also a spider robot as well. So it's cool to see the progression from Google's number of code project to then creating something as valuable as the community to then actually turning into a product. And then kind of going on farther, there was also the BeagleSat in 2014, or sorry, 2015. So it's a nano-satellite platform based on the BeagleBone. So essentially software that would help you in the process of developing a Linux-based CubeSat. So one of the main things here was the ability to interface sensors like IMUs into the Python library that's popular in the BeagleBone, PYBBIO, and then be able to fuse through sensor fusion. So be able to combine digital compass and accelerometer gyro and be able to use that. So I think that's still an ongoing project. So someone asked me yesterday if I knew of any Linux systems that were in orbit. And yes, you did. Okay, awesome, cool. So another interesting project was the USB sniffer. So this was all the way back in 2010. And this was with the Beagle board, which had several USB ports on it. So the way that this works is you connect a USB device and a USB host and you're able to sit in between and sniff the USB traffic. So it can be pretty useful for doing development and also probably doing reverse engineering, trying to get Linux drivers working for various types of hardware. And one of the other, I think really useful projects was user space Arduino. So this was done back in 2013 by two students. And this was to provide a way to run Arduino code in Linux. So have most people heard of Arduino here? Okay, so pretty simple way of programming a microcontroller with this simplified wiring language, which is based on C++. So a lot of people coming into the Beagle community, Beagle board community, Beagle board.org community using Beagle bones. Oftentimes they're coming from more simple microcontroller boards like Arduinos and they're pretty comfortable with that level of abstraction of writing Arduino sketches. So it's a really nice to have that ability for them to start using their code that they were using their Arduino in Linux. So this was an implementation to be able to run Arduino sketches in Linux. And this project was done on the Beagle bone, but it actually, because it's just implementing in Linux, it's applicable to other boards as well. And other projects have gone on to use this as well. So there's more information there if you wanna check out examples in code and screencast of how it all works. So this past year in 2016, we had seven projects. One of which is the Beagle scope, which was cool to see that build upon Beagle logic. So a few of the students, I told them I was doing this presentation and I was like, it'd be great if you could give me some slides about your project. Zubin was one of the people that provided me with some slides. So essentially what Beagle scope is, is to be able to hook up a ADC with a parallel bus to the Beagle bone using the PRU. So the way that this is done is by leveraging the IAO subsystem. So basically you're taking the PRU, you're using it as a parallel bus to be able to connect to a high speed parallel ADC and then exposing that with the IAO or the industrial IAO, the industrial IO subsystem, the Linux kernel. So Beagle scope is composed of three things. There's an IAO device driver, there's the parallel interface bus driver for that parallel bus that's connected to the Beagle bone and then a platform specific driver as well. So the main thing if you're interested in using this to consider is if there is a device driver for what you wanna use. So for example, is there a device driver for the ADC that you wanna use? In this case, he was looking at a particular high speed ADC board, which there was, he was developed a device driver for that as well. So this is basically a way to expose the high speed capabilities of the PRU as a device in the IAO layer. And links there to different information about the project. It supports reading raw data and also supports a buffer capture using IAO buffers. More links about the project, Wiki, source code. One of the things that's cool about Google Summer of Code is the students keep a blog and they're supposed to update it every week. So it's cool to be able to go back and look and see the progress of the project along the way. One of the other projects from last year was multi-channel sound driver for the Beagle board X15. So the Beagle board X15 is probably our most capable board and that's a new board that's coming out. You can see that at the technical showcase tonight. But it has a dual core A15, it has also DSPs. So this project was to leverage that capability into a high performance sound system. So Henrik was another student that provided me with some slides about his project. So previous to this project, there was a Beagle bone cape that they created called CTag which was a multi-channel I2S sound card that you could use with the Beagle bone. And this Google Summer of Code project was about being able to use that with the new X15 board and leverage the higher performance of the X15. So the first part was to port the audio card drivers to the processor that's in the Beagle board X15. It's using I think in analog devices, really good ADC there or something like that. So they had to port over the driver for that and then the other part was to create a user space library to be able to utilize the DSP that's in the X15. So it has dual core DSPs in the X15. So they created a user space library to make it easier for creating audio applications to leverage that. And so it's called LibDSP X15. It uses OpenCL to offload operations to the DSP. One of our other projects back in 2016 was the idea of exposing the PRU which is that the two microcontrollers that are in the Beagle bone to add additional peripherals that you might need. So this project implemented a I2C controller and a spy controller in the PRU. So the Beagle bone has a lot of IO, the TI's the tar chip that's in the Beagle bone has a lot of IO but you might need more. You might want more I2C master or another spy bus. So in this case you could use this to then create additional peripherals using the PRU. And this project was to have the Beagle bone act as a spy slave. So usually with these Linux systems they're usually acting as a spy master but in this case it is to use the Beagle bone as a spy slave as part of a greater system. And one of the mentors actually Michael is in the back there. So if you have any questions about this you might want to chat with him later. But it was pretty interesting to see using the Beagle bone as something that is a little bit different than what you normally do with a Linux system. And finally I think the last project I'm going to talk about is another project from 2016 which was to add support for the new hardware that's in the Beagle bone blue. So the Beagle bone blue is a Beagle bone with hardware to make it good for doing robotics projects. So we have motor drivers, sensors, IMU, different things like that. So this project was to get those drivers working in the Linux kernel. So in Jason's previous talk he was talking about how a lot of the existing demo code for the Beagle bone blue is done in user space. So this project was to get that working with the device drivers that exist in the kernel. So I think that is all the projects I'm going to talk about today. The main thing to keep in mind if any of you are students, undergraduate or graduate students or you know graduate or undergraduate students they can apply on March 30th. I think it's a great thing and you get to work with mentors from the industry and you get paid and you create open source code that you can use in your portfolio and resumes and job interviews. So I would highly recommend checking it out. I think that was rather short. So if there are any questions, we can chat. Or Jason, do you have anything you want to add? I'm just looking for students also looking for mentors. Okay. So you're a professional. Yes, so we applied as an organization. We won't find out until next week at Beagleboard.org is going to be accepted but we are definitely looking for mentors. In addition to students we need mentors to help those students achieve the project goals that they want. And of course people don't have to mentor a big organization for GSoc. Yes, yeah. So there's, I think last year there was 178 projects. So there's all sorts of different projects. So hopefully whatever you're interested in there's probably a project along those lines. Oh, you were, okay, cool. So, yeah. Well, it's on the video. Oh, okay. How realistic is it for a student to spin up on a PRU project for a GSoc program if they've never done it before? They could probably depends a lot on their background. You know, if they've done low level programming before. Like microcontrollers. The one thing that's nice now is we have several mentors that were previously students. So Kumar Abashik and now Zubin who had done the Beagle Scope is now looking to be a mentor. So they'd be available for other ones. Yeah, yeah, so that's the great thing. And I think since Beagleboard.org has been in Google Summer of Code for many years now it's great to see that kind of succession of from a student to a mentor and then they're able to help out. And for us what we try and do is we try and get prospective students to join our IRC channel or join the mailing list and talk about their ideas and then hopefully kind of have a nice organic process where it's like, hey, I could probably be a mentor for that and the students like I'd be interested in this. So for the PRU I think we actually have a fairly good amount of people involved that have done projects with the PRU, especially the people that did the Beagle logic and the Beagle Scopes. So and for us in terms of the, I think the differentiating factor of the Beaglebone and the Beagleboard is the PRU is a big part of that. So in general, we're very keen to have PRU projects. Did you, yeah. I just wanted to try to address some of the technicalities of the complexity of the PRU projects. We made a transition and for Beagleboard, how we try to support the PRU use from UIO into remote proc and that was really on the push of what we thought the future of Linux was. It's about trying to do things in the kernel. So UIO is a way to simply memory map the entire peripheral and there is a user space library that uses, utilizes UIO to do all of the PRU management. But we were trying to, we did get away from that. So that's still, that UIO stuff is mainline. You can use the UIO library to load and run PRU code and there's an API for doing that. But I think for a while it got a little bit harder because we transitioned away from that. And so that did make for some of the documentation online to be a little bit confusing. It's really simple to, you create an ELF binary now for the PRU's and remote proc will load it, right? So you just put it into libfirmware and there's a couple of CISFS entries where you just poke and it will load it. Of course at boot time, it'll just, like you specified in the device tree and it'll just load it at boot time like it does all the other firmwares. But if you want to change it, you can just prod some CISFS entries and it'll reload and run that firmware. Now communications at that point, there's a RP message which is a pretty formal way of doing communication between the processors and that still, it's to be a little bit confusing because you have to have code on the PRU's to understand how to do PRU to do RP message. I think a lot of people didn't understand it. It's still just as simple as mim mapping the peripheral and using the shared memory space for communicating. There's nothing stopping you from doing that just because you use remote proc for the loader. So there's almost no API needed to work with the PRU's, right? Remote proc is not mainline at this point. It's, I don't know, there isn't, I think TI was doing another patch submission imminently. We do maintain it against the 4.9. So for Beagle board, there's one against the LTS kernel, the 4.9 LTS kernel for students doing development. But it's in and of those any day now things, the remote proc will go mainline. But UIO is mainline, but again, we think that the ultimately mainline will go away from that and so we're trying to get on the future. Cool. Sort of for the inside baseball. Was there something else that other points you had about Google Summer Code just meant that we were looking for mentors? Yeah. Yeah, so the question was what do mentors do? What are the responsibilities of the mentors? So the mentors are really there to help both before, so before, during this time after the organizations are accepted and the students apply, that's really the time where hopefully potential mentors and potential students will discuss either on my list or on IRC, what projects the student is interested in and also what projects would be good for the organization. So that's one of the times where there's a fair amount of activity. One of the things that helps a lot is if you have multiple mentors. So if it's just one mentor, it can be a lot of work for one individual. So we try and get multiple mentors for a project, especially with time zones involved, it can be somewhat difficult depending on if the mentor and the student are in different time zones. So it definitely helps a lot to have two or three mentors for a project to share that load. And I think then additional prospective mentors are less likely to be discouraged because they know it's not gonna just be solely on them. So, do you have any ideas on that? Was that, yeah. As being one of the administrators for our effort, we do try to distinguish between what we call primary mentors and secondary mentors and something because a primary mentor has the responsibility of defining the project and passing or failing the student. And we do expect a pretty strong commitment from that primary mentor. But we do look for secondary mentors to try to handle when that primary mentor is not available, somebody in the region maybe that can speak more clearly to somebody in a particular region. We do try to find people to overlap in time zones. So we're looking for a lot of secondary mentors. So you don't have to have that big pressure of like I'm the guy that's gonna pass or fail the student and I'm the guy that's gonna define what's in and out of the project. You can just show up and support it, right? It's an open mailing list, it's an open IRC channel. We try to keep the communication between the students and the mentors through those channels. We've experimented with Google Hangouts and even phone calls and other things, but it just doesn't scale to a community effort. We try to step them back to IRC. That's the way that we try to support the students. It works really well when everybody's engaged. And so if you can spend some time on IRC and on the mailing list answering newbie's questions and giving them some guidance, just do it. And we do ask for you, we do encourage you to kind of sign up, be accessible, let people know who you are, but it doesn't necessarily require a huge time commitment. We're just not gonna assign you a student if you're not gonna put the time in. The time commitment for primary mentor, the expectation on our part is the students are putting in 30, 40 hours. And so that the mentors would be available to answer a couple of questions every day, right? It's a multiple times during the day, so they would be accessible on the IRC for if the students get stuck. They can idle there, they can do their jobs and just answer questions, but they should probably allocate five hours a week. To the student, as probably a good eyeball figure. It's not a zero effort. One of the other things that is nice is, so in addition to the mentors, is you can also have people come in that have specific domain knowledge or skill in a certain area to help out. So one of the things I thought was really cool was with Beagle Scope, I think it was, or is it Beagle Scope? Okay, so it was using an IIO driver, so there's this industrial IO subsystem, Linus Kernel. So Michael was actually able to get the maintainer of that subsystem, Jonathan Cameron, to come on to our IRC channel sometimes and talk with the student involved with that. So that was really cool to be able to get, like, the person that actually runs that subsystem to come in and give some guidance. So I think there's kind of a range there, yeah. But for being a primary mentor, it's definitely a significant commitment, I think. And that's one of the things I guess I should have mentioned at the beginning about the students, is Google Summer of Code is considered basically a full-time job for the student, so like 40 hours a week, like every day working on it in the weekly reports are a big part of that. So it really is like a full-time engagement for the student during the summer. Do you have anything to add, Michael? Okay. If you do become a primary mentor, make sure you have a good secondary group because there's gonna be times when you can't be there for the student. And I picked up a lot of Slack this last summer and I think it helped a lot for the other guys. It really lessened their burden because these are like professionals. They have timelines and all this other stuff going on and these students can get pretty demanding. So if you have the time, it's rewarding, but it can be demanding if you're a mentor in the primary domain at least. So, yeah, cool. Thanks. Any other questions or comments about Google Summer of Code? Oh, okay. I guess if that's all there is, then we can, I think we ended with, you'll have some time left before the next, actually it's lunch, right? So I guess you can go to lunch early. All right, well thank you. If you know anyone, tell them to apply.