 Okay, so I'm Driftini. I'm one of the board members of the BeagleBoard.org Foundation. Jason Kreidner is the co-founder of BeagleBoard.org Foundation and The Beagle Bone. And Robert Nelson is the man behind our Debian images and a bunch of other of the things on the software side that make it really useful in easy use. Patches? Patches or patches? Yes. So this is the first time and I think we've all three been at ELC together so it was great to be able to get together and have a birds of a feather about Beagle Bone and BeagleBoard. And thanks to Frank for rescheduling this so we aren't up against the other buffs because I think we definitely have a lot of people that probably also be in the device tree buff tomorrow evening I think. So I just... Tonight? Tonight. Okay. All right. So put together a few slides but mainly the point of this is to have a discussion with y'all and see what you're interested in, what questions you might have. So one of the things to keep in mind is tomorrow morning we do have two talks. Jason's giving a talk, I'm giving a talk. So tomorrow we have a talk in the morning. Jason's giving a talk about educational robotics and I'm giving a talk about Google Summer of Code. And we also will have the BeagleBoard X-15 and the BeagleBoard Blue at the technical showcase tomorrow night. So I think the first thing I want to go over is we kind of have a nice ecosystem now of different Beagle Bones which you may or may not be aware of all the different ones. I don't know if you want to say anything about this Jason? So there's a logo licensing program. So a lot of people don't know. BeagleBoard.org Foundation is a non-profit foundation. For the details we're actually still working on our tax exempt status but I hope to get that straightened out soon. But it is a non-profit. We do fund the foundation through royalties of the logos. So there's trademarks. We do everything as open source hardware. We try to use open source bits anywhere we can. I think the only limitation is if you want to run 3D graphics which we don't even drive a lot of stuff towards the 3D graphics especially on the BeagleBones. There's some closed source bits there but we push all of our build scripts so Robert maintains that all of the stuff so that you can rebuild the images from scratch. And we try to support people helping us get code into mainline. So everything is open hardware. We make sure that we don't use chips that you can't get the documentation for that you can't actually go to DigiKey or pick your favorite distributor here and actually buy the chips and make the boards yourselves. We've been doing things to try to make it easier and easier for the clone. I think that's really different than a lot of other low cost educational Linux computers. So that's something that we do differently and that's a part of... We do need to try to do some things to fund activities with the foundation and we do that through local licensing. And so each of these different guys, if it's not a BeagleBoard.org product, well the manufacturers of those we don't have any manufacturing ourselves. Those get manufactured somewhere else. They pay a logo fee and then all these other guys pay a logo fee in order to put the Beagle brand on their boards. And then we try to do quality control as we can manage. As bugs get found of course. But of course we listen. The community is the biggest source of quality control. We don't block negative comments that come in through the mailing list and come in through the IRC channels. The only thing we've ever had to block is real hate speech, like religious hate speech. But if you mention competitors products, you say something negative, we keep that out there right for all time. And so we try to be accountable to the community. The other, so I also have our two... So this is probably one of the more recent products people may or may not be aware of. This is the BeagleBoard Black Wireless. And this was the first product that's using the Octavo system in package. So you'll notice that giant BGA there on the board integrates the processor and the DDR memory, power management and a bunch of other passives. The nice thing about that, that frees up board space. So this is actually a... It's a six layer board. But it's done in Eagle. So you could do this very low cost, you could make modifications to it. And by putting... There's 145 different components inside that package, including inductors and all the high speed stuff that you don't have to worry about laying out of your board. So it's a tool like Eagle could be used. Of course we have folks working with Kaikad doing derivative designs with the SIP as well. So we think this makes us a lot... This is what makes us special is that people can actually go and make these different variations of their own open hardware. And I just had... For our technical showcase where we have two posters up. So come to the showcase and we'll talk more about BeagleBall Blue and X15. And this is private for our friend EA, right? So I know this stuff all gets out there. But we try to be really open with our community. But the details of that isn't really public information yet. Yet the source files are on GitHub. Try to consolidate that in your mind. But we do try to manage the brand. We do want to try to make news when this stuff comes out. So we don't want to be putting all your blogs and stuff now so that the media feels like they're getting scooped. But if they just hang out and participate with the cool people, they know all about it. So probably one of the topics that hopefully people in the room will have questions about. And Robert can speak about is our Debian images. And what the current versions are and what's coming up next. So did you want to say anything about this, Robert? Sure. Just that, especially anyone that's using any of the wireless devices, make sure you have one of the latest images. There's a couple issues on November release, especially with Bluetooth. Otherwise, we try to have a full option for everyone, whether just standard IoT images or some kind of desktop, or just a regular console from the base, basically build anything. Yeah, these are the two main ones we push out to the users. We ship with the LXQT image for the Beaglebone Black and all the boards that have HDMI interfaces, so they have a full desktop on them. And then for something like the green wireless, we have an IoT image. We actually have a separate IoT image with a captive portal that Seed worked out. They just have one extra package now. So it's just one package delta, which is their captive portal page. It's kind of a nice tool, but it's a little bit... It takes a lot of resources. So I think the... I've got a question here. How many of these require 4GB and won't run on the revision A hardware? So the big one that requires 4GB is the LXQT image. I think it's shipping right now at 3.3GB, while the IoT will fit in the 2GB image and the console will fit there. We do have a 2GB image of the LXQT, but other than being built, it's not actually tested to see if it'll fit. But it should work. It should work. I haven't any complaints. Feedback on the list. The big item that is the browser, Chromium, it's like a 1GB package in itself, right? Yeah, it's mainline Chromium. That's only on the 4GB image. We stripped that out for the 2GB one. The IoT, I think, is a useful thing for a lot of people. I used to use the full desktop until you started doing the IoT. I don't actually use a desktop. I just didn't want to have to install the packages that aren't on the console version. I would almost just ship the IoT image, but it takes a long time for those that do want to install X to wait for all those packages to download. Bill? We need to give you a microphone. So your LXQT image, is that Wayland or X? It's still X, especially in Jesse. It's stretched. We're going to see what we can do. We have Wayland available, but we'll see. You do have Jesse Wayland builds, but not one of the standard build packages. Yeah, that's not standard. The main goal of that was since the SGX drivers, we do have our EGL slash Wayland. We could potentially actually have graphics on these, but it's not usable for users yet. We did get an amazing user contribution of 2D graphics acceleration for X-15 open source, so we're pretty excited about that. We do now have 2D graphics acceleration for the X-15 image. So the future for our images is WN9, which is stretch. Yeah, and some of the big things that we're going to change. A lot of the stuff we did in Jesse and Wheezy was for the old Inkstream group, and all the defaults it did. So we're finally going to nuke the root password above the blank, and we're also disabling SSH access via root. So that's going to catch some users off guard. They actually have to type in the Debian username we've been using for three years now instead of just root. And we're also nuke in the sudo don't ask for password option that we have set. Anyone who logs in as Debian currently, they can just type sudo in what they want, and it doesn't ask for password. So we're finally going to interact together and clean up how messy your image is a lit for... Don't consider this necessarily real security, but it's baby steps towards real security. And if somebody wants to do a real security audit, that we're very open to working with folks on that. Especially if they have patches. So right now, the current image is if you just do root at address, you log in, no password. So what we're changing, we disabled root over SSH, which actually is a Debian default. And when you're as a root, you actually say if you want to be a serial or as a console window, you actually have to type in the password root instead of just hit enter and go in. You still be able to SSH Debian at, but then you'll require type in the password, which it prints on the screen for you. So the bots have to be a little bit smarter. They actually have to erupt the screen. At least they have to be targeted bots. I mean, there was a botnet attack that went out back in October or September last year. That was the big one. So a default BeagleBone would have participated in that. Because it went around and just tried to log in, like it did root. It would SSH into nodes that it found and it would try root at port 22 password blank. And then it had ARM binaries that it would use to propagate the attack. So if you put an unpatched BeagleBone on the internet, what were you thinking? We know it's easy to plug it in, but... But yeah, it would have participated in that botnet. So at least this would get it off of that. At least patched enough to not do that. And one of the later things that we've done lately is we're actually... For a long time, we used Pentel's device tree overlay patch for building the overlays. We're actually now fully on mainline DTC. So we've backported that to our 4.1, 4.4, and 4.9 kernel. So the DTC that's actually being built in the kernel is mainline DTC. So all the overlays are... We're thinking forward to move forward. We didn't backport it to 3.8 though, so there's still two binaries. Yeah, the whole CAPE overlay manager. So he's saying that the mainline DTC requires you to do some extra content within your... Just specify that it's overlay, underscore, underscore, overlay, underscore. Yeah, that's going away. Since I know he wasn't on the microphone, I was just repeating the complaint. And for stretch, for planning, we're still thinking... We'll probably end up just shipping 4.4 by default, but 4.9 is looking pretty good. There's a couple things we've left to do, such as testing, but... Got a question back here. Thank you. Well, I will document the three lines in YouTube. Re-enable that, so... Because it's going to be a frequency-ass question. Yeah, I mean, we know we're going to get hit by a lot of noobs with this. I think Robert just said, it's like, we'll do it as long as I can blame you. And so that's blamed me. So any questions? It's Jason. It's just, you know, I get tired of going places and hearing from security experts that we're part of the problem and not the solution. And it's like, okay, I'll start listening. So the other big thing that we're doing here is... Is Maxine here by chance? Should I go forward to the U-boot overlay? Yeah, I was going to talk about that right here. So Maxine did a nice thing for the next chip when he got U-boot overlays working for that chip. And so device tree overlays can be done in U-boot, and we've kind of built on that process. Where right now, you can, with one command in our boot unit environment, you can actually do U-boot overlays by default with our images. It doesn't support all devices quite yet, but it's getting there. So I still think there's use cases for having runtime, device tree management. Right, so being able to... On Beagle's, being able to dynamically change the device tree at runtime, that's somewhat contentious. But at least... And so I still want to have the CAPE manager, but at least this actually eliminates the requirement for it for, you know, 95% of all your CAPE's. I mean, there's some devices that when we try to do it in kernel land, it just blows up, especially anything with video. So just pushing video to U-boot actually solves a couple of those problems. Because there's a nice big race condition there. I do find a lot of user error, and this is something I think needs to be worked on. If you mess up the environment variables in your boot environment, it won't boot and, well, go find a serial cable, right? It's... I don't think it's a problem for anybody here in this room, but for noobs, you know, it does get to be a challenge when their kernel doesn't boot and they have to get to the U-boot prompt. And depending what version of U-boot's in the UMC, it might load a flash file system so you can actually fix it. Yeah, that would be great. Yeah, sometimes. So one of the things is there's a bunch of hyperlinks in these slides, and they are on elinux.org right now in the ELC 2017 page, and they're also on the conference website. So if you want to click on any links in here and get to either the GitHub repos or elinux wiki, there's links to various pages on there, you can do that. Did you want to talk about any of the syntax, Straber? Sure, we'll talk about some of the syntax. The main thing is with the old 3.8 kernel, you've always had disabled UMC, disabled HDMI, and disabled HDMI audio. For the overlays, we've added quick clicks for you to actually do the same exact thing, and we've also added the wireless option, because some boards, like the big old green wireless, some of those pins are actually used by the Cape. So the black wireless doesn't have that problem. And then we've always had, you could add load four capes. So we have four overrides. So if you have a Cape that has a wrong firmware name or something, you can redefine it and load a different one. And then plus one more on top of that. At this point, we're still not doing any eProm reading? The first four we're doing eProm reads. Okay. But it turns out not every Cape has eProm. Yeah. And if it does, it was never written to. Small issues. And the goal of this, we don't have this completely done yet, but it'll load Cape Universal at the end too. So all of the config pin options will still work. I think there's probably still some more granularity that needs to happen here such that it'll load a helper. So thank you very much for helper functions, Penn Tell us. But for every pin that you could, Mux, I don't think that you could get into situations where it won't necessarily load the helper for it. So we want to have a helper for everyone so we can get back to where we were in 3.2 Kernel land. So I think one of the things, Robert, you had mentioned on the mailing list was for people to test out their Capes with this? Yeah. The main thing was if you have a Cape that, let's make sure it works. I mean, I got a bunch of Capes, but there's so many in the field that have been built in the last three years. And this is a big migration from, well, we don't work in the Kernel, but does it work with overlays with Uboot? And one of the big things in Uboot, we want to detect the Cape and say, OK, these pins are now can't be used. We really have to redo that whole database. How do we want people to communicate that on the mailing list? Either the mailing list by email or by the GitHub account that this is on. The B.B. Overlay is where all the DTBs for the Capes. So that's the bb.org overlays. I mean, since really 90% of the Cape support is just the DT overlay, this is where we're expecting all the Cape support to be. And right now, this supports 4.1 all the way to 4.10. So we've forward ported most of the 3.8 Capes, but we didn't have all of them to test. So that's mostly just user-tested boards, Capes we had. The wonderful thing to me about having the overlays in Uboot is you actually get on your LCD, you can actually see the boot screen now. And that worked in 3.8, but has it worked since? Yep. So that's the end of the slides. So hopefully this is some useful links for people. If you go to the slides, you can click on these. But do you have anything else, Robert, or Jason, that people should maybe go to if there are any other useful links or anything like that? Information? Yeah. The board githubs, each one, there's a hardware github for each of them. On some of them, I'm moving the system reference manuals into Media Weakie and using the github Weakie. So starting with the Beaglebone Black and contributions are welcome there. So the system reference manual at this point has been converted to Media Weakie. And just trying to make it better to get to that documentation online rather than just a massive PDF that you have to kind of go through today. You already have to go through a 3,000 page PDF for the technical reference manual for the processor. Do I want to go through another 300 pages for documentation on the board? Let's put it on Weakie and manage that content a little bit better. So there's more githubs there. If you go to the github.com slash Beagleboard, there's a number of useful repos there. Pretty much everything we do is on github. So if we're missing something, we obviously missed it then. So that's kind of the end of the outline. Looks like we had a question out there somewhere? Somebody who's helped just get some good Debian patches upstream. Thank you very much. Okay. So yeah, I'm Begrant Cascadian. I work on Debian and I've worked at the Uboot maintainer. And I worked on helping getting Beagleboard switched over to Debian. But there's also this divergence that's still there or still happening. And I don't know if there's some strategy or plan or way we could work together to reduce the divergence with Mainline mainly because then I can just pull it into Debian. And then I was also really curious of the overlay support. Is that with Mainline Uboot or is that with a patched Uboot? These are questions I have. So when you talk about divergence from Mainline, are you talking about kernel, Uboot, or Debian? Yes. Yes. So we'll start with the first one. With Uboot, Maxine did most of the work on that. So in Mainline Uboot, you just have to enable a config and the overlays will work. The manager, however, was not there. And right now we have a, it's a work in progress patch. And that's one of the ones we leak on here. It's like, here's the current version that we're using. It's infant. It does a couple of quick hacks. So right now it's getting to a point where it's usable and when everybody's happy that it's usable, we'll push the patch, right? You'll push the patch? Yeah. I was praying. I was praying some Google Summer of Code student would be quite interested in doing this project. Yeah. Uboot maintainer Tom. Yeah. That's a goal. And as soon as 4 to 11 RC1, I actually have two patches for you. Green wireless and black wireless. They're going to go Mainline. So on the kernel side, you can, the Mainline kernel for this board is actually really well good. The blue hasn't been pushed yet because it hasn't been released. X15 is pretty good. I mean, if you're doing static, static DTB, because really that's the only thing you need for Uboot, like going back to Uboot. The only thing you need out of that's not in Mainline is overlays for capes. If you're doing a static DTB, Mainline Uboot works fantastic. Now you've got a crazy script to try to do by default that you patch in to kind of boot from all sorts of different sources. And a lot of that's compatibility for images three years ago. So for a Mainline, that doesn't matter. Because the first thing we do in our Uboot patch, we actually do the Xcon Linux option. So if it doesn't detect that, it goes on a crazy script. Considering I got another patch for 3.8 last week, probably never. But for the average user, Mainline Uboot works fine. I know whenever I'm doing any development, I just go back to Mainline. If I'm doing any changes to Uboot and want to see it, if I'm recompiling, I don't apply the patches and then move forward. I just go to Mainline and then move forward. I've never had any problems getting the kernel, the boot, and everything to work. Mike. Mike. Recorded. Yeah. The question, who is currently maintaining the kernel for the Big O bone board? Robert is the maintainer for the kernel for the Big O bone board. Robert, you want to talk from this and I can carry it around the microphone? Yeah. Well, I mean, here's the question. I tried to build like a playing vanilla kernel for a Big O bone board, so I'm configured for RAM processor, bring up those modules, and it's never worked. So what did I do wrong? I watched DevConfig. Mainline OMAP2 DevConfig will boot the board just fine. Oh, it is. And Multi, I think, works too. I just don't do it on my build farm. OMAP2, that works out of the box. Okay, thank you. So you were doing something other than that, so first thing to try, right? You have something to go try, right? Yeah. Okay. Tony. So what kind of kernel patches do you still have? What's the leaves that currently compared to the Mainline kernel? It's getting smaller. What do you have to do? The main PR use and what else? Yeah, the PR use still is the mainline for our situation. I know, too. UIO is the mainline, but we're trying to move forward with remote procs, since that's what we're understanding is the direction from the kernel maintainers is the remote proc is the way to go. Yeah. Our biggest patch that is still Pentail is Cape Manager. Other than that, it's just hot fixes. There's a couple of little drivers, the ECAP. Yeah, the ECAP driver, the X15 2D acceleration patch, which didn't get in quite yet. We've got to wait for some hard of order mod clock changes before that can go back in, so. And that's pretty much it, right? Is there anything else that we have out of Mainline? Yeah, that's pretty much it. There's a couple boards. The blue, of course, isn't on there. Blackwater has got merged. But the blue is using a Wi-Fi driver that's already Mainline. So it's really just DTB, and what else is actually in the kernel? Is there anything else in the kernel? Yeah, just mostly device tree patches. Yeah, I mean, we need to clean up our Mainline device tree, right? Because we are one of the few boards that are supported by Mainline device tree. So our device tree is there. I don't want to lose that status. It's a nice place to be. And then a lot of our patches, too, is different modifications, like board-of-out EMMC, board-of-out video, board-of-out audio, all the different files and combinations you can have. And so those won't ever go Mainline, but users want options. I've been trying to get hold of an X-15 for quite some time. That took, man, did we seriously go 32 minutes before that came up? Oh my goodness. Yeah. All right, X-15 will happen. So we had a... I'm being recorded this time, I'm answering. Ask me again when I'm not being recorded. We're transitioning the manufacturers, and we're still trying to get the new manufacturer going. They really just want to try to get as many orders consolidated from distributors as possible so that they can have the lowest price, right? So it's been a little bit of a chicken and egg in doing that transition. The guys are still learning how to work with the different distributors. Most of the recent months have been just getting them set up in the system for all the distributors to place their orders. But they haven't gone out and really started doing the builds until they get the orders in. But all the major distributors are still on board and are putting orders in. They're not... The guys building it are waiting for that PL. Actually, when I originally booked ELC, my thought was I'm finally going to have X-15, so I have to go to ELC, right? Because we pretty much built the X-15 for this crowd. And I don't have it. So believe me, that's not more painful for anyone than me. Oh yeah, we brought one to show. And yeah, we've gone through... It's passing FCC, so the long-winded fight of getting through FCC is done. That's not an issue anymore. We are... We're making a transition from PG-1.1 to PG-2 silicon because by the time we got around to actually building it, the PG-1.1 silicon wasn't even available anymore. So we're moving to a process update. So when it does release, it's going to be called revision C. Yeah. But it is happening. We're essentially... Ten weeks out from when the distributed orders all get placed, which is imminent. It's kind of a checking day-to-day thing, so I would estimate it at about three months. President Bright said there's less bugs. And we've had user contributions of open-source 2D graphics, acceleration, and... Open CL, I mean, it's going to be a nice box of bugs. Any news on upcoming hardware for this year, including anything from Octavo? The new hardware? Probably the blue. Oh, is there any new hardware this year? Any hardware new this year? The bigamoon blue is imminent. The information... We don't really have permission to share the information that we're sharing here about the details of the bigamoon blue. But we try to work very open in our community and hope to ask for forgiveness later on. So that is going to be coming soon, and we'll have some demos actually out at the showcase. That's going to be in March timeframe as actually a product? I wasn't going to say, but... Okay. If any of you are in Germany next month, I'd pay attention around that timeframe. Yeah, that's the city. Anyway, there is more stuff coming. We did some other things doing with the Octavo SIP, doing some other fun things with that. There's a gentleman here who's done a community hardware project, not an official Beagle board project, but I think it's really interesting because it's... I'd started a hack called the pocket bone last year, and it was done in Eagle. So a lot of people really want hardware developed with open source hardware tools like Kaikad. So he's taken the pocket bone design, re-implemented it in Kaikad, did a real layout. He added a couple layers to try to get signal integrity on the USB that I'm not too worried about, but that's okay. Four layers versus two layers is not too bad. But now it fits inside the mini Altoids 10. So you're really pretty simple, because you throw a couple crystals down and some resistors. There's even room for some buttons, and it's got a couple USB connectors on it. And I've got some assembled units coming March 8th. So we'll find out then exactly if it works. And again, we're just... We're running this as a very much an open community project, and we're pretty excited about that. I think that Michael's even going to try the... I'm going to commit you to that toaster oven assembly. That's one of the things I'm excited about. So the pitch... We had one picture there with the Biglebone Black Wireless, but if you look at Octavo Systems' website, you'll see a picture of the system and package. And it's a huge pitch for the balls, which should be large enough that it should be manageable for a skilled electronics hobbyist or engineer to be able to hopefully use a stencil with solder paste in a reflow oven at home or in their lab, be able to do it on their own. So I don't think anyone's actually quite done that yet, but hopefully Michael will be one of the first people to do that and show that it's possible to actually assemble your own Biglebone clone at home. So you tried assembling the Octavo Sip onto a board with a toaster oven? There you go. I did a two-layer board, similar to PocketBomb, but a little bit different, and it didn't power on at all. It didn't power on at all. Take the mic away. If you copied mine too close, which I hope you paid attention to the GitHub issues list, I actually swapped the placement of a couple of crystals. I only got followers at all, actually. It was just kind of similar. I went through the Octavo page of here's what to try to do, and I made the seven external connections between the balls, because I'm assuming it's something I did wrong with the PMIC, or it's maybe my reflow. It didn't work, but I ordered another one, so I got about $150 in it. When I get home from this, I'm going to try to reflow the other one and see if it works. Okay. I got a stencil from Osh Stencils. I got a board from Osh Park. Hopefully it'll work once I get back from ELC. There's really not much of an end. You get to the different colors. It's kind of hard to read the silk screens, but there's a lot of colors in the rainbow. As far as layers go, because I'd like to try that as well, I don't know if it'll be a pocket bone or, and you're saying more than four layers. What are the other two-layer designs of the lineup? What's realistic for us to create? With the SIP and with the AM335, I'm not aware of anybody that's gotten a two-layer board completely functioning. Four layers seems to be the fewest anybody's got. The Beaglebone Blue design prototype, I don't know what I could say, to make it less official, but that's four layers. It passes FCC, and we're good on four layers. I've had a number of people using it for a few months now, and it seems to be rock solid. It's a question, how few layers can you do? I have a Volterra printer that prints silver traces, so I can't do sandwich epoxies and stuff. I can't do more than two layers. I think that if you... USB is really the biggest concern in terms of traces on there. It's the highest speed signals that come off. If you... You could do six more traces in six more spaces and route two traces in between the balls if you can get the spacing right in the design. So there's room for that. You should probably just use a thin PCB and put a plane on the other side. So don't use a full thickness FR4 board, but if you can get one of the ones that's essentially like a single thinner board, you can probably get the sort of signal integrity that you're looking for. You probably don't want to do the full thickness, just because the ground plane should be too far from your traces. I think it's going to work fine. Keep the traces nice and close together. They're going to have a return path. The single-ended signaling isn't all that fast compared to the differential signaling. I think it's going to be fine, but my board didn't work. Not really. I haven't finished yet. I just use a four-layer board because I'm kind of spoiled. I've been doing printed circuit boards for a while now. I get the mic a little closer. It's a little quiet. That's just what I'm used to is having the two plane layers, and that's what is really recommended for USB routing. You can get away with it, but I felt bad trying to sneak between the pins, especially with the BGA pattern that we currently have in KiCad. It's actually not quite getting two tracks between the pads because they're a little bigger pads. You can tweak the pattern if you want to try that. To me, it's kind of triggered my OCD a little bit, and I just went ahead and routed it in four layers. I do actually have, if you look at the history in my repository, I did get it to route in two layers. It has a slightly different layout. If you want to go back and look through my KiCad repository, there is a routed version that uses two layers. I don't know if it'll work or not. There's that. On mine, I literally spent, I think it was about three hours between part creation and grabbing things and actually running the USB traces and clicking Auto Route. Yes, so not trying to claim it was a quality design. When it didn't work, I shouldn't be too surprised. That's why I was really happy to see Michael picking that up and doing a quality layout. My strategy at this point is let's see his work, and then I come back and strip it down to two layers and try again. Hi. I was wondering how viable was it to just put a Beaglebone in a commercial product? It's extremely viable. A lot of people do it. That is not my endorsement. There's liability issues when you come to making consumer electronics and you don't actually validate it for your application in a real way. That's true if you build off of a Beaglebone, you build off of a Raspberry Pi, you build off of any off-the-shelf board that doesn't have an engineer at the company claiming that it's suitable for this particular purpose. It's almost impossible for us to do that without having some sort of customer engagement. And guess what? I don't do that anyway. There are other companies that go and do that. I know people that will help you validate the use of Beaglebone in a product. I know a good number of people that do that. We don't have any restrictions. I know that Gerald's come out on the list a lot saying that just don't do it. There's no legal restriction for it. But there is a disclaimer from our part that we're not responsible if you go killing somebody because you made a defibrillator and it wasn't screened for ESD. The first time you shocked somebody, the board blew up. It's viable. I know that a number of people just buy them off the shelf and a number of people do derivatives. I think it's helped build a lot of business for TI and it's been a very successful processor and I think a good part to Beagle and the ability to simplify people being able to get to market on their own. Very much want people to prototype with it before you go into production. Think about what you're doing. You should get an engineer to think about it. Don't think you're going to do things without an electrical engineer when you're making commercial electronics. Thank you. Three minutes maybe. If you could recap. You talked about Debbie and Upstreaming and you talked a little bit real quick off-mic. If you could just talk that through a little bit more. Sure. As far as the Delta with Debbie and right now a lot of the patches in the GSC image were just backpourts of stretch. Basically we needed a good desktop and LXQT was... The one we've used in Weezy was pretty much going into life so we needed something and the goal was if we use QT there's a chance we might get SGX graphics working. That didn't work of course so that's why we went LXQT route for this last image. Almost everything's in Debbie now. There's still some things missing. We still have our U-Boot patches of our own. There's also a collection of just kind of random utility packages that we have. I think there's the Y-Link firmware package that is kind of oddball and we've had some complaints about it but in terms of we're going to make the changes to try to make it easier for that to be a main package. There are several that just pull down Githubs and just repos and builds them like the Cloud9 IDE. We have three documentation packages. They just pull in an image file that loads up on the user's desktop so I know Debbie would not ever accept that. So there are a few oddball packages that are really just ways to trigger install scripts. Are there any Beagle board specific packages that you've created that you've successfully pushed into Debbie? Would you have an idea maybe what some of those might be? We still need that working mainline though. That's the big problem. The UIO driver is in mainline. It supports the L138 out of the box but the Prosperz N2 TI wants to push remote proc so while the community is using UIO we're stuck in a hard place right now. Things like the compiler. There is a GCC compiler but we still ship with the TI compiler that's covered under a freely redistributable license but the Debian package for that for example it triggers a script that downloads the package from TI and then runs the TI installer. Does that make sense to go put into a real Debian package? I don't know. We've got some utilities that we put on just like op-sources, things like a Beagle tester. We're trying to do more to share the ability to replicate our testing, our hardware testing so that people could use that when they make their own variants of the boards. There's a package called Beagle tester. If you plug in a USB scanner for 2D barcodes and something pops up, you just found something cool. The Beagle tester goes off a USB scanner so if the screen changes all of a sudden you just discover the test script. It's a UDev role, it triggers the test script. But embedded in that is a whole production programming thing so you can have a lot of fun with it. Patches welcome, there are more things to test. I did actually get Debian installer support working on the Beagleboard X15 but I get the impression the model I have is of a relatively small number in production and the new UBoot images may not work. Is yours an A1 or an A2? I think I got you an A2 and that would be fine, it's not going to be an E. So my question was basically should I pull that support for stretch or is that useful enough if people get the RevC or whatever is that going to catch fire if they try and use it? There was about 200 or 300 of the A2s actually sold in Europe so there is 200 or 300 of those boards out in the market right now. They exist. The A1s are the only ones we save burn with fire and talk to your TI contact and get replaced ASAP. I'll leave it in. It's all good, that'll work. The production again though with the B revisions. C. Gerald wants to up it because we went from PG1.1 to 2.0. The board is the same as the RevB but because the processor revision change he wants to call it RevC. So what do we do with the mainline file? Because it's revision B and mainline right now. Patch it. So the most likely difference between RevB and RevC is going to be that we'll want to have a new U-boot because there will be new IO delay magic that needs to be applied for optimal functionality but that is most likely to be hit. Because it is a different piece of silicon it will have a different IO delay parameter set. Yeah, so when the time finally comes it will be time to say, well we need to update U-boot to whatever one has the correct IO delay information for that silicon as well and everything else really should be the same. From a board level standpoint it should all be the same. So loading the RevB DT should be fine and I think that is normal best practice that we won't need to introduce a new named device tree until we actually have it. Let's save ourselves some work. There's IO delay timings in RevB right now. Is that in the device tree though? In our version it is. I don't think mainline has it yet. Alright, maybe a little more to sort out. If you have to push IO delay information up in the device tree then yes you will need to have one for RevB and one for RevC and we'll have to do the runtime detection to say do this or that and how well. So how many RevBs do we ship? Zero. Oh, we're good then. Alright, I think unfortunately we have run out of time for this Birds of a Feather but all three of us will be around through the end of the conference. We have showcase and two talks tomorrow and now you know what we all look like so feel free to come up to us and talk about anything Beagle. I have some Beagle stickers up in front if you want to grab any on your way out and thank you for coming.