 Hi everyone. This is Tim Bird. I am a principal engineer for Sony and I, I guess I'm an embedded Linux expert. I've been doing Linux for about 25 years now, embedded most of that time. And so I'm here to answer your questions. And so if I don't know if anyone's out there or not, but go ahead and fire away and we'll have a little ask the expert expert session. So let me just click on the Q&A and see if see if anyone has something they want to talk to me about. So just while I'm waiting for people to formulate questions, let me just toss out some information about what's been going on recently. So I have a couple of sessions at this conference. I've been working with TimeSys, Sony and TimeSys have been working together on some board farm related software. And I've got a talk on Tuesday. Yeah. So I have a couple of different talks. So I have a talk on Tuesday on that topic. And then on... Oh, how did that? I got my first question. So I'll get back to that. My other talk is on compliance, license compliance, and that's on Wednesday. And then I do the closing game. So the first question I've got is, how did embedded Linux conference get started? So actually, before the Linux Foundation existed, there was an organization called the Embedded Linux Consortium, which was also called ELC, by the way. But that was a group, early, early people in the embedded Linux industry got started, TimeSys and Monovista and Linio at the time. I was at Linio. And we started having meetings, talking about this, and then eventually activity in that form wound down. And I was recruited by Sony. This actually ties into a little bit of the next question, which I have here, which is, tell us more about the open source journey with Sony. So I'm answering two questions now at the same time. So I was hired by Sony officially in 2003 to start a new trade association, the Consumer Electronics Linux Forum. And so that organization started by having like some requirements meetings. And we also started having some, we put together these technical working groups, and we had technical working group meetings that we would have, like every six months, at different places. Well, in about 2005, we realized we were having all these technical meetings that was isolated from the community. And we thought, well, that's not the right open source model. So we switched and had started to have an open conference. The first year we called it Worldwide Technical Conference or something like that. And it was a combination of these technical committee meetings that were on topics like real time. And I was at the time, I was the chairman of the boot time working group. And then we had a size group and a security group. And anyway, so we started inviting community members. And that was mostly hosted in San Jose. And from that, it just turned into an open conference. From then on, in the early days, it was hosted by the CE Linux Forum. And then around 2010, CE Linux Forum kind of got acquired or merged into the Linux Foundation. And so that's where it started. So we've been going since 2005. So we're 15, 15 years now, which is pretty amazing. Getting back to Alexander's question, tell us more about your open source journey with Sony. So I was hired by Sony originally to start this trade association, the CE Linux Forum. But I had Linux experience. And I had been, I had been the CTO of Linio, which was an early embedded Linux company. And so I had experience with the kernel. And I found myself also consulting with product teams on how to add certain features, particularly since I was a boot time expert at that. By the time I finished with the CE Linux Forum, I did a lot of size work on Sony cameras. I did actually ended up maintaining kernel for one of the product teams that was used heavily in some of the visual, the camcorder products. And then that's, it went sort of, from there it developed into all kinds of stuff. And so now, unfortunately, I don't do a whole lot of kernel coding. I used to do a lot of kernel coding. But nowadays I'm doing, I'm focused on automated testing. And I'm on, I do like help Sony with compliance issues and stuff like that. So that's my two talks at this conference. So the next question is from Michael open accurate. He says, what hardware are you currently working on? And so I have right next to me, I don't know, should I, should I, this is a bad idea. But right next to me is my lab. So I've got a bunch of boards here. You know, if you've ever seen a hardware lab, you know, this kind of stuff looks like, sorry, that was all fuzzy. And I don't know if, and now I've messed up, you know, my own setup here. But so I have a raspberry pie, I have a beagle bone, I have a middle board, I have like arena sauce board. And I'm not, I'm not actually testing those boards as much as I am testing the tests for those boards. So automated, automated testing, I found that there's a lot of issues with, with automated testing systems. And so a lot of these boards are actually kind of running older kernels. I'm not actually doing like upstream testing at kernel CI is doing, I'm the maintainer for a project called Fuego, which is an automated testing suite, and it's used inside Sony and inside some other companies, I know Fujitsu uses it and Toshiba, Toshiba has used it. And it's got a little bit different spin because it's not targeted upstream, it has some of the features are a little bit different. So what I ended up doing is I'm testing LTP and I'm testing case self test. And so I make sure that they run on this wide variety of hardware, I have compiler, it's cross compiler two chains for that. And then the project I've been working on recently with, with time says has been about board farm software and managing board farms. So it's a little bit of a meta project, it's, it's not the hardware, it really doesn't matter, you know, it probably matters to the Raspberry Pi and the BeagleBowl people, but that's not that critical for me. So but that's my hardware, I've got a lab right here in my, in my basement here. The next question is, hi, Tim, are there any follow-ups for the automated testing summit planned at the moment? And that is a really good question. So for two years, we had an event called the automated testing summit. And I thought it was really good. But one of the things that kind of, well, we're trying to create synergy between a lot of different testing projects. And one of the things we found is that we had some good participation from the embedded people at automated testing summit, because it was always co-located with the embedded Linux conference. But we didn't get as much participation from some of the other areas of the ecosystem, for instance, the enterprise guys and the distribution vendors in particular. And so we've started, we've kind of shifted and now we're just piggybacking some of our stuff for automated testing on Linux plumbers. So Linux plumbers, unfortunately, well, so there isn't, there's a testing and fuzzing microconference that happens at Linux plumbers every year. And this year was where kind of the main action for automated testing was happening. So that's not to say that there is not still collaboration and cooperation going on, particularly at ELC. I think we have about four or five talks on automated testing at ELC. So you can consider it kind of an embedded track, although it's not broken out as one. And so that's kind of where it's happening. Right now it's happening at plumbers and there is a kind of embedded sessions at individual conferences, but we don't have like, we may restart it if it kind of starts to get big enough, but it didn't seem like there was enough the intersection of people at like ATS to get all the right people involved. So the next question is, what is the fastest you have ever booted Linux and what techniques did you use to achieve it? So I, although I'm not intimately working on on like an actual product at the moment. So I used to work at Sony, I used to work on let's see, I worked on camcorders, worked on Blu-ray players, worked on TV sets, worked in mobile phone division for a while, but when we were doing cameras, boot up time was a really huge issue. And this was probably at least 10 years ago, but the best we ever did in the lab, we were able to boot a system in 180 milliseconds, so 0.18 seconds. That was a toy system that was all stripped down to its bare essentials. The, in a production environment, the cameras, our goal with the camera was to boot it in under a second because nobody likes their cameras to start slow, right? So I don't know if you've ever fiddled with your cameras, the cameras on the cell phones are terrible in my opinion, they don't come up fast. But anyway, so our goal was a second and actually in production, I used to do a demonstration where we could cold boot a video camera, Sony video camera, in fact that one right there on, that one is a video camera right there, that's the one. We could cold boot that, take the battery out so it's no power applied. This is not suspend, resume, which is what a lot of cameras are doing these days, but put the battery in, turn the on button on, and you'd have the video and the camera mechanics already in a half second. And so we thought that was pretty good. So another question here, any hints for submitting ELC and ELCE, ELCE Europe talk proposals? Yes, I do. I have strong opinions on this. I've been the chair of the committee, I guess since its inception, because we've always moderated, well, since we started moderating, I've been moderating the talks and selecting which ones to accept. And sometimes it's frustrating because sometimes you see that someone has kind of a good idea, but the abstract is not good. I don't know how to put it any nicer than that. So sometimes you'll see about the most common problem that I see is people will spend too much time describing the problem and not enough time on what their talk's actually going to be about. So this is a really quick answer. If you're going to submit a talk to a conference, make sure that you have some details about what the actual talk is going to be about. So a lot of people spend too much time on justification and then kind of wave their hands and say something like, oh, and then I'm going to present some solutions for this big problem I just described. So like, well, no, not some solutions. Tell us what are the solutions that you're proposing. And if you have some data, go ahead and don't save it for your presentation. If you feel like you're doing a talk on boot up time and you were able to save a half second through some technique, say, I use this technique and it saved a half second and I'll describe that in the talk. So be specific about what's going to be in your talk. I think that's really important. And so I'll just leave it at that because there's some other questions here that popped up. Okay, is there any general technique to debug any hardware or interface related issues into bootloader or grubloader specifically into Linux? I am not sure exactly the nature of this question, but I think you're asking, I think you're asking, is it possible to debug the bootloader using techniques as it transitions into the kernel? Or use kernel features to debug the bootloader like grub? So yes, the one big thing I'm more of is there was some work done to be able to pass the tracing buffer that's used in UBoot through to the kernel so that after the kernel is booted you could use kernel tools to go look at that tracing buffer. I don't remember the details of that, honestly, so I am going to have to just pass on answering the rest of that. There are some other, obviously, when you transition between the bootloader and the kernel, usually the bootloader has control of the serial console and then it transitions to the kernel. So there's some other techniques you can use to have the kernel in that data. So there's something called the protected ramfs where the bootloader could store some data and the kernel could then pick up that data. So that's another mechanism for passing data that allows you to debug the bootloader through the kernel. Okay, another question. What do I think about robot framework as an automated testing framework on embedded Linux devices? Any other suggestions as automated testing framework? So I am not sure what you're referring to as robot framework. If there's a specific automated testing framework called robot framework, I am not familiar with it. I thought this might be about robot operating system, but it seems to be about testing. In terms of an automated testing framework, well, you're asking someone who's completely biased because I work on the Fuego system. So I would recommend Fuego, of course. But having said that, the industry as a whole for upstream testing, the industry as a whole is moving towards kernel CI and lava. And so just as an example, the project that I just did with time sys recently has to do with extensions to lava to add board and farm management capabilities to lava and the lava console in particular. So I don't have my own project that is not ready for prime time. I'll describe it in my talk, but I have my own project that that does board farm management. But I think you can't go too far wrong if you get on the lava bandwagon. But of course, I would love you to join the Fuego community. The Fuego community, I'm trying to get the two kind of hooked up. And so this actual API thing I'm doing with time sys is related to that. Here's another question. Does Linux have a future in deeply embedded systems less than two meg? And whatever happened to the Linux tiny project? So no. And it pains me to say that, but I don't think Linux is going to do very well in the two meg market. We used to do a lot of work on that. I did a lot of work on the Linux tiny project and we hired Matt Makle, who I don't know if you know who he is, but did work for many, many years on reducing system size in Linux. And I just don't see it happen. The forces inside the kernel in terms of trying to stretch the kernel to fit all these different niches, it's just gotten way too hard to trim Linux down into a two meg system. So unfortunately, I think that means we're going to miss out on a lot of IoT opportunities. But there's plenty of other space from, I think, from about four meg up to, of course, super computers running with terabytes of memory and stuff. I think those are handled by Linux pretty well. There's one last thing. Last question here because I'm running out of time. Could you elaborate on how the community could contribute to the Sony Xperia Open Devices Initiative? Wow. I don't know if I should have accepted that one. That's a big question. So Sony has a project called Open Devices and it is, it allows you to unlock Xperia phones. And so you have to be pretty knowledgeable to do kind of real work in that system. But there are people who do it. There are people who make ROM images for phones. And so if you want to get involved with that, just use that as a search term, Sony Open Devices or go to Sony Developer World. In terms of getting involved, we're always interested in people just giving us bug reports or giving us feedback on how the tools work and whether we can improve those. So unfortunately, well, I don't know, maybe I have, I think I have time for one more. So I'll just do this last one. What are your thoughts regarding Xperia as an alternative to Linux for embedded RTOS? I think Zephyr is great. So I have to say that cautiously because Sony is actually using NutX and I'm sorry if you're a Zephyr fan, we happen to have invested in NutX. I don't think we need to get like into like RTOS wars. But I think Zephyr is a really good solution. I haven't played with it a lot myself because I'm not kind of in the RTOS space. But I think that it has a really good chance. The reason that Sony went with NutX is that we like the posits compatibility. And I think at the time that we made this election, Zephyr didn't have that. But I think that's changed. Anyway, I am running out of time, but I appreciate all the questions. And I hope to see you around the event. I'm still trying to figure out how the chat stuff and all works. But hopefully I'll be able to communicate with you more as the event goes on. So I'll talk to you later. Thanks a lot.