 Okay. Hello everyone. My name is Artem. I'm from Global Logic Ukraine. We are working on embedded software, Linux kernel, all kinds of wireless networking and so on. Our company is mostly a technology services company from Silicon Valley in a few locations. And I will talk about the use case we had with what we call Nautilus. It's an automotive-grade Android with Xen as a basis for it. Basically, we were trying to resolve major goals that are causing problems right now. In automotive work, we were aiming to create the automotive-grade Android distribution. It's not like the distribution like Fedora or whatever, but something that vendors can use to accelerate development of Android apps for the automotive market. And our desire is to create a single platform that leverages all the AGA, Genevieve, Linux, Xen and other open source stuff to simplify and reduce time to market for end-to-end IVI products. IVI is in vehicle entertainment. And we decided that Xen is going to be a key component of this solution. So, why virtualize in automotive? If you need an answer for this question, currently, there's a lot of changes coming to the automotive market. First of all, everyone wants to shorten the time-to-market cycle for the software in the automotive industry. Recent few years, there's a new connected car concept when all the car services are connected to the cloud and you have a way to monitor what's going on with your car and probably even your car service are able to see what's going on with your engine, whatever. You also want to deliver third-party applications to your car, like Facebook or whatever, and do the cost reduction for the in-vehicle-of-attainment system development. I've been a few weeks ago on the Genevieve conference and John Ellis from Ford said that currently the Ford Sync software is over 10 million lines of code. Probably some of you use Ford with Sync installed. If someone uses, please raise your hand. No, no one? Oh, no, there's one person. Okay, and with time, we will see that there will be some kind of custom applications to be added for the cars, navigation, radio, streaming, the connectivity. You know, everyone wants to read emails while driving, maybe with text-to-speech or whatever. Don't text while driving, but anyway, I wasn't telling you that. Everyone wants to post Facebook posts while driving, do Twitter's, wash your own favorite videos, play Angry Birds. Everyone wants to play Angry Birds, right? And of course, post the photos of the just-rived car. All right, so when we have all this kind of stuff installed on your phone and you're installing more and more and more each day and sometimes your phone freezes because of that, because some software is not very reliable, the operating system is not very reliable. So what happens when you have that? You just reboot your phone, you don't care, right? What happens if you have all that crap installed in your car? It's nothing funny. So we decided to think of what's critical and what's not critical, right? So, yeah, vehicle software, we call it critical stuff, right? Usually, vehicle software is powered by the QNX or some ODSR OS, or maybe automotive, no, no, no, no, not now. And it is responsible for mission-critical stuff like con or most, or some lean bus or climate control, vehicle services, diagnostic breaks, whatever you can think, maybe driver assistance in the future, right? And also, there's an infotainment software, which is not very hmm, mission-critical to say. It can be powered by Windows, like Fort Sync or Android in the future, probably. It handles the user interface, text-to-speech, speech recognition, whatever else, phone connection, wireless hotspot navigation, cloud applications, multimedia, everything, which is not, as I said, mission-critical in your car. If it breaks, you will not hit the tree, right? So, yeah, that's kind of why we want to, why we decided to go with virtualization. Now, if you're worried about virtualization now, we had very nice presentation by Samsung, and I think there's no, no doubt that it's possible and it's doable. That's the slide from the ARM presentation. I just copied it to remind you what we have in the architecture. I use it because, you know, in the future, I will, in the future slides, I will refer to that. So, we have, we have the, we have the hypervisor level, the privileged, the, between the trust zone and the supervisor mode, and there is a secure state, which is not supported, by the way, by the hypervisor, so you cannot do the hypervisor secure stuff. You just need to do calls. If you remember, just remember about this structure, if you, you know, in future, I will reference it. So, why Xen, actually, there is a lot of hypervisor out there. We were thinking about the KVM, about the green hills, integrity, so on. So, Xen is type one hypervisor. We decided it's very important to keep the hardware, you know, the hypervisor level as thin as possible and Xen is a way to do this. It has flexible virtualization modes. We use only HVM, but, you know, there is a PVHVM and so on, which is very useful for us. It allows rather desegregation. It has arm support, which is nice. And it's open source. So, it means that we were able to start working with it from day zero without waiting all these legal stuff passed through years and years and years. So, why we decided to go with OMAP-5? We decided to go with OMAP-5. Well, it's dual-core, say, 15 SoC, like Xen is. It has very good interfaces and peripherals, mobile world capabilities. Yeah, there's a ready-to-use solution for mobile for automotive, like J6 is actually automotive CPU and OMAP-5 was a mobile CPU. And LoboLogic is a TI platform partner, so we have access to all the sources, which is also nice. So, what we did? Key principles. We decided to go with dual domain, like Android is a DOM-U and Linux is a DOM-0. We go with HVM with SSM-U and enable the driver domain, but it's not a separated driver domain. We just map hardware to the Android to the DOM-U and we firewalled most of the SoC controls, like MMU's power management. You don't want your Android to, you know, for whatever reason, disable your head unit while you're driving, right? Okay, so that's the architecture we went with. So, it's a software architecture. All kinds of vehicle service, diagnostic system services and some IPC is in Linux and everything else, everything you can do for user is on DOM-U. That's a J6 CPU architecture. You have a lot of, just as I said, you have a lot of peripherals. That's a public, you can check it out on the TI website. We decided that M4 cores, not A15, will run software accelerators, like boot animation, camera, AV codecs, et cetera. Most interfaces, like UART, I2C has to be DM-8 through SSM-U. It's very important. We decided we don't want to do the provincialized drivers. We want to map the hardware to the DOM-U and to keep it safe, you need to have the system on you implemented. Unfortunately, it's not there with Xen, but it will be there hopefully in 4.4. So, we did our own hex for that. PCI Express is all accessible through SSM-U. We don't use it, but anyway. Some interfaces like USB and SATA, which have, and this is true for other system chips. If the interface has its own DMA, not going through the system, you don't have any other option except partialization here. Unfortunately, or fortunately, I don't know. Fortunately, because probably there's too many of them. MPU graphics, BitBlitter, IPUs, DSPs, all this stuff, which are actually separate CPUs, right? They have their own MMUs, which can be configured in a way that as MMU is configured, they can work with the driver domain safely and even can do sharing between DOM-0 and DOM-U without partialized driver through that MMUs. That's a very, very high-level and un-precise way how the communication built. DOM-U, which runs the HMY and Android frameworks, communicate directly to the hardware, which is configured by the hypervisor with MMU controls. So DOM-U itself cannot control the MMU. It will fail if it tries to do so. I mean system MMU. We decided that the hypervisor is the right place to do the SMM-U control. DOM-0 has its own, well, it has all the Zen tools, the vehicle software, and we moved the PM logic, the power management logic to DOM-0. We decided that Android is not allowed to suspend the whole device. And, yeah, DOM-0 also, of course, can talk to the hardware. And all the, well, accesses to the hardware, which is a mission critical icon, is going through the trust zone. So there's a SMC software that calls the checks and firewalls these calls. Communication between the DOM-U and DOM-0 is done through Xen. And we are building the encrypted protocol, again, using the trust zone services, because you don't want any kind of message to be passed to DOM-0. You want to protect your DOM-0 here as much as possible. So all the Xen tools are there. Okay, so the highlights. We started with 4.3. We took on a 5 with Linux kernel 3.8, stable kernel 3.8 as DOM-0, and we had to stick with 3.4 in DOM-U. We backported a few stuff like ATUGs and backported some Xen support patches to the 3.4. Unfortunately, it's not, it's not, you know, a lot of development was done after 3.3.4, especially on 3.7.8 and later. Kernels, we have decided that we don't want to go with parallelization. We wanted to make peripherals to be directly accessed by DOM-U through memory mapping, which is completely insecure. But we, as I said, we are adding the MMU support, so we are kind of covering that stuff. And I need to mention here, actually, it's not, it's what I'm saying insecure. I mean that you can, from DOM-U, you can program your peripherals, DMA, to ruin your DOM-0 memory. That's why it's insecure. First of all, that's the major reason. But if you're protecting it, it's okay. We disabled power management. That's why I was asking about what's your approach. I had hope. SMP, well, that's a typo. SMP works for DOM-0, and we have no kernel changes on Android side. We wanted to keep the Android kernel as is. Yeah. And we have integrated all this stuff. We managed to integrate, fortunately, all this stuff together. Next steps, something which is not, I call it next steps, but better to say, it's not implemented yet. We want to switch, after this event, we want to switch to 4.4. We, as WIO told me, with SMM use, we will upstream our changes that we did for SMM use. Well, hopefully, they will be accepted. As soon as Jacinta 6, which is a full automotive, kind of automotive version of FOMA 5 by TI, as soon as available, we're going to switch it. And we want to go to 3.11 on DOM-0 and 3.8 on DOM-U, which will allow us to enable SMP and DOM-U. That's important, I believe. We were specialized on runtime power management. We were thinking of moving some stuff to the hypervisor, but you don't want to move a lot of stuff to the hypervisor, right? So, that's very questionable right now. We are going to drop the virtual memory for DOM-U. So, everything that is not, we cannot protect with system in DOM-U. We're going to per-virtualize. Well, USB and block devices, you already have the drivers there. You just need to integrate that. And continue with SMM use and SMC, because we believe that it might happen that we will need to have some minimal support of SMC configuration in Xen with trust. Okay, open issues. So, how to make power management, thermal management? I believe there's a lot of talks in LinuxCon about the power. Always, every meeting probably since five years already or 10 years. So, it's a big issue in kernel and the same with all the embedded applications. We want to review the hypervisor and tools code. We want to address the boot time. That's one of our major goals in automotive. We want to switch to the hard time scheduler. I had probably SDFS, I was advised yesterday. We want to, well, we need to continue testing performance impact on J6. You know, everyone want to get from SOC as much as possible. And upstream, of course. And the big pain is certification. All the automotive guys has a very complicated and tough process of certification. If Xen as a hypervisor has to run on the hardware, it has to be certified for automotive applications. We don't know how to address that yet. But that's a big, big deal. If we do it, then great. Someone told me yesterday that Xen used on some military applications. So, it's doable, at least. All right. So, a few words about our case study. What we treat as a product or not a product, but a solution here, right? So, we want to, first of all, the boot time line. It's very important for us. We want to have user interface up and running in less than seven seconds. And stuff like rear view camera, right? If you just get into your car and turn on the ignition, switch on the rear gear, you want to have the camera up and running immediately, not after seven or ten or whatever seconds, right? And, of course, you want to have the UI up and running in as quickly as possible and not like your smartphone when it boots up. Half minute, minute or worse, right? And you want to have like boot animation nice and sweet. You want to have the, you're all the controls available immediately, dashboard up and running. So, you need to have lots of stuff available as quickly as possible. So, that's our timeline that we're gaining right now. I will not talk about that a lot. There will be a separate presentation by Alex on the AGL track. If someone wants to join, we are welcomed. But, basically, we have only a few use cases, like security, as I said, the MMUs and so on. And then, of course, as a way to secure the system, rear view camera, boot time, that's it. Be concentrated on these three major things on this proof concept. So, that's what we have so far. So, that's OMM5 Panda. Easy to do zero. We connected the SATA disk and who is the monitor? That's the reset. After the reset, we have seven seconds right now to boot the UI. So, that's Uboot, Zen, DOM zero, Android. Oh, yes, before the Uboot, there's M4 software. You have the Android UI up and running in seven seconds. When you're saying that it's available, it's hardware accelerated, video playback. Someone was asking about video playback. That's our favorite test movie. I believe that should be a StarCraft theme. No, not something different. Okay. So, we have video playback, fully accelerated UI, whatever else you like. Yeah, there's some. It's not very good video. So, it's 4.0. So, it's Jelly Bean, 4.2. We will migrate to 4.3. Android running in VM in DOM view. That's the Shelf Linux. You see there's only domain zero and Android to virtual machines up and running. That's basically it. I need to have a snapshot of the details probably. Yeah, not the case we were addressing as we are destroying the DOM view. Probably, it would be better to crash the kernel and restarting it safely. So, right now, after the start, it starts even faster because you don't need to start all the Linux and Zen and other things. I think after that, it starts in around five seconds. Let's see. Yeah, it's around five seconds to start the Android itself. That's it for today. We are working to improve other cases. Our roadmap is to show the full demo with every feature implemented on J6 on CES this January. We will be at TI booth. I mean, TI will have their own booth and we will be presenting there. We are going to upstream all the Zen changes after migrating to 4.4 to avoid any conflicts until the end of 2013. And we call this stuff Nautilus. We want to invite everyone to contribute it as a platform next year. So, bottom line of my presentation is fairly simple. Zen and ARM on automotive is absolutely useful. You can do whatever you want, provide all kinds of security. You know what's the car, right? Okay. So, I think that will give Zen a good way into car applications. So, thank you. See you in Vegas. Why will you also have time for questions? Yeah, we have five minutes. All right, 10, including the five. Yeah, actually, the break is over. Any questions? And remember that one of your slides said that in the future, you could use Hibaya to manage the CPU frequency. Yeah, that was one of our things is to... It's here. Yeah. Actually, Android has its own CPU frequency manager called Interactive. That means, of course, yeah. When they use the touch launch application, it will boost the CPU frequency to get a quicker response. Yes. So, if you just let the Hibaya to manage the frequency, that means you have to disable the interactive gamut from the Android. So, that means you could get a longer response on time in the user launch application. Yes, definitely. This is a big deal to understand what would be the right way to manage all the voltages in CPUs for the power management. Probably, it's not that important for automotive where you have a more limited set of use cases. You don't care about maintaining your battery life. You have the car turned on, or you have a battery like in Tesla. You can power up your smartphone device for probably a few years. So, in automotive, that's not a big deal, but we definitely work on this, and that's why this is kind of a question mark. We want to ensure that all kind of delays are minimized, that's first. And second, there is some simplistic way for Android, if not to control the power, but at least to declare its own... Define what are the requirements at this moment? Like, do I need to enable graphics at the maximum frequency, or do I need to enable the core CPU at the highest frequency? Or it's okay if I have some wakelocks enabled, which domain can I shut down, or what... That's why I put the power management to the open issues, because it's a very sophisticated topic. And when you start to talk about multiple androids, it's becoming even more complicated. If you go with mobile, again, on automotive, you don't really care. Because for the car devices, you can erase the frequency to the maximum. Yep, but in the car, you still care about the thermal, right? Because if the application is not easy, you can lower the CPU frequency, because that can keep the CPU cool. As I said, we want to make it more generic. We want to make sure that it's applicable on different use cases. And even though you can think of use case, when you're shutting down your car, it might be that the head unit is not going to be turned off completely. It's going to some suspend mode. And in suspend mode, sometimes it needs to check probably wireless interfaces. Like someone from Intel was talking about NFC use case in car. Like you want to wake up your car just getting NFC card to the door lock. So in this case, you need to monitor that. So in this case, you need to implement all this kind of stuff. If it's Android or if it's the vehicle part, you don't know. But you definitely need to have the power management in this case. So that's a big open question, how to address that. And I don't think that there is a good solution exist out there for the embedded and virtualization. Yeah, you're right. That is a serious challenge. Yes. Thank you. Thank you. That's a good question. Have you done any metrics on power and thermal consumption with and without Zen and just to see what they're like? Because there are rumors that A15s can run hot. Yes, that's true. A15s can run very hot. We were, you see, it's Panda, no cooler or big fan. So we decided since we are disabling DPM and we want to, we don't want Android to manage DPM. We have fixed the frequency at 1 gigahertz out of 1.5 available. You know, when you are, the more you increase, the more power consumption. So it's 1 gigahertz. We don't have any issues with the overheating and so on, at least on Panda 5, right? I think it will be the same for Exynos. It's the same technology process. It should not be a big problem. And when we resolve the power management issues, we can increase the frequency to 1.5, 1.7 giga, which will decrease our boot time. And it's very important for us, right? We want to take it as quick as possible. But we are not there with a strategy, how to manage the frequency and power and voltages. So for now it's fixed on 1 giga. We don't have any issues, any thermal issues. So do you write the SMMU driver from scratch, or did you pull the Denos driver to Exynos? We were using some of the patches published on the tree and doing as much modifications as we could to make sure it's running. But that's, you know, we are trying to reuse whatever is possible. And we don't, as I said yesterday, we don't want to deviate far from what's being developed now by the community. And we want to be part of the community. We would love to see whatever you've done with the SMMU. Definitely. But I'll have to eat what they did. Okay, sure. Yeah. Do you have an idea exactly what kind of parameters you need from the scheduler as far as latency, as far as percentage of CPU and things like that for your... I have a list of requirements from some of the OEMs, the automotive OEMs. To be honest, I haven't gone through them yet. I need to look at them. And that's why I was asking you about the hard real-time stuff. Yes, because I need to understand what are the possibilities and whether we need to do a lot of changes or it's not yet analyzed by us. We know that it's a requirement. The hard real-time is a requirement. But in terms of budgeting, in terms of whatever you can think in hard real-time, we don't know the complete list. Okay. Thank you. Last question if there is still one. No? Thank you, Daniel. Thank you.