 Welcome, everybody. Hopefully you're back from lunch, or enjoy the free IBM lunch, as far as I heard. So the next around 30 to 40 minutes, I'm going to talk a little bit on something that I've done about a year ago on trying to see how small we can actually Linux get and what you have to differently to make it a little bit smaller. So the talk is called Running Linux on Tiny Peripherals, and we're going to go through this one step by step and give you an idea on how small we can get and how we got there. My name is Marcel Holtmann. I work for the Intel Open Source Technology Center. And quick stuff over me, you will realize by some of the things in the talk I've picked this way. I've been working on Bluetooth since about 2000, maintained the Linux Bluetooth stack since 2004. I have done a couple of other projects, like a connection manager for back in the days for the Mego and Tizen operating systems, a telephony stack, a proxy manager, and something that will become interesting in a little bit of future on the Meta Linux library. And I will make have a quick detail on that one for a second later in the talk. I'm with Intel for over nine years now. I joined in 2007. I do a lot of standards work lately. So this was a little more of a fun project to get going and see if we can actually push the boundaries far enough to actually make this work. I'd like to start off with a quote that Jonathan Corbett did at the Kernel Summit in Korea last year, and fundamentally goes the way it's like, if we are not able to shrink Linux, then Linux will play absolutely no role in the IoT space when it comes to the devices that are really small and tiny. And someone else is going to eat our lunch. And I think he's spot on with this one. Mainly we keep moving Linux bigger and bigger. We put it onto enterprise systems, but we keep forgetting that it was actually really big in the early days and helped us to establish Linux dominance on the small devices. So backing on this comment, I said, look, let's see what we can actually do. And the question we're going to really, I'm going through in the next 20 to 30 minutes, is how small can we make Linux? What's our target? Where are we going? And where we are stuck? And where we should probably use something different. So the way I did this is I looked a little bit and fundamentally, and this is not to scale, if you can't read the bottom part of it. It's not a scale. I just picked some numbers in there to actually see where we are, where Linux is good, where Linux definitely has a use case in the embedded space and the IoT space, and where you really want to actually take an RTOS, like the recently released Zephyr from Intel, for example, and we're going to do this. So the generally scale goes, if you're more than 512 megabyte, there's no questions to ask. You want to run Linux. 32 to 512, sure you run Linux as well. And even heard that some companies have problems getting any RAM chips that are less than 32 megabyte these days, if you don't make custom designs. So 8 to 32 megabyte, I still think there's no questions to ask. If you have 8 megabyte RAM or Flash, you're going to run Linux. There's really no questions. You're not going to bother with bringing up an RTOS to that size and scaling it to the features you're going to need. Now we come into the space that's a little bit of the rambling zone, where you actually can consider running an RTOS or something else. So 4 to 8 megabyte, I don't think you should be running an RTOS, but I hear people want to actually blow up an RTOS on the level that they actually want to do this. I think Linux where we run perfectly fine on 4 to 8 megabyte, no problem. 2 to 4 megabyte now gets really tricky. Can you actually shrink your Linux call down to something where you can actually run this? And you will see in later talks that we actually can. And the really interesting part is when it's 1 to 2 megabyte, because that's the really tricky one where you actually have to think a little bit different, where you might not going to run your standard Linux distro anymore or do whatever you think you were doing in the past by doing a tiny build of Debian or something else. You just want to boot it up. If you go less than a megabyte, I think it's really on none of the Linux business anymore. That's where the RTOSes are going to shine, like Zephyr. But then you have to make the assumption, OK, you might not going to have Wi-Fi support. You might not going to have the dedicated IP stack support. You might not going to have XYZ and so on. So that's something you have to scale up your RTOS a little bit. But the rambling zone is somewhere in between a 1 megabyte and 8 megabyte, where we can have a discussion about this. Once you go over that one, it's Linux. If you don't use Linux, you're wasting your time. So there's another one between Jonathan's comment. It's what I call the Timberts Serial Scale. And he basically has given a couple of talks. And the latest one that I reference is the Stutters of Embedded Linux in October 2015, where he basically looked at, OK, what's the cheapest Android phone you can get? What does it cost you? And was it still running Linux? So the cheapest Android phone he phoned back in the day was $29 in Russia. That's a whole Linux phone that can run Android. So it runs Linux kind of plus a whole Android stack. And then there's also the chip with a $9 board computer. You can also run it on. So I think the cheapest estimated Linux capable of SOC is around about $3 right now. So that gets us pretty close. And we know that the price of silicon is on a steady decline. But fundamentally, his was like, look, we want to put a Linux system into every serial box. And the rule of thumb for doing this one is that it needs to cost less than a dollar. And that's SOC, display, battery, input, RAM, et cetera. And you have to run Linux on this. So that's where we have to go. We have to get a less than a dollar. And that's pretty much his scale I'm going after in this talk is like, look, what do we need to do to get us there? Now to actually getting us there. So when I did this, I was like, look, let's pick a really use case where we actually can do this. So with the IoT space, you have to imagine some sort of devices. And I pretty much picked three corner case that I want to do with the device. The first one, it has to measure and access sensor data. So the symbols would be like a thermometer, or kind of wind speed measurement system, or something really simple that measures something, or even just your weight, or something really simple that is tiny. But it has to measure something that you actually have as an input. The second one is, you want to get this data back out. And most of it is an IoT device. It has to be wireless. You're not going to attach an Ethernet cable to it, because that's not really an IoT device anymore. So it will be Bluetooth, 15.4 Wi-Fi, or even LTE in some cases. But we have to pick a wireless technology to get the data back out. And the third one is, you need to have a battery powered, so it actually has a long lifetime. Because if your IoT device that measures data and sends it out over any wireless technologies keeps running out of battery after a day, they become really useless. So that was my good thing. We're looking at these kind of device types, and we want to run Linux on them. So which device types we would actually going to pick? So I have a really simple categorization for any of these. So we have the really simple ones, which I call sensors. And they're basically using Bluetooth low energy, Bluetooth smart, and they will measure your temperature, measure your heart rate, or something else. That's really simple. And the only thing they're going to do is that they measure, and you can access it over Bluetooth. It's a simple peripheral, and you can get the data back out. They don't have any advanced security or anything else. There's a second category somewhere in between where you actually have what I call an IP node. And it's pretty much, OK, we're going to run IPv6 on this one, and we run it either over Bluetooth or we run it over Threat. And that's pretty much then, OK, we have real internet connectivity. So we'd be really internet of things kind of device. And the third one is you always need an IoT. Well, you need the gateway that will connect this to your larger scale, to your home entertainment system, or the back ends, or somewhere else. I don't know what. And actually, I should have probably put these days LTE and LTEU on these ones as well. But fundamentally, we have the really small ones. We have the IP ones, and we have the gateway ones. So I think for the gateway ones, there's really no questions. Most gateways in the IoT vault that currently run Linux. And they're doing well. And the DSL and cable modem manufacturers have been doing this for years. So putting a little bit of extra IoT juice they need into these boxes is pretty easy and straightforward. The IP nodes, Linux has a really great IPv6 stack. And I have a couple of comments on the Linux IP stack as well. But Linux has a generally good IPv6 stack. We need to probably look into actually just utilizing this instead of having a half-baked IP stack from some RTOS where we actually have to fix half of it. Linux is well-proven because they run this in the data center. Companies like Facebook and Google run fully IPv6 backends. And they know what they're doing with IPv6, so why not leverage that one? So the sensor world is a little bit tricky because historically, Linux hasn't really been used on any Bluetooth-enabled sensors. That's all custom design running on the same MCU. So that's something. Let's see if we can actually do this. What's the size of building, for example, a temperature sensor? And I'm going into this one in this talk and how we going to get there. So I picked a few ingredients to actually do this. I put the logos up there. The bottom ones are a little bit more. I had to pick a logo, it makes sense. Does any of you actually know the top three logos, what they are, which open source projects they are? None? Oh, wow, OK. OK, so the left one is gummy boot. It's a UFI bootloader. The middle one is the Linux kernel. You should at least guess that one. And the right one is the Muscle C library. And I picked this pretty much for a reason because I'm not going to starting out with a G-Lib C, but I wanted a C library that actually was pretty much compliant when it comes to we behave the same way and we proud ourselves on doing this one, while being small. And Muscles seem to be like a good fit. They're more than them, and you can probably use DietLib C or ULib C or UCLib and some others, but I just ended up with picking Muscle. The Linux kernel was kind of obvious, since I want to make Linux smaller. And gummy boot is I needed a UFI bootloader that I actually can work with. And you will get in the later slide to see what I'm doing with this one. The two bottom ones, I said the target was a Bluetooth peripheral, so I thought I'd have to take the Bluetooth stack for a Linux, Bluezy, and make that one work. And I needed a helper library for a little bit of doing the basic stuff like setup, main loops, and so on and so forth, which is L, which is the embedded Linux library which I worked at on Intel, and we open sourced it for about a year and a half ago. So now I'm putting this all together, and now it gets a little bit of the fun starts. So what I'm actually doing, I'm building a PE executable. Everybody knows what a PE executable is? It's a Windows binary. So I'm building a PE executable that I can actually directly put onto an UFI bootloader, and we'll just start it. So to do this is I'm borrowing the gummy boot EFI stub, which you see in the bottom of the diagram, which is either the IA32 or X64 version, depending on if you're on a 32-bit or 64-bit X86. We're stuffing the OS release information into this one. We're using the kernel command line put it into this one. We're building a static kernel image without modules, putting this in there. And we're going to put a built-in in drumFS, and put this in there as well, and we're linking this all together, and we're linking it into a PE executable that you can just literally put on your SD card and just boot it off your system. The in a drumFS consists of a single process. We're actually building the PID1. We're building the in-it process. And the in-it process is actually the Bluetooth stack itself that runs in user space, using Muzzle as a C library and LS an embedded Linux library for different functionality. If you put this all together, you get your boot IA32 on 32-bit platforms, boot X64 on 64-bit platforms as an EFI binary, which I said is a PE executable, and you can then just put this on your UFI system and just boot it. You don't need anything else. On the left side, you have still the case that you actually can sign these, since UFI supports a secure boot. So you can sign this whole image and have also secure boot, getting at this one for free. So to summarize again, the IEFI stub comes from gummyboot. Gummyboot is a little bit of a deprecated project. Most of the stuff with the EFI stubs has moved into SystemD boot, which is part of SystemD, but it's fundamentally the same thing. I just kept gummyboot because it had a nicer logo. The operating system identification is pretty much only that you can actually analyze this and see what's in there, so you can put version numbers in there, et cetera. The kernel command line is important to put in there, because you want to boot this kernel command line, and we actually want to, if you do secure boot, you also want to sign this, not that you actually can circumvent the boot command and disable certain things. The kernel image is obvious, and the user space is custom-built in a drama phase. You install it on your FAT32 partition, and you just boot. And really, any UFI system that you have out in the market can actually boot this. And we've tested this with Galileo and the MinoBoat Macs. You put this on the SD card, you put this in, you say, you power up the system and just boots, and you actually have your whole Linux system running up there. And secure boot is just a nice thing. A neat trick, besides secure boot, is that if you want to do an update, you just put a new EFI binary inside the boot partition, turn the boot loader entries for UFI to the new one with a fallback to the old one. It boots the new one. If something goes wrong, it falls back to the old one, and everything is taken care of, so you don't have to do a large-scale software update process. It's just pretty much, here's the new binary, put it on there, off you go. Looking into PID1, so as I said, we're not going to use any system D or system 5 in it or anything else. We actually have to build our own PID1. We have to build our own init system. And Bluezy, as a user space demon, doesn't have support with, so we actually created a project that is called Bluezy Purple, which is part of Bluezy, that does exactly that. So it becomes a Bluetooth stack and an init system in one binary. And what these things have to do is they have to fundamentally create basic device links, since you need to create a couple of device links in your dev route. You have to mount some file system like dev tempfs and some other ones to actually get the system up and running. You need to initialize and set up the Bluetooth hardware. So that still needs to be done. So either you need the firmware to load or something else. If you want to additionally have some watchdog support, you actually start the watchdog at that point, which is pretty much, OK, we actually open the watchdog support from the kernel and make sure that we're actually going to get restarted, which is pretty important if you build an IoT device that's supposed to be somewhere lying in the ocean for three years. You want to actually have that automatically restart itself, and you don't have to go diving back down there. And then, obviously, at some point you say, OK, I'm exposing the Bluetooth information. Oh, my sensors are up and running. So you can actually connect to me. Muzzle, the basic C library. Works really well for this one. Nice static linking, nice easy to build. And L, we have been using this for main loops, hashes, and queues, which is sometimes needed for some product operation that you need to do with Bluetooth. The interesting part is really on the left side. So that when the system boots up, we don't have a route file system. We basically keep dev route as the kernel gives us, which is the inner drum of S as you build it. So that stays there. We don't pivot route into a new file system. So this system has no idea about route file system. It's read only. But these systems sometimes need to store some information. Like for Bluetooth, for example, if you're going to pair the device, you get a security key that you want to save over reboots or something, or you might have to some configuration that you have to remember, or some states, and you want to store this. The interesting part is, if I actually provide you with persistent storage, so you can use the UVI-VARFS file system to actually access the storage data. And we have built this directly into this demon that you actually can store a couple of information in the UVI-VARFS, and then just works it. So pretty much we're running without a file system there, which is great. It saves us a lot of space. And the UVI persistent storage, we just make that's the problem of the UVI system to provide us. But it works really well, and it is nicely standardized. So we built a proof of concept. So this idea actually works. So the idea was simple Bluetooth sensor. It boots perfectly fine in QAMO. The Bluetooth controller in QAMO is just forwarded from the host. We have nice support in Linux that you can just move the Bluetooth controllers into the host and just appears a UART, and then you can just use it nice. If you're going to build a Bluetooth 64 EFI binary with that one that runs in QAMO, the size is less than a megabyte. And that's still the 64-bit version. I didn't even bother to try in the 32-bit version, mainly because I was lazy as luck. We're going to do this a 64-bit, and if I find time and find the need for it, I'm actually trying 32-bit version. But even the 64-bit version, I was all in the space that I previously reserved for the RTOSes. So we're already less than a megabyte. If you want to put this on a Minibot Max, you need a little bit more, since you actually need PCI and USB support to actually get a USB dongle that is a Bluetooth USB dongle that is on USB attached to the system, so you can actually operate as a full peripheral. Then you end up with 1.3 megabyte in size, and it's still in the range that we were actually targeting. So and this is just a simple Bluetooth peripheral where you can read your temperature sensor and so on and so forth. So as I said, we could do this for 32-bit. I just was too lazy, since I would have to refresh the firmware of the Minibot and make a build system that builds this for 32-bit. So that's something for someone who wants to actually play with this one. Try to make this to build a 32-bit and see what it actually saves compared to a 64-bit build. Now we're getting into the level that I'm going a little bit on details on what we have done and where still working areas are going. But so far, any questions? OK, then let's get a little bit into the nitty gritty details on what we have done and where things are actually funky and what still needs to be done to actually make this all a reality. So the first thing that we had to do, we have to build a user space that actually isn't bloated. And that's you have to really take it. If you're aiming for a size between a megabyte and two, you have to heavily look at this one that you actually build something where your user space doesn't blow your limitations out. You can easily blame the kernel of being too big, but in all of cases, it's a user space. And the first thing we had to do, we had to remove the IPC. Bluezy generally supports debuts and supports a couple of other IPCs to actually work on this one. But that's mainly because you have a multi-user system. In this case, we're running a single process, which is PID-1. So there's really no need of IPC. So we had to restructure pieces in Bluezy. It was luckily relatively easy to do so. But we had to restructure a lot of pieces to just run as a single binary that actually has no input for anybody else. So it runs for a given time. We needed L and Muzzle to actually make the small. Because once you use the G-Lib C or something like that, you end up still with a megabyte or two megabyte just in user space size. Because it's G-Lib C is just large. But Muzzle worked out really well. And we have written L specifically for the case to be used with Bluezy and with Muzzle. The kernel site. So you're going to start out with make tiny config. And there's the wiki link for this one. It has been through the press a couple of times. And it's improving. So you want to actually make a kernel that actually has almost everything disabled that you don't want. And then you manually enable things else. So you can start with an empty .config and then build your kernel. But you still want to find one option that's tinyfication where you actually have the expert menu that allows you to disable even more features. The one thing that will make this really interesting as a future is when you actually be able to use execute in place on x86, then you can share your RAM and flash. Because the kernel sadly still consumes a lot of RAM. Even while itself is small, the RAM that it keeps persistent for itself is still pretty high. So it would be great if we can actually reduce that further. After I made besides the execution place, we haven't looked at this one. The patches have been posted. So there's still some work to do. An interesting part is then if you want to do optimize your linker that links this all together. And there have been kernel support for this one as well. The CTO seems to be really interesting for this kind of support, especially in addition with cold code compression. And I really urge you to see or read Tim Byrd's Advanced Size Optimization for the Linux kernel. It's a really nice read. And he has done a great job on that presentation. So find this and look it up. So when we got this far, we ended up getting a little further. The user space, we built it dedicatedly for this one. So there's really not much more optimization. It's super tiny. It does only the job that it has to do. And everything else is now in the kernel. So the only size optimization we can go further is actually getting something removed from the kernel. So the first one is we don't need any inter-process communication. So any kind of IPC the kernel is providing, we don't need it whatsoever. There's running a single process. We don't need UID and GID support, mainly re-running PID1, which is rude all the time. So we don't actually have to worry about multi-user system setups. And there have been patches in the kernel that allow you to actually disable this now. So that's pretty great. We wouldn't need fork and exec. So these system calls we could disable. I haven't really succeeded in doing this nicely. They have a little bit of tangles, tentacles spread over everything. So we have to see how we're going to go there. And on that line, we really only need a small subset of system calls to actually operate our small PID1. So you can disable certain system calls, but you cannot enable all system calls. You're still carrying a lot of baggage around this. So you would have to actually put a lot of extra config options into the kernel to re-enable the rest of it. The command line parsing is rather complex in the kernel. We actually wouldn't need a lot, since we know exactly what we're doing. We don't really need the full blown VFS, since we don't have a root file system. We're running on the inner ROM-FS and the EFI-RFS. So that's some automation as well. We would not really need a heavy scheduler, since the only thing we're going to have is running PID1 and a couple of kernel threads, so that could be just really simple scheduler. So that could be made an argument to have an alternative scheduler or a breakout that actually makes the simpler and we roof a lot of complexity in that code. Especially when you build a Bluetooth peripheral, we have limited need for networking. That's obviously changes when you want to build an IP node. But even there, you have limited need for the whole networking stack that Linux provides. So you actually want to do a small separation, say I need x, y, z feature. For example, if you only need IPv6, what are you going to do with IPv4 support? What we especially did for this one, because we actually focused on Bluetooth low energy. So there was no Bluetooth classic or Bluetooth high speed support. And if you look at this one, start looking at this one, you will find a lot of other areas you'll say, look, this is not really needed for this one. It's always built in. It's like, why is this actually there in the first place? So let's figure out if you can get some kernel options in there. So how far have we gotten? As I mentioned earlier, single user support went into Linux 4.1. It's a big step. It saves a lot. We were pushing Bluetooth LE only options into the kernel. So previously, we had the tendency to have the Bluetooth stack always be supporting everything. So fundamentally, if you selected it, you get the full blown support. So there were a couple of options in there that we can say, we want to support only low energy. And they even patch this now for a decentralized security manager, you say, I'm a super dumb center, I don't need the security, which means you avoid having like elliptic curve, Diffie Hellman, and some of the AS operations built into the kernel, which saves you quite a bit as well, since the crypto subsystem in the kernel is not as slim as you think because it's built for enterprise. On the other hand, it's great because you would have crypto functionality in one place and don't have to duplicate it in user space. So there are pros and cons in that direction. I think the biggest challenge that we have gotten, and I will get a little bit on the details where we actually have been really challenged here, is that getting new config options in the kernel to actually disable things not as easy as you think. Even when hiding them behind something like config tiny or something else, there's still a lot of resistance to actually adding new kernel options that disable code. And the reason for that was always being the testing complexity that everybody's worried about, that you're going to break something and you put a new config option in there. So that's still work in progress, and some of these ones will make it eventually into the kernel, but I'm not sure if you get all of them there. But hey, if you have found an option that you think might be useful in helping this one, if you toy with this idea, please let me know and please try to get it upstream. So our biggest construction areas. The Bluetooth sensor node is kind of nice. That works pretty well. We have a little bit of cross-termination if you enable networking, since Bluetooth is still a networking stack. So it compiles in some of these net filter stuff while they're only empty stubs, but they're causing a little bit of size. So there's a little bit of cleanup to do with the cross-termination once you enable config net, which Bluetooth depends on. If you have to do an IP node, you want to enable this one anyway, that's all fine. But the biggest problem is, can we actually build an IPv6-only networking stack in Linux? The answer is right now, is no, you can't. And frankly, I don't know if we ever will be able to. So there's a lot of work needed to make Linux IPv6-only. And some enterprise customers are actually wanting this, because they're running IPv6-only backbones. IPv4 packs are completely useless to them. So for them, that would be not a size optimization that would just, OK, we don't have to deal with this one, because it wouldn't accept the packet in the first place and don't even push it through any queues. The reason for IPv6-only mode is so hard, because historically, IPv4 was the one and IPv6 was the one that was the last thing glued on, and a lot of pieces are still interlinked between IPv4 and IPv6, and they're sharing code. So that would be neat, a lot of separation and cleanup to actually make this an IPv6-only Linux. What we have succeeded, while not upstream yet, but we have succeeded a config TCP equals N mode. And the reason for that one is pretty simple, that most of these embedded IoT devices, they will actually not talk TCP, since they don't want to keep any states. They may only take UDP, and then DTLS over UDP actually do their work, and they don't have to keep that many TCP states and sliding windows and so on and so forth. So we managed an option where you have config TCP equals N and that disables TCP, but it will not actually allow for any user-space TCP. It will still handle the TCP packets, but it will just all reject them, which was one of the main requirements from the network guys that, look, we don't want to enable user-space TCP, but if you think you just want to take the code out, just behave it as a dummy that has no idea that there's any port open or anything else. That patch is not upstream yet, but I hope you understand this upstream at some point so we can actually get this included, because I think this is a big size saver. So the other interesting part is what we are looking into is actually kernel-side TLS. And this is an ongoing work item, mainly driven by enterprise folks. And you have seen probably patches for KCM, a kernel connection manager, where you actually can split out a TCP connection into multiple sockets and gets pre-passed in the kernel for you and pre-framed. Something similar will happen for TLS and that you can do TLS in the kernel so you can make use of crypto accelerators. While for the enterprise side, this is purely about speed. While for us, it's about size. We don't want to carry two TLS implementations around. And the kernel already has support for TLS and it needs support for TLS because of secure boot, or RSA in that particular TLS, but RSA. But if you're going to go to the IP notes that I showed earlier, then they would use DTLS, which is fundamentally TLS over UDP. And we need TLS support again. And we don't want to drag a TLS stack into multiple areas or have copies of AS encryption algorithms or any kind of RSA or Diffy Helm. So our goal was to actually put TLS into the kernel, put the certificate authority into the kernel. The kernel has a concept of keyrings, so you can actually have keyrings that you can seal. And hopefully we get this all working at some point where user space process can inherit kernel keyrings. So they would start out with a CA that is backed up by kernel. The interesting part is once you do this, you can actually access TPM or secure enclave type devices where your keys are actually not in the kernel memory, where your keys are actually in hardware. And you can ship devices with pre-built in keys, and they will often go and work perfectly. I think there will be updates on the TLS and DTLS support in the networking or NetDev 1.2 conference in Tokyo at some point in the next month or two. So if you're interested in this one, I will look out for that or find me and talk to me afterwards. An interesting error is when you actually want to go towards, we want to build a tiny peripheral, but we want to use Wi-Fi. And previously, I always thought this is really a weird case. If you want to run a Wi-Fi, then run a bigger system. But I've seen the Wi-Fi requirement for artists is coming up lately quite a bit. And I've seen the Wi-Fi requirement up even for a small Linux system. So we have the problem that the current way of handling Wi-Fi is only with WP-supplicant, because if you need the crypto, and it drags in either GNU-TLS, OpenSSL, it's on crypto libraries. And it has pretty much no management capabilities. So you need to put another process on top of it that actually manages the Wi-Fi network then. So you have something that only can speak the crypto protocols, a little bit of the scanning, but doesn't want to manage anything. Then you need inter-process communication again. You can't really easily link it. So this turned into something, OK, this doesn't look really feasible. So this is not an open source project yet, but we plan to open source it at the Open IoT Summit in Berlin in about a month. I think it's the second week of September. I forgot this right, or maybe October, second week of October, which is probably we have been working inside Intel phone for about a year and a half now. And it's a new attempt to actually do a wireless demon. So we're going to replace W-supplicant while using kernel keyrings and kernel TLS and RSA support for actually WP Enterprise. Since that's one of the funny things, if you actually build an IoT device and it's an Enterprise device, you're not going to talk WP personal for your home network. You're actually going to talk Enterprise network, and you have to deal with certificates to actually get this device securely authenticated to the network. Watch out for this one. The plan is to open source it at the Open IoT Summit in Berlin. So note to the elephant in the room, I'm basing this out of a U of I. And I'm talking about I want to go less than a megabyte, and probably everybody has been silently laughing at me. It's like, what the heck am I doing here? Because U of I is already humongous. And yes, there are huge U of I versions out there, but U of I is based on the U of I standard. And there's nothing stopping you from actually building a small U of I bootloader that just does the basics that you're going to need. So there's a huge amount of opportunities. And when I gave this talk the first time internally, this was still as it was. But as time moved on about a month later, there was an interesting email from Alexander Graf, who came up with like, look, I've actually built the U of I primitives into U boot. Because previously everybody was like, why don't you use U boot? Make this work on U boot. It's like, look, I work for Intel. We do U of I, and I think the problem that you want to solve is not make this work on U boot, you want to make U of I smaller. And Alexander Graf from SUSE actually did. So he put the U of I primitives and U of I loader into U boot, so you can actually have U boot booting up the boot IA32 EFI binary. And which is kind of interesting, since we had the fundamental problem that the Edison devices from Intel were actually using U boot and was really hard for us to boot on this one. But out of the sun we were able to actually boot these devices as well using the PE executable that we were building on this one. The email is public. I think he has sent version three by now, something like February of this year. And as far as I know, this is actually merged upstream and he's continued working on getting support for this one. He had a little bit of caveats that he had no persistent, so no EFI variables so far, but he has plans on making this work within VRAM, so they will happen as well. So this becomes a real alternative. And in this part, he then does this for ARM and ARM64. And ARM also supports EFI as well, so you actually can build this tiny peripheral using a PE executable to actually also run on ARM. It's no problem, it's just I didn't bother testing this on ARM. I tested this on Intel platforms. So what we get with this one? Testing and verification of this one was really interesting since it was super easy. It was super easy to bring this up. It was super easy to test this. And I didn't have to deal with certain hardware problems. OK, does this hardware boot? Does it the hardware doesn't boot? At the end of the day, I was even building extra code pass into the PID one where it allowed me to test all what I was going to do either as a process running directly or either in a namespace or either in QMO. So before this even saw real hardware, I had all the nitty-gritty details figured out. And that's just awesome, so you don't have to deal with a lot of things. Emulating virtual hardware, emulating virtual and real hardware is especially easy when it comes to wireless devices because the Linux stack has so many features in there. So I've seen so many engineers struggle when, oh, I need to make this work on the real hardware. Well, I go, look, can you just run this on your desktop? And once you actually like 90% there, then you put this on real hardware to find the other problems. This made it really easy to get this all working without actually having touch on hardware. So you get 90% done, and then you fix the rest through 10% of bugs that you're going to have. Seriously, KVM and QEMO is the friend. If you're any doing any of this one, my only advice is if you want to play with UFI, build your own BIOS that you strip down from the EDK2 because that saves you so much time. If you know what you're doing with this one, you'll probably spend an hour or two trying to understand EDK2 and how to build it. But just do this once, and then you will have so many things easier because you just only do 10% of EDK2 ready to run any of this one. The interesting part gets really when it comes to the wireless space where you normally would hand off the device in a large-scale certification lab, and they take the device for three or four months. If you can emulate all of this one, you can cover a lot of the ground before this even has to hit a physical hardware test step. That's kind of interesting because, hey, what's the difference between spawning one key, in one instance, compared to spawning 300? Doesn't really make a difference. And the interesting part is really you will easier find a Linux developer than you find an ARTOS developer. I think that's something that everybody needs to consider when they make the arguments. Oh, we need to scale up the ARTOS because the Linux is too large. Or like figure in the case that you have to find your ARTOS developer while Linux developer, you find quite a lot of them. Do we have any questions? So there's another project. So we open-sourced this. We put some of this stuff into Bluezy Stack. You can find it. You can test with it. But there's also another internal project that actually took this idea and allows you to build it. The Soleta project has an API that you can use to build your applications. And it has options to actually build this for an ARTOS, build this for Riot, build this for Zephyr, build this for anything else. But it also has an option to build you an EFI binary similar to the process I just described. And then you can integrate this with any kind of IoT solution it's going to have. And then you can actually test this out by yourself. So I would urge you to actually start looking to this one and then want to toy with this one. If you want to look at any kind of the work that we have done manually to build this, it's all in the Bluezy source code under Bluezy peripheral, which is pretty much a dedicated mode to actually run this as an EFI binary. You still need a little bit of magic linking tools to actually build this all together. If you don't want to look into that great details, Soleta is probably the better approach, because you can just start designing your IoT device and then just build this for a PE binary. And then have fun putting this on a minute board on Edison or Galileo, or any favorite other IoT platform from a different manufacturer. That's all I have. Thank you very much. Any questions? Yes, please. So the question is, I didn't really strip down Linux. So what did I use? So we actually took, we selected the right configuration options for the kernel. We put a couple of patches in to actually put more options in there to scale down the Linux kernel. But we walked away from having the idea that we have the standard Linux way of booting a system. So there's no system 5 in it, and there's no system D. Because that's just killing your budget that you have right there. We're building a custom user space that is really only doing one job and one job only. Say again? Oh, so debugging, the thing is, as I said earlier, the user space that we build, you can run this as a standard process in your desktop Linux. And then you attach GDB to it, and you're good to go. So that's pretty easy. That makes it kind of nice and easy to try. Or if you run this in QEMO, you attach GDB to QEMO. Any other questions? If not, then thanks, everybody, and have a good day.