 I'm Alexander Bellon. I work for BellyBray. I will speak about Grebus for IoT. So, first I will just introduce quickly Grebus and why we started. And then I will explain why we may use it for IoT. Okay, first, everything begin with the project ARA. So, the goal of the project ARA was to start a modular phone. So, the goal was to have an interchangeable module. The module could be add or removed at runtime before to switch off the phone. And the goal was to support any type of module such as the screen, camera, even the AP was supposed to be a module at the beginning. So, to make that work, we had to develop a new protocol, Grebus. The role of Grebus was to manage the modules and to add them, remove them. So, features of Grebus was mainly hotplug and hot-remove. The module discovery, when you insert the module in the phone, to detect it, to prepare it to be connected to other modules such as the IP. And the module provides a lot of class and protocols. And that's the main interesting thing with Grebus. So, here is the list of protocols and classes supported by Grebus. For IoT, I think most interesting classes are probably GPIO, SPI, SQC. It's really common bus used in IoT. So, what is interesting with these classes is when you insert a module, Grebus will do everything. If you insert a module with SPI protocol, Grebus will automatically create SPI controller. So, after that, you don't have to do anything except use the SPI controller. So, why Grebus may be useful for IoT? First, because it's free. Everything is open source, everything is free of use. Even because the project dies, there is no anymore Google to try to control it. So, it's only owned by the community. It's documented. There is a lot of documentation. It's a good specification because the goal was to create a standard when we... So, there is everything that is highly documented and you can start... If you read the documentation, you can write everything. It's very good. Now, it's merged to kernel. It's in a staging. So, you can use it now. That's good. And the main interest of using Grebus for IoT is to keep the intelligence in the host. And the microcontroller used in IoT, there is some memory constraints, power constraints. So, the goal here is to use your Linux as a gateway to control the other device you may have on your IoT device. So, you can use the SPI protocol to access to your sensor. And the driver of the sensor will remain on Linux. And that's very interesting because most of the sensors already have drivers in Linux. So, you don't have to write anything if it's already supported. And when everything is totally made, it just works. You just insert the module and you access, you read and write things on your SPI booth. Nothing else to do. It's easy. My goal was to have for this speech a demo. Unfortunately, I've been stuck with Bluetooth. I've not been able to make it work on this board. But it's still a good example of what we can do with Grebus. So, on this board, there is plenty of sensors. This board has been made by TI for IoT. And there is a motion sensor. There is a pressure sensor and some other kind of sensor. Most of these sensors are on the I2C bus. And with Grebus, we could use them directly on the host. So, there is a little schematic of what we can do. So, we have four sensors on I2C bus. So, we have nothing to do. The OS already provides some drivers to use the I2C bus. The only thing there is to do is just to implement Grebus to control the I2C bus. So, not all of it to do. I will show an example later. The Grebus protocol has been made by kernel people. So, some of the protocol is really similar to what we already have in Linux. I mean GPIO is a good example because it's almost similar. You have GPIO set, set value, GPIO set direction, things like that. So, even for kernel people, it could be easy to implement it in firmware. And on the host side, again, except the change I've made for IoT, there is nothing to do. Grebus will do everything. And then, for our sensors, the I2C controller will be created when we will start the module. And then, you will be able to bind the driver with, and then use IIO to access to all your sensors. The four sensors on here are already supported by Linux. So, nothing to do here except to bind the driver to IIO. Because I2C is not a plug protocol. There is no way to do device discovery. So, you just have to bind the driver. And that's it. I need to speak about Unipro, because when we start the project, we choose Unipro as a transport as a bus for the modules. So, most of the things in Grebus currently are made for Unipro. And that's a big part of what I did is to try to translate Unipro things in something else such as TCPIP or Bluetooth. So, Unipro is an interconnect to use in the mobile phone to interconnect IC. In the project area, you will use it. Actually, there is some other application of Unipro. I mean, there is UFS that is an application layer that uses Unipro for flash system to connect flash to the IP. There is some other application. I don't know if there is a note such as CSI and DSI. And the goal when we start to Grebus was to add the Grebus to this list. So, Unipro is a nice speed interface with high bandwidth. It's supposed to be low power, but it doesn't support hot plugs and actually it's not made at all for modular things. That's why the Grebus was needed. So, the topology of Grebus. First, everything is supposed to be modular. The IP was a module and then all the modules are around the switch, the Unipro switch. And so, you can interconnect a module with the IP or two modules. And there is the SVC that is a key component. The SVC is a microcontroller that is supposed to detect a module to create a route between two modules and things like that. So, to use Grebus for IoT, I had to change that because obviously we don't want to add a microcontroller to do such things. So, instead I did everything in software and I removed the capability of the IP to be a module. No, IP is just sort of gateway and we plug module on this gateway. Connection of module maybe actually it's Bluetooth or TCP IP. I think we can add other way to connect quickly, easily. I think there is some other radio protocols that are used in IoT such as ZigBee. So, I think it's just we just need to add another layer for ZigBee, for example. Yeah, I'm working on BLE at this moment. So, here is how we are describing Grebus module, device. First, we have the device and the device may have one or more interfaces. Actually, for IoT, we don't care. We need one interfaces. For RARA, we had the ability to have one or more interfaces because of size modules. Some of modules had two physical interfaces, so we were able to use two newly pro interfaces and sometimes to improve performances or to do dedicated things. Here for IoT, we only use one interfaces. And then, the most important part of the Grebus description, I mean, is the bundle. So, the model is the place where we define what class we want to use. So, we are here in my sample. I have two bundles. The bundle zero is the only one mandatory. It's the control bundle. When you insert a module, Grebus will use this bundle to load the... Sorry. So, the bundle zero is used for the control protocol. The control protocol is used by Grebus to get the manifest. The manifest describes the list of the bundle we have in your device and will be used by Grebus to create all the interface we want. And inside the bundle, you can have one or more support. Support is something specific to Unipro, but it's really similar to Socket in terms of TCP-IP. So, it's used in the same way. And to each support, we assign a protocol. So, the bundle defines the class and the class may have one or more protocol. So, a good example for IoT is the class GBFI. And the GBFI, you can use the protocol GPIO protocol, I2C and things like that. When you insert a module in Grebus, it will add some entry in CFS. I will not detail that. But by using the CFS, you can access to every interesting information about your Grebus device, such as vendor ID, product ID, kind of protocol, your device support. Here, I give a little example of a manifest. So, the manifest is used to describe your device. So, in this example, the most important thing is the support descriptor. Here, I'm using the GPIO protocol and the bundle descriptor that is using GBFI class. So, when Grebus will see this manifest, it will create the GPIO controller. And from here, on the host, we will be able to use GPIO remotely. So, if we continue with the GPIO sample, if your kernel is compiled with GPIO class, you can directly control your new GPIO controller only by using CFS. And so, there is nothing more to do, magic. Now, if we take a look in the firmware, the protocol of GPIO is quite simple. And, as I said, it's really similar to what we have in Linux. So, here is just an example of what I'm doing in Nautix, the way we were using for Project Ara, just to set up, to set the direction and the value of GPIO. Another interesting part, so currently, Grebus is still a work in progress. We have worked on Grebus for two years. There is still a lot of things to do. And even on my side, Grebus for IoT, the change I made, are still in progress. So, there is some limitation. I will start with the first one, performances. Yeah, actually, performances might be variable because some protocols are only sending one RPC at a time. So, if we have bad latency, we will have bad performances. So, for example, if we are using the GPIO protocol to blink a LED, if we have very bad latency, the LED will blink very slowly. So, for some protocol, we made it because we had hardware limitation for platform. We had not enough memory. For some other protocol, we don't have the choice. I mean, if for a GPIO, we are sending two RPC at the same time, one to switch on and one to switch off, it won't make sense because we can't control the time between the switcher and the switchoff. So, for some protocol, maybe for some usage, because of that, it won't be adapted. But for some usage, if we have boost or things with low latency or if we don't care about performances, Grebus may be perfect. Another thing is power management. We were working on it when a project stopped, when Google made the hierarchy. So, there's still a lot of work to do in power management. For me, for IoT, I think the most important missing thing is the remote wake-up. Currently, if we want to suspend the module, we will have to wake up it regularly just to know if there is something to do, if there is something that changes. There is no way, actually, currently to restart the connection when the module is suspended to notify the host that we have something to do. So, that's something we need to complete to make. Another important limitation, and I heard it a lot in other speech, is security. Currently, Grebus doesn't define any security things. I mean, there is no encryption, nothing like that, and that's very bad. If we are using Bluetooth, it's not really important because Bluetooth has encryption, it's doing peer-to-peer, so it's protected. But, if we are using TCPIP, there is no protection. We can sniff what is happening on TCPIP. We can inject Grebus operation. So, for some usage, Grebus actually is not safe. So, we need to add some security to Grebus. Another thing is Grebus actually currently is a module. So, we need to load the module to use it. So, we can't use Grebus as is on your smartphone for the moment. So, if we want to connect IoT device to your smartphone, we have to use the smartphone as a gateway to Grebus host. So, nothing blocking, but something that will increase latency, so we have to take it in account. And my current implementation only work on local network. So, for TCPIP, I'm using Havai to discover a new module and to detect when the module is removed. So, obviously, it's a new work on local network. But again, it's just software, so we can add a new protocol to discover module. It's not something blocking. Still, even if I'm not able to make a great demo like the one we saw during the keynote. Yeah, I wanted to have something great demo, but I didn't have enough time to do it. But I still have something working. When we were working on Project ARRA, we were using GBCM, it's a Grebus device simulator. So, kernel team, we are using it to continue to develop Grebus. We put to have for firmware team to implement the new features and things like that. So, right now, we can test and play with Grebus for IoT by using GBCM on big open black. It should work also on Raspberry Pi. So, if you want to try, there is a sorties available. I still have a lot of work to do, but I've tacked the... If you use the branch ELCE, you should be able to reproduce the setup and start to play with Grebus. So, now, what I want to do later is to upgrade all my software, because right now, the software I'm providing on my GitHub is not compatible with the last version of Grebus. When I started to this work, we were still working on ARRA. It was not stopped. And so, I used the sources, the public sources. I was not used the internal sources. So, the whole software is a little outdated and I need to update it to support the new features. And so, the one thing I really would like to have a platform, a good platform for firmware. I really would like to have an OS such as Defear that will support Grebus completely. And then we will have nothing to do. If Grebus is working on an OS, all the platforms supported by the OS will be supported by Grebus. And so, we would just have to do everything on this OS and we work. So, now, if you are interested, you can contribute. This project has been started and financed by Google, but now Google doesn't care anymore. So, we can do what we want with this project with Grebus. So, now it's all and we just have to make it have some. So, if you want to contribute, you can help. Do you have any question? Yes? Sorry? Oh, I hear the word to your session. I was not able to attend. It's sort of the same thing. Yes, yes. Yeah, I think the main interest of Grebus is already present in kernel. Even if it's staging state, and there is a lot of work to complete it, we already have something working. Yes? Yeah, yeah, yeah. Effectively, the part to bind the driver is not the best solution. And I know there is some thing we have with Difference Tree could be best. But for the part itself also protocol, Grebus is already there. So, maybe we... Yeah, I'm still working on Zephyr to have the Grebus stack. But actually, you don't have to have the whole Grebus stack. I mean, you can at build select if you want to have GPIO, if you want to have SPI, things like that. So, except Grebus Core to send and receive packets, you don't have to have the whole stack. Yes? Yes. Yeah, actually, yeah, we don't... Yeah, yes. Yes, yeah. Yeah, it's going to be Zephyr. Yeah. Yeah, actually, Grebus is in the... It's both, yeah, both BFD and GPL. So, you can write an implementation of Grebus in BFD, or Apache or whatever you want. You can tell it's GPL, yeah. No, no. Currently, what I'm doing is just... I'm simulating some other things. A lot of Unipro... We have a lot of Unipro operations, and so, when the application receives it, it just tries to fake everything. So, right now, it's just underlined by the user specification, but the best thing to do is definitely to remove... to abstract Unipro things. So, there is a chance to make a kernel for that. Yes? Oh, yes. Yeah, I don't know if for kernel we have a mailing list. Okay, yeah. Good point, yeah. Okay, any other questions? Yes? Yeah, for Bluetooth, I'm using the inquiry. So, continuously scan Bluetooth to see if there is a new device, a new Bluetooth device. Same for BLE. And for TCP-IP, I'm using AVI. So, I'm using AVI. Yes, yes. Not yet. Yeah. That's really a big mess. We need security. Okay, any other questions? Okay, thank you. Thank you.