Welcome to the Zephyr Mini Summit 2020. Warm welcome to those of you Zephyr developers. We would not be here without you. So thank you for your contributions. Also welcome to those of you who are new to Zephyr. We hope this talk will provide enough ammunition for you to get started with your own Zephyr project. All right, we have a great agenda lined up for you. I will be going over Zephyr project over all what the project entitles. Then my colleagues from Zephyr project will join me and walk you through with some of the key topics, communication stacks, our release plans, security and safety for Zephyr, and we will have a use case example at the end for you. At the very end, we'll have about 15 minutes Q&A. If you have any questions throughout the talk, feel free to start entering your questions on the top right corner and we'll do best we can to answer, but we will also have a panel at the end. With that, let's get started. One common question we get is why Zephyr? Was there a really need for another R-toss while there are so many choices out there? Based on our research, we believe that how the market was evolving for constrained devices, there was a real need for open source, open governance and full featured real-time OS. The low end of the stacks were extremely fragmented and there was a need to secure endpoints so it can be used for safety critical applications and that is why Zephyr was created and we have really strong ambitions and goals to make this Zephyr as a best in class real-time OS. Zephyr project has been around about four years. We started around 2016. Right from the start, Zephyr was an open source project with mutual governance. It is permissively licensed under Apache 2.0 so you as a contributor can retain your copyright and this was the goal because we wanted to develop and we wanted to build a strong community. If there's an, right, go back and if there's an architect, yeah, great, thank you. So Zephyr from the beginning, we wanted to be in the smallest of the devices. And we continued adding features and bringing new architectures. At the same time, we're keeping the footprint very small. That is why Zephyr was designed from design point of view, modular and configurable. So if you have specific features, you can bring in and out of the kernel. So this is up to you as a developer. Zephyr aims to be a scalable solution to develop cooperatively in the open that integrates all of its functionality around a common API and permittance. And you can't just call yourself open source project without the key principles of what the open source project entitles. So Zephyr in that sense is a truly open source project and our goal is to empower our developers and to build a strong community. And sure enough, we have built a strong, vibrant community and this community is bringing great products into market. So if we start moving forward and these are the products that we see in the market today. I'll call out, the interesting about Zephyr is it's an open source embedded RTAS. So we don't get to see all the products out there. So it's a little bit of detective work but these are some of the good examples here. A few of them that I want to call out is that OB4 in the corner. It's using Zephyr, it's a radio by Teenage Engineering. It's actually already sold out. I'd love to get my own one when it's getting back in the market. Another one is the distancer with the pandemic world we live in right now. It's a small device using Zephyr, helping yeast to keep the required social distance so that they can still be productive in their work environment. Actually my favorite one is one of the early on Zephyr projects that Grush Gaming Brush. It's making my kids bedtime routine a lot more enjoyable and a lot more fun. So again, Zephyr is targeted at the constrained low power devices and these products are good testament of that. So if you look at the architectures, you'll see the key architectures are represented here. This is actually the main reason and one of the important reasons that Google joins Zephyr project community. You have Intel, you have Arc, ARM and it's exciting to see we have Spark and OpenPower in the pipeline. If you don't see the architectures of your choice in this list, please consider this an invitation. We welcome you to join us, join us as a community, work with the community, get it upstream and add it to this list. We'd love to see that. One of the exciting things that we see right now is a lot of the development boards started shipping Zephyr as a default OS. This lowers the barrier to entry and play with Zephyr and allowing you as a developer to quickly get started Zephyr and get involved. So we'd love to see much more developer boards in this list. This is an example of it. And in fact, if we move to the next slide, we have about 200 boards, more than 200 boards and this list continues to grow. That is enabled for Zephyr. This is just an example of list. If you go to the Zephyr site, you will have the full list of your choice. What does it tell you as a developer? There is a wealth of board choices for you. Not only there is a functional platform, but there is a range of solutions for your choice. Boards are all about getting you started. You can find the lowest price point with the good functionality boards from this list and quickly get started with Zephyr. So don't wait, just get started. And now let's take a look at Zephyr's architecture. From the beginning, we wanted full functionality OS for constrained devices. That was the one of the key goals. Another fundamentals was Zephyr. Founding principle was safety and security. So this was a very proactive approach for security. Zephyr basically sits between bare metal and full-featured operating system. What makes Zephyr special is that it's full-featured, full structure and good architecture with a strong community. So you as a developer can focus on your applications and not worry about other things. I know this block diagram looks overwhelming and then you can barely some of the blocks here. But I would like you to take away from this is Zephyr is highly configurable. It's modular architecture and designed to expand and accommodate new functionalities. So you can fine-tune features and parameters based on the needs of your hardware platform requirements. Memory resources are statically allocated so you can get a good idea upfront what is the upper bound of what your OS memory consumptions will be and you can plan for it. And something that I want to call out here is Zephyr has a rich networking stack and Bluetooth stack. And we have these details available on the Zephyr site and getting started section as well. Let's take a look at Zephyr ecosystem. So at the core, you have the OS itself, Zephyr OS with three layers. You have the kernel hardware abstraction layer with the smallest footprint, kernel objects, services, low-level architecture, everything you need at the lowest level. Then on top of that is sitting the OS services. Basically your networking stack, IP stack, Bluetooth stack, crypto libraries, then at the highest layer is the application services, high-level networking protocols, higher-level objects you can take advantage of. Outside the OS we have the software development kid, device management and bootloader. And then of course the community that we have built and we're proud of. So when we say Zephyr project, it's more than just the kernel. Zephyr has broad goals and we aim to provide soup to nuts menu for your firmware development. And we're building a robust ecosystem with this goal. So let's take a look at what are the applications or tools available to you in the next slide. So on top you'll see based on the architecture, you have NXPs and Nordic and Synopsys, architecture-based development environments. Then you have architecture vendor agnostic development tools in the middle. And then we also have a slew of debug tools for various platforms as well. So you have a great set of development tools as you get started with Zephyr. From firmware and middleware applications perspective, we see that machine learning applications are coming down to these resource constrained devices. So it's exciting to see that Google, Google TensorFlow Lite team has integrated Zephyr. So at the end, my colleague Michael will go deeper into this one. We have Python and JavaScript. We're bringing these popular programming languages to Zephyr and the community around this as well. And Zephyr comes with the integrated boot firmware MCU boot. You also have security oriented middleware that is available. So with all these tools and firmware, we are focusing on the training and consulting services. Training is one of the key areas that we will be focusing on coming months is. You can find getting started guide tutorials and documents already available on the Zephyr site. We have some of the consultant partners of the Zephyr offering training and as part of their services as well. And the right on the Linux side, you also have a free Zephyr class to get you started. From consulting, we have few partners. Actually, Antmicro is a Zephyr member. They provide consulting engineering services. Google works closely with them and open source tools as well. And we have Bay Libra and few other partners here. And Blue Clover device is offering tester. They offer version control testing plans and results can be easily integrated into the cloud. So that you have these services also available at your fingertips to get you started. With all these robust ecosystem, we, as I mentioned, we have a strong community. If we look at on the next slide, this data was pulled from the GitHub and past two weeks, merely the past two weeks, there are 1600 people uniquely cloning Zephyr. These are the people using Zephyr for real projects and their development efforts. As an open source project, we take great pride on the community we have built. And we have come a long way in past few years. We have built a diverse contributors in terms of upstreaming features and changes. As you take a look at this from where we started in 2016 and where we are today, number of authors, we have 45,000 commits sitting right now and the boards, as I mentioned earlier, in very beginning, we had one board per architecture. Now that catalog has grown into 200 plus boards and this continues to grow. And the community continues to grow as well. And we collaborate closely. We have active, engaged people in Twitter, LinkedIn and the cooperating on Slack as well. So in summary, Zephyr is an open source and mutual governance real-time OS with a strong community. It's offering full-featured modular RTOS for you to get started. And we have built a robust ecosystem around it. We look at open source as a common good for all of us. All of us around the globe from the industry have obligations to come together and build a great open source that all of us can utilize. So we continue to put our efforts in and we welcome you to join us in this community and push Zephyr's technologies forward. So this is where we are as a Zephyr overview. Now I'm going to hand it over to my colleague, Johan, to walk us through the communication stacks. Johan, take it away. All right, thanks, Badna. So my name is Johan Hedberg. I work for Intel, I've been part of the Zephyr project ever since it went public many years ago. And I primarily spend my time maintaining the Bluetooth stack there, but I've been working closely with the team that's responsible for many other communication technologies. So the idea with my part of this presentation is to go through the various communication stacks that we have in Zephyr and tell you about the current state of them. So next slide, yeah. So let's start with the IP stack. Well, first of all, I would like to say that one of the kind of core philosophies with Zephyr from the very beginning has been that we don't only want to be the core kernel where people creating products have to go and find various networking stacks or other subsystems to make complete products, rather we want to provide those as part of the Zephyr offering. And as such, from the very beginning we have had an IP stack in Zephyr. Now, when we started, we were trying hard to fight against this not invented here syndrome. So we looked through the existing embedded IP stacks, open source IP stacks that were available. And we ended up originally using the stack from an RTOS called Contiki. And that one was working pretty well for a while. But then we realized that we were adapting it so much to Zephyr and it ended up changing so much in Zephyr that we couldn't really upstream the changes and it became very hard to maintain. At which point we made the decision that it makes more sense to implement a fully native IP stack for Zephyr. And that's what we've had now in the project for several years. And in terms of features, we think that we have pretty much everything that you need for a typical Internet of Things node type of embedded device and many features beyond that as well. So the IP stack that we have, it supports both IPv4 and IPv6. It supports address auto configuration for both of those with the various protocols that are available for that. We also support industrial use cases like the time sensitive networks with the precision time protocol where we also support master and grandmaster roles. And then things also like 8021 QIV. Then as the main application interface for the IP stack, we have standard BSD Sockets API. So that should make it fairly easy to port existing applications that use BSD Sockets on this effort. And we've done that ourselves, for example, with the CVT Web Library that implements a sophisticated HTTP client and server. Then also to simplify the application developer work for doing secure applications. We've extended the Sockets API with a non-standard set of call for doing TLS as well. I think we copied this from Linux. So it's not completely from scratch in invention there. Then since we have the Sockets API, we actually have the possibility of supporting offloaded IP stacks as well. So there exists solutions where you have the IP stack on a completely separate chip and there's a higher level interface that you talk to that chip with. And as long as you're using the Sockets API in Zephyr, we can actually abstract that the way. So you don't need to know if you're using the native IP stack in Zephyr or if you're using something that's offloaded to another chip. And then lastly, I'd like to mention that we've done, since this was a stack implemented from scratch, we've done fairly extensive compliance and security testing on it to be sure that there are no really bad bugs in it. So we've been using this suite called Maxwell Pro for doing the compliance and then also a suite called Defensix for doing fast testing and that kind of stuff. So this has given us a fairly good level of confidence that the stack is on a very good robustness level and compliance level. So next slide please. So let's look at the little bit more higher level features or rather application use cases that you can do with the Zephyr stack. So we have your typical application level protocols that you would want to have in IoT devices like co-op and MQTT. Then of course we have support for traditional HTTP as well. And I mentioned earlier that we were using the CV12 library to implement this using an existing solution that uses the Socket's API. We also have a native HTTP client in Zephyr as well as a WebSocket client. Then to help with corporate use cases where you're sitting behind a firewall and you want to test your Zephyr implementation we have SOCKS 5 support so you can actually get through your firewall, your corporate firewall and do testing with the wider internet. Lightweight machine to machines is another thing that we've actually been doing demos at earlier conferences with Zephyr there. And thread support is something that we also got a few years ago using the OpenThread project which is quite widely used. Then about the various technologies we support a couple of boards in Zephyr which have internet adapters on them so we have drivers for those and you can get a network connectivity with that. We have the possibility of building an application with Zephyr that makes it an USB internet adapter basically. We have Wi-Fi with IP offload support which I mentioned earlier. Then there's a bunch of technologies with six-low support that we can use six-low with. The most common one probably is the 802.15.4 but we also have the IP stack in Zephyr integrating together with the Bluetooth stack for having six-low PAN support for Bluetooth LE. So you can do IP links over Bluetooth in that sense. And Canvas is a fairly recent addition to that. And another recent addition is also a point-to-point protocol support to be able to work with external modems. So then another quite important communication wireless communication technology we have is Bluetooth and that's something we've supported from the very beginning. Although when Zephyr launched, I think we only had the host support, the controller side came a little bit later. But on the host side, we've been working hard to keep the stack compliant with the very latest specifications. I mentioned here that it's a 5.1 compliant but we've actually got features already from the 5.2 specification of Bluetooth as well. The primary use case as Zephyr targets small embedded devices with constrained resources, Bluetooth low energy is the most natural fit for those. But we've also wanted to support Bluetooth classic in case somebody wants to build a device using that and has some use cases for that. But that's ever since it was introduced, it's actually been flagged as experimental because there are no major boards in Zephyr that support Bluetooth classic. So most of what I'll be talking about relates to Bluetooth low energy here. The host side of Zephyr, it's using the standard host controller interface which is specified in the Bluetooth core specification. And there's a bunch of standard transports for that. So physical communication transports for the host to talk to the Bluetooth controller. The common ones are UART. So we support both with Zephyr floor control as well as with hardware floor control, UART. Then we have support for USB as well and a few others of the HL transports. And there's a fairly clean abstraction for this but it's quite easy to add new ones if you have use cases for that. Then in order to make and sell a Bluetooth product, you need to go through this process called Bluetooth qualification. And we try to make it as easy as possible for companies wanting to build products out of Zephyr by making sure first of all that it's, it passes all the qualification tests all the time. But in addition, the Zephyr project itself has actually gone through the process of qualifying and creating a sort of qualification listing on the Bluetooth.org website where you can then simply refer to that listing as part of creating your qualified product. And the last release that we did this for was the LTS release last year. There has been subsequent qualifications of newer Zephyr versions as well but those have so far been done by member companies. They can still be reused in the same way. It's not done in the name of the Linux Foundation. And our plan is to qualify the next LTS release as well which is coming next year. And one of the features of the Bluetooth stack since we have the standard HCI transport support is that we can actually do different kinds of builds of it. So you can build the host alone and then expect to have the controller available through some physical transport. You can build the controller alone and then have it provide the physical transport to host somewhere else. Or you can combine these together into what we call a combined build where there's still your standard HCI messaging going on between the host and the controller. But it's all done in runtime memory. So we encode things into network buffers and then the controller decodes them and vice versa when data's coming from the controller to the host. Ever since we started developing the stack we've had more and more companies joining it and it's quite diverse right now which I think is very healthy for the project. So there's not a single company that could be dominating the development of the Bluetooth support. So that's a good thing. The Bluetooth mesh support is something that is one of the most recent additions and we kind of pride ourselves in that the Bluetooth special interest group has taken both the mesh implementation as well as the host stack itself to be used in its reference materials. So if you go to the Bluetooth.org website and you look for developer guides for creating Bluetooth applications it's actually using Zephyr as a reference there. So that's a good starting point for somebody wanting to develop Bluetooth applications with Zephyr. So next, yeah. So a little bit about the Bluetooth controller support. First of all, this is a fairly recent thing in the industry to have at all an open source Bluetooth controller implementation. I think five years ago, none of this existed and then suddenly at the time when Zephyr started gaining traction there were a couple of implementations that came to be. And one of these was contributed by Nordic Semiconductor to Zephyr. And we actually have the second generation of that going on now. So the first Bluetooth implementation we had in Zephyr that was quite strictly tied to Nordic Semiconductor's hardware. In principle, you could have adapted that to other radios as well, but it was fairly complex. But now we have something called a split link layer in Zephyr, which splits it into the upper and lower parts. And the primary purpose of this is to allow creating new implementations of the lower link layer that adapts to different kinds of radios. So you can actually use the Bluetooth controller on more than just a single piece of hardware from one vendor. And we already now have support for more than the original Nordics NR5 family. So we have the Vega board support, RISC-V and then there are companies who are working downstream from Zephyr that have adapted that to their hardware as well. But at least so far this implementation isn't upstream. But already the fact that we have like two, three implementations has given us good feedback to know that the abstraction that's there between the lower and upper link layers is fairly good and flexible. Another thing, of course, that's important when we want to support different architectures is to be conscious of what's the native NDNS of the architecture that you're running on. This is something we have supported from the very beginning, that we don't make any assumptions of the NDNS of the host CPU architecture. So it will work both on big and little NDN machines. The way that the interface is designed is that the procedures are all asynchronous. So we're not blocking up operations and any procedures that are taking a longer amount of time. And the second generation of the controller is extremely efficient also in utilizing the radio. That there's very little waste if you do an analysis of if you're asking it to do multiple things like serve multiple connections and do Bluetooth low-energy advertising and so on. It's very efficiently using the available bandwidth there at the time. And when you're not using it anything, the usage is very low, the CPU consumption, so that that's a good property of it as well. And there are really no hard-coded limits on the kind of use cases that you want to do, how many connections you want to support or how many advertisers or scanner instances you have. So in practice, these are simply limited by how much runtime memory you have and then what the actual timing constraints are. So how much time each instance requires for itself. So this allows fairly flexible implementations and use cases to be done. Next slide. So then lastly, one more technology, I guess which you could call the communications technology is USB support. We have primarily started off with the device side since that's what your embedded systems would normally want to support. And we have support for several different MCU families with USB device support. So this is the SD micro, the Kinetis Nordics support as well as AdMels devices. And we have full USB 2.0 support. Supporting both full and high speed. And we have various classes of USB devices that you can create out of Zephyr. So I think I mentioned earlier that you can do an Ethernet controller out of Zephyr. We support mass storage. So we have the FAT file system support in Zephyr and you can export that through USB to your PC, for example. We have HID support. So you can do, if you have a Zephyr board, which has accelerometers in it, you could implement a 3D mouse or something like that using HID device firmware update is another thing that supported. And then of course Bluetooth. So there's a sample application in the tree that you can build that creates a standard USB Bluetooth adapter out of Zephyr. You can plug that into your PC and it will just show up automatically. And all of this is tightly integrated with the main operating system, which means that it's very low footprint. Another nice thing that we have in the USB stack is the flexible descriptor instance in which allows you to make multifunctional USB devices. A couple of additional nice things we have, demos that we have done is we have support for the native POSIX platform where you can run Zephyr as a native application in Linux. And you can do USB development through that. And we also have a sample for web USB. And yeah, that's what I have for the communication. So let's go to the next topic. Thanks, Johan. My name is Maureen Helm. I work for NXP and I've been working on Zephyr for a number of years now. I'm working as a maintainer for NXP platforms in the ARM architecture, as well as a member of the Technical Steering Committee. So I'm going to spend the next few minutes given an overview of releases, both our mainline releases as well as our long-term support releases. So next slide, please. All right, so starting off with our mainline releases, this is kind of where all the main development happens in Zephyr. We have adopted a release cadence of every four months based or built off of the main or master branch of the Git tree. Our most recent release was made just over a month ago back at toward the end of September. This was our 2.4 release. And we are actively working on our next release, which is 2.5 scheduled for January of 2021. There are two parts to the release cycle. The majority of that time is spent in what we call the merge window open stage. This is where all of the main activity happens, right? This is, you know, we're merging new features, adding enhancements, bug fixes, documentation, you name it, this is the bulk of the development or where the development happens in Zephyr. Now, the last three or so weeks of the release cycle, we then back off a little bit and try to stabilize things before we actually finalize the release. And so this is our stabilization period. And what we do during this period is we slow down the merging of features and enhancements and we instead focus on bug fixes and documentation, any kind of release related patches. We do allow for exceptions if there's a new feature that was close to being ready or just barely missed it. We do have a process where if somebody still wants to get that in, they can take that to the technical steering committee and request an exception. Now, during that time, even though we are generally not merging new features and enhancements, it isn't important to remember that the community is more than welcome to continue submitting things to continue submitting pull requests for new features and enhancements. They can still be submitted, they can still be reviewed, although that being said, sometimes the reviewers are more involved in the release process. So they may not have a whole lot of bandwidth to review patches, but that process can still continue going forward during the stabilization period. Now, what signals the start of that period is the release manager rule tag, then RC1 or release candidate one tag, and that signals when we stop accepting new features into the tree. As we go through that, we'll iterate. So for each release candidate, we'll then kick off a bunch of regression testing, various member companies have board farms where they'll go run regression testing on physical hardware and then submit new bugs that may have been found during that testing period. And so we'll do that several times. Usually we'll get to an RC1, RC2, RC3 states where we finally take a look at, we have a set of release quality criteria that determines whether the release is actually ready to go. And this consists of looking at the total number of bugs that we have outstanding that haven't been resolved. So we generally classify bugs as high, medium or low priority. And then finally, after the release is actually complete, we do have mechanisms for back porting fixes. So if security vulnerabilities are identified, we will back port fixes to the two most recent releases. Next slide, please. Shifting gears a little bit, the other type of release we have is our long-term support or LTS release. This release is targeted more towards production and long-term support. So the Zephyr project made our very first LTS release back in the spring of 2019. This was our LTS1 or the 1.14.0 release. We are actively working towards our next LTS release, which will be about two years after the initial LTS release. So that will be our 2.6 plan for May of 2021. Now, during the two-year support period, we will back port fixes for security vulnerabilities, bug fixes and things like that for the entire course of the two years. We've done two of these to date. We've done a 1.14.1 in October of 2019. And then we did a .2 in April of 2020. And we do these as needed based on any kind of bugs or security vulnerabilities that get identified. It's important to remember that we do work toward maintaining any API compatibility here. So this will, you know, taking an LTS update won't impact your higher level applications. Next slide, please. A little bit about how these releases actually happen. We have a group of highly active maintainers in the project that we call our release engineering team. This consists of about six to eight people represented by different member companies. So this isn't just one company managing all the releases. We work hard to share the load across the member companies. Now, this release engineering team are the people that are responsible for merging code changes. So as pull requests during the merge window open period of a general release, it's the release engineering team that will actually merge pull requests into the upstream main or master branch. This team meets weekly to triage new bugs that get reported and monitor fixes that come in and actively work toward getting those bug counts down as the release cycle progresses. This team also keeps an eye on the continuous integration. So those of you that have contributed to this effort know that we do a lot of continuous integration. We do a lot of build testing across the 200 plus boards that we have supported upstream and tree. We have nightly builds, a lot of build testing to try to make sure that we keep that master branch in a buildable state. The release team also is responsible for reviewing backports toward that LTS branch. And so each week in our release meeting we'll take a look at any new backports that have been submitted for the LTS branch. And those backports first have to be accepted into the master branch. And once that happens, we'll make sure that we have reported a bug report for that backcourt fix. And then if that team agrees that it should be back included in the LTS, then we'll go ahead and merge it. Within the release engineering team we have a release manager role. This is a rotating role by release. And so each new release will select a new release manager. And this is a pretty critical responsibility and so that's why we kind of try to share the load. And this person is really responsible for kind of bringing that release through completion. They'll lead the weekly release team meetings, they will monitor all the bug counts, they will coordinate getting all the release notes ready to go from all the different subsystem maintainers. They're the people that are the release managers, the person that actually makes the, or tags the git tree and publishes the candidates and announces them as well onto the mailing lists. Okay, next slide please. So taking a look a bit into what kind of features we have planned, both what's been landed in our most recent release as well as some features that are coming in our next couple of releases leading up to LTS too. So as I said earlier, we had the 2.4 release just come out about a month ago. And so the highlights that came with that release were around firstly, some initial support for virtual memory management landed. We saw some on the Bluetooth subsystem side of things, there was host support for some periodic advertisement and us operative channels. This is leading toward LE audio support and a future release. For the networking subsystem, the TC, there is a new TCP implementation that was introduced a couple of releases ago and we shifted that to be the default now in the 2.4 release. We saw new tool chain abstraction land and this is an important introductory milestone toward supporting additional tool chains. So historically, Zephyr has supported GCC based tool chains but we are looking toward expanding that to things like LVM Clang and proprietary tool chains like IR or RMCC. So all this tool chain abstraction is a stepping stone toward that direction. But the last thing that's important to note about the most recent release is we made a concerted effort to reduce some technical debt. And so as I mentioned before, when we make releases historically, we've looked at bug counts. We've had basically to say, okay, there can't be any outstanding high priority bugs. There's a threshold of low priority bugs and we typically haven't had any kinds of thresholds to gate releases based on the bug counts for low priority bugs. And this has led to a fairly large backlog of what we've classified as low priority bugs. And so for the 2.4 release, we made an effort to work down this technical debt. And so at the beginning of the release, I think we had somewhere on the order of 300 low priority bugs and we worked to bring that down to 150. And then the goal is to continue working that down over the next two releases. And so by the time we get to LTS2, it will be a much more manageable number. Now looking forward to the 2.5 release is just what we're actively working on right now at the beginning of January, due at the end of January in 2021, there is a lot of activity going on right now around device tree and pinmuxing and standardizing that across the different vendors. It's largely been around ARM, but we're seeing that happen in various areas. Let's see, so there's also a goal to continue on that tool chain abstraction front and to have LVM support on all applicable architectures. I mentioned already technical debt. Now, this is then leading toward our LTS2 release in next May, which is our 2.6 release. Again, we'll continue working down that technical debt. As Johann mentioned, we will re-qualify our Bluetooth host and mesh parts of the stack and as well as working on some safety related coding guidelines compliance. And so Amber will talk about that here in an upcoming part of this presentation. Now, as many of you know, doing roadmaps in open source can be challenging. It's difficult sometimes to know what features are coming when. So I did want to also highlight a number of features that are actively being worked on, although we don't have firm dates yet is when these things will actually be landing upstream. So if you're interested in any of these additional features, just wanted to bring awareness to those that they're coming and if you want to contribute, you're definitely invited to do so. So I mentioned IAR, there's some sound open firmware work happening, S&P. There are some members that are interested in expanding that from X86 architecture and ARC architecture to also including RMembers 5 as well as more expanding support for power management. Okay, next slide please. So I had the privilege of being the release manager for the Zephyr 2.4 release. So I wanted to take a quick look at some of the statistics that I found in this release. And it's really exciting to see how much this community has grown over the years. So over the course of our roughly four months, 113 days, we saw over 3,000 commits land into the master branch submitted by over 200 authors. Now what I think is the most exciting statistic that I found looking through some of this data is that we had 83 new authors contribute patches in this release. And so I'm welcome to everyone that is joined recently. We're really happy to have you. All right, with that, I'm gonna turn it, oh, sorry, I forgot about my resources slide. This is more for future reference offline after this presentation. If you wanna learn some more about the topics that I've talked about, here's a slew of links you can go check out. And with that, I'm gonna turn it over to Ruud from Synopsys who's gonna talk about security. Thanks Maureen, indeed, let's talk security. My name is Ruud Derwig, I'm working as a security or system architect but also focusing on security with Synopsys. I've been involved with Sefer from the start in various roles. So maintainer for the architecture, representing Synopsys in the technical steering committee. And also member of the security committee. So that's the topic for this section of the summits. Now you can go to the next slide, Vets, thank you. So Barnard introduced their first slides, the vision of the Sefer project, basically becoming the best in class artals. So how does that translate to security? Obviously, Sefer wants to be the world's most secure artals. But that's not easy because it's targeting connected devices. And that basically means you have a huge attack surface or at least anyone can attack connected devices through the network links. You don't need local access to the device to try and temper with it. Next, the devices Sefer targets are a resource constraint. So that basically means they are cost sensitive typically that translate into the products not wanting to spend efforts, costs, hardware area, footprint, code space for security. So security has to be no cost. Well, that's not that possible but we try to minimize the impact there. The last challenge is that attackers keep evolving, right? That's a growing set of attacks but also the type of attacks change over time. So tools for doing attacks become readily available and you can download the scripts for doing attacks. And basically that means that also on the defense side devices need to be more and more clever and add more advanced countermeasures. A security talk should always have some example of a recent attack. The one I picked, you see a picture on the right bottom is Ripple 20. So that is attack vulnerability maybe consisting of 19 zero-day vulnerabilities in a networking stack. And the name for this attack was chosen to be Ripple 20 because by attacking this network stack which was used in many, many different devices the attack basically ripples through, right? So there's also a characteristic of Zephyr being an Artels, it's a foundation component used in many type of devices. So if there are vulnerabilities in one and basically there's vulnerabilities in all, right? So how do we counter these? Well, there are three aspects I wanna zoom into. So first of all, for the technical aspects features and architecture in Zephyr with respect to security and then the process and organization aspects and finally testing and certification. Can you go to the next slide, Bratz? So features and architecture. First of all, it starts with cryptographic functions. That's the algorithms for encrypting but also for signing, verifying, authentication, integrity, protection. Zephyr has a crypto and a driver API for these crypto functions and also for random numbers which are often used in security protocols. And for these APIs we have various implementation. So software implementations using embed TLS and tiny crypt stacks but all applicable are hardware platforms that have hardware acceleration. These drivers have been implemented or these drivers implement on the hardware accelerators. So giving better performance, lower power and sometimes also more secure implementations. The next feature or architecture aspect is what I call platform security. So that deals with the trust in the software that you are running on the system. So it starts with secure boot. Within Zephyr, we use the MCU boot project for this and instead of just referring to, well, please use MCU boot, we really do integration of that. So the Zephyr build environment was includes the scripts for signing and potentially encrypting of firmware images. Next is hardware and software stack checking. A lot of attacks exploit software bugs that leads to stack overflows. So on platforms where we have hardware support, these can be enabled. There is also support in the tool chains using canaries that we support. So that's both hardware and software stack protections. The types of devices Zephyr runs on often don't have a memory management unit and virtual memory. That makes other space layout randomization a bit hard, but at least for stacks, we do a bit minimal randomization of the stack layout. Then for processors supporting multiple privilege levels and having memory protection or memory management units, we support user space. So there's kernel threats and user space threats. And this also includes access control. So for all threats, you can specify what kernel objects can be accessed. The user space separation also includes different memory domains and stack isolation. So user threats cannot access the stacks of other threats, but also can be part of certain memory domains. So memory variables can be brought access to certain threats or preserved access to others. Final platform security feature, what I mentioned is support for a secure mode. There are architectures like ARM, implementing trust zone, ARC, implementing secure shields that have an additional secure mode basically for creating a separate trusted execution environment. And Zephyr has support for these as well. Another aspect is secure communication. Johan already mentioned the networking and BLE stacks. So security for that's in the form of TLS, DTLS support is provided by Zephyr. And similarly, the BLE security features are covered. Then there's work on going on additional security features. Security coding guidelines I mentioned here. So we have these guiding developers on how to apply a secure coding style. And helping security reviews for that. And recently also the TFM PSA security solution has been integrated. So that provides features for secure storage device at the station, et cetera. So we have a good basis and the especially on the security services we explained to expand the common time. Next slide talks about the process and organization. So on the organization from the start, Zephyr has had a security committee. So that's consists of a chair, a security architect and various members. Think over time we have had some 20 people, maybe there's some five to 10 really active at the moment. And together basically we manage the Zephyr security processes. So that is defining the security processes, writing the documents, the security coding guidelines, et cetera. But it also includes the day-to-day handling of security incidents. So we handle security vulnerabilities. And that brings me also to the next topics. CVE numbering authority. So the Zephyr project is a so-called CNA that stands for CVE common vulnerability enumeration numbering authority. And for those of you that don't know CVE it's like a large database with known vulnerabilities and the information about it. So in what software do they occur? What versions have they been solved? And that basically helps users to understand what are the risks C in the vulnerabilities applied to their products and what version to use to have a mitigation. So to become a CNA you have to comply with certain rules and we put everything in place on documents and the different process requirements to be a CNA. And that means we can assign the CVE numbers for the database for vulnerabilities in the Zephyr stack. Part of the requirements there is that we have a defined vulnerability process. So that basically consists of a number of phases. If vulnerabilities are found either by Zephyr developers or security researchers or all users they can notify the Zephyr project. For instance by sending an email to the vulnerabilities as Zephyrproject.org. That mail will be received by the security committee and then we start an embargo period. So during the evaluation of the vulnerability and especially also during the fixing of the issues only a limited set of people knows about it. So we have a lot of people only a limited set of people knows about it. We don't publicize it yet. So we have an internal JIRA database so we are not using the public GitHub issues for tracking these. And then we work with the maintainers to solve the issues. One that happens we disclose through the CVE numbers but also we listed in release notes for Zephyr. Next slide talks about the vulnerability alert registry. So as said we have an embargo policy but of course besides Zephyr itself downstream product device makers also needs to know what vulnerabilities to fix. And moreover it also needs some time to fix them and provide software updates to their devices. So for that we started this alert registry. You can sign up for it. If you are a product vendor some requirements you have to meet you see them on the slide on the right. And when you are admitted to this list then you get early warnings on the vulnerabilities during the embargo period. Zephyr projects strives to solve the issues within 30 days. The embargo period that we chose actually is 90 days so that leaves 60 days for vendors to update their products or take all our countermeasures. Last process aspect on this slide is the core infrastructure initiative gold badge. Zephyr was one of the first projects achieving this gold badge and it is basically about best practices for open source projects. In infrastructure, inversion management, hosting, release management but also security practices. And we are proud to have been one of the first gold bonds there. Other open source projects I really recommend to have a look. It's a good list of best practices to apply to your project. Next is the third pillar testing and certification. So this is about avoiding security vulnerabilities in Zephyr. So first of all, we have a rigid code review practice for Zephyr basically using the secure coding guidelines. It's not just the security committee that does this code review. Basically we use the GitHub reviews. Every PR needs to be signed off by at least two people. So besides the security committee also the maintainers and all the people are involved in these reviews. Next, we leverage a lot of tools and automation. So we run a sanity check, script and basic tests on every boot request. But we also weekly run further code analysis. Static code analysis. We use the public covariate scam service. Coverage is a synopsis tool for static code analysis for security and quality issues. But as for open source projects there's a public free version covariate scam. So we do like weekly scams and then based on the results we create GitHub issues and inform the code owners. Another tool that you have already mentioned is Defantix. So there's a fuzzing tool that we use for the communication stacks and ongoing work in progress currently is to do more fuzzing also on the software APIs. For instance, fuzzing the system calls for user space support. Besides the projects we are actually quite happy that also other people look at our sources and if they find vulnerabilities notify us. So a recent example is a report. I'll talk a bit about it on the next slide from the NCC group. But before zooming into that I want to talk a bit about certification. So one of the ambitions for Zephyr is to certify according to some security standards the articles has a lot of proof of the security of Zephyr this is work in progress basically one of the discussions we are having is what standard to certify against should it be like FIPS 140-3 should it be common criteria should it be one of the derivatives SSIP PSA basically there are many, many standards to choose from what complicate things is that the certification often is done on a product level final product level and most on the the software stack alone. So we haven't really made up our mind yet how to implement this certification. What we find important at least as important as the certification itself is to make sure that the articles is certifiable so that we have the process and technical features in place that meets these different certifications schemes. Next slide Brad Thank you. So I said the NCC security reports so this was a very useful help from the NCC group that we got this year they did an analysis of the Zephyr Artos and MCU Boots and found 20 similar abilities 25 in the Zephyr Kernel and one in MCU Boots and now obviously we have fixed these somewhere really say medium or low priority but definitely the critical and highs have been very quickly been fixed and also back ported to the LTS release. Meanwhile the embargo has passed so I think in May or so the public the report became public so you can find the details you also see in the release notes for instance for the 114.2 what CVEs have been addressed and this was a great help for improving the security of Zephyr. Besides that we learned also something for our process earlier for instance we had the embargo period for 60 days we increased that to 90 days including time for downstream public developers to resolve issues prepare for that. So that brings me to the last bullet on this slide Zephyr continues to improve you actually see a quote on the NCC group where we got some compliments that we really were really fast in resolving the issues in reasonable time so security unfortunately is not like a feature you develop once requires continuous effort and that's what we continue for the next releases yep that is the end so next you'll hear about safety from Amber can you all hear me yes we can hear you okay perfect and it looks like you just refreshed Brett yes thank you so much hey everybody let me turn on my camera alright you should be able to see me now hear me hello everybody my name is Amber Hibbard I am an engineering manager on the Zephyr team at Intel and I'm going to talk to you today next slide please Brett alright so for those of you that may not be super familiar with safety I'm just going to give a very high level introduction to how it's defined and what it means for us so safety in software is really about minimizing or mitigating systematic faults in our code base and this is fault systematic fault is something that's introduced in the development process as opposed to random faults which should be something in the hardware that could arise from random things like bit flips why are we doing safety so by following certain safety processes which we'll discuss later in the end the hope is to provide a very robust and high integrity code base low systematic faults and that can be used in safety critical applications there are many examples of safety critical applications and a number of different market segments from automotive, industrial, medical so you can think about you know a software defined factory where you have robots working closely with humans you can think about autonomous vehicles self-driving cars and then tons of medical examples et cetera to meet safety there are a number of standards that are out there I've highlighted here at the IEC 6108 standard this is effectively a parent standard for many of the other standards that are out there so the children standards to IEC 6108 are more targeted towards these different markets for example ISO 26262 which some of you may be familiar with is targeted towards the automotive segment but IEC 6108 is kind of the parent standard and as I'll discuss this is the standard that the Zephyr project has decided to pursue initially next slide please okay so when we think about safety standards and going towards safety a lot of it can be understood in the context of what's known as the V model which is represented on the right hand side of this slide so the V model can be thought about as a way to do software development and if you follow it to certain to a certain rigor and meet certain requirements you are essentially meeting what is found in a lot of these safety standards and so if we start from the left hand side and kind of work our way down you think about overall software development as starting from really well defined requirements so you would have some market requirements, product level requirements and from there define what your software requirements are going to be from those market use cases once you have defined requirements then you work on your architecture module design how you're going to do the implementation and then you do the coding at every step during this process there should be verification that's happening and that's what's kind of represented on the right hand side of this V of the V model so at every step from requirements to code you verify that you are producing what you are intending to produce and at the end there should be some overall validation that you've done this so for software that undergoes compliance safety development often the V model is followed closely so if you're a developer being an open source project this is not necessarily how it goes and for open source software because of this there are additional challenges to meeting safety requirements and to gaining a safety certification so I mean for open source you don't often start with like some defined set of requirements you have a number of people from the community and you don't always have a rigorous requirements for the traceability to be established when you're doing this so all of those things just leave two additional challenges here for open source but in the end what we need to do and what we're doing at the Zephyr project is to basically provide the evidences that what we have in our code base can map back to this V model and the compliant development and that is what we're doing so I'm going to next talk to you about where we're at with the project with our safety so next slide thank you Brett so we established the safety committee a couple years ago in 2019 we meet bi-weekly we have really nice participation there there's typically around like 10 different people core members who are attending we have made some initial decisions in progress so we decided on following the IEC 61508 standard the one I mentioned on the first slide and this is our initial target because it is the parent standard to a lot of the other market specific standards and once you have compliance to the standard there is often a small delta to reaching the requirements of other standards specifically in the IEC standard we are following what's called route 3S this is what you follow if you have a pre-existing code base that you're working to certify which is the case for Zephyr we have published a coding guideline and we are working on the CI enforcement for that so to arrive at this coding guideline the safety committee would include something like 300 plus different guidelines from the MSRC standard from JPL from cert C and we from that super set agreed upon a set of around 100 plus coding guidelines that apply to Zephyr and that we fill will really increase the integrity of our code base we have a number of other activities that are just starting or in progress and these are to meet traceability so overall we need to show that we have traceability from requirements to tests we need to meet 100% test coverage for all of our requirements that are in our safety scope there's a lot of work around tooling making sure that the tools that we use in our software development have been evaluated and in some cases qualified or validated to show that they themselves are not introducing systematic fault into the code and we are working on our engagement with a certification authority that will help direct us towards meeting safety standards and in the end give us the safety certification against IEC 601508 next slide please okay we have also decided on our initial certification focus and so the idea here is that we will for our first iteration of safety certification pursue a limited scope right because this is something that is new to the Zephyr project and so we want to start with essentially the core OS what we call the core OS and then in additional iterations out on top of this and so you can see here our scope our current scope it's in blue so we have the kernel some OS services logging debug low level apis architecture interfaces we've decided on x86 and ARM architectures to be part of our initial certification scope and then once we have this baseline certification done we do intend to expand add additional components and do delta search on top of it including some other subsystems in the future next slide okay this gives you kind of a high level idea of the activities some of which I've already spoken to that we have on our roadmap the overall goal here is to buy LTS to so Zephyr release 2.6 next spring to have most of the changes in the code that will need to be done before we create an audible code base so we plan to branch off of LTS to create an audible code base and then on top of that do the remaining work that's required for certification a lot of that will be at that point hopefully documentation so just walking from left to right here so I highlighted with Zephyr release 2.4 we publish our coding guidelines we are now 2.5 timeframe and we are working on the tooling and processes that we need in general but also specifically for traceability since the requirements to test are such a big part of safety requirements along with all of the tooling we're doing the tools evaluation so looking at every tool that we use in our software development evaluating those tools or potential to introduce vault into the development so that's tools classification and then for those tools that are quote-unquote risky we'll do further work to qualify the tools validate them to minimize that vault that could be introduced we're working on the CI infrastructure for our coding guideline compliance and we're working on publishing our requirements the functional requirements that would represent that architecture scope that was shown in the previous slide by LTS-2 we want to have our coding guideline compliance achieved we need to have 100% test coverage et cetera and then last slide I actually I want to keep this one for backup Brett if there's questions later on this goes into more specific details of the safety collateral that we will be producing as a project as part of our safety certification and kind of the breakdown of whether those artifacts will be public or reserved for platinum members but I don't want to go into the line by line detail that's it from me perfect thank you again Amber up next we have Michael with at micro Michael hello hello can you see me can you hear me we can hear you great awesome thanks very much so let's get started if I may ask for the first slide all right so welcome everybody today I'm going to tell you about a building tiny ML ecosystems with Zephyr of course TensorFlow Lite Micro as well as Renote and especially how do we build like a well tested ecosystem that enables us to do things that don't break I have a lot of materials I'll be asking Brett to advance the slides very quickly so let's see how that works so next slide please a little bit about where I'm coming from some my company is founded more than 10 years ago and consistently we build open source platforms we build open source products and especially important I think to say is that we're members of quite a few organizations that drive the open source ecosystem forward including Zephyr project of course but also like Risk Five International and related organizations next slide please and we kind of do a bunch of things starting with hardware especially software that's kind of our major focus I also do new platform development you know an FPGA and an ASICS however if I may ask for the next slide tools is the most important aspect of what we do tools is kind of permitting all the other things that we do because the new methodologies the new ways of working that we enable with new tools are kind of critical to being able to do many things effectively in a software driven way and I'm going to show you today how we kind of how we think about developing tiny machine learning applications and what kind of tools recommend to do that next slide please tiny mail let me first define this it's basically the trickling down of machine learning capabilities into smaller lower power devices and those devices have a certain number of advantages first of all they just use less power than big devices they're less complex they don't have to communicate wirelessly into the cloud if they can do machine learning on board they don't need to ask you know a server for data or like communicate back they can do stuff autonomously this also increases responsiveness of those machine learning algorithms as well as the privacy because of course you don't need to transmit sensitive data outside this also enables new machine learning use cases because you can do very nicely low latency focus gesture recognition you can do sound recognition that's very close to the user and acts immediately you can detect anomalies when they happen where they happen so a lot of great opportunities there if I may ask the next slide there's also a lot of challenges though and of course the constraints in the devices themselves are a problem too you have little power you have low performance you have quite little memory and especially in the testing area you know these are kind of different kinds of devices these are constrained devices that come with their own tool chains with their own libraries they're sometimes hard to source it's hard to kind of deploy them at scale they might involve complex configurations of many unit systems that are connected over various protocols so testing all of this manually is very hard people actually don't test a lot like we've seen among many of our clients they test much less than they would in a regular software development context Zephyr of course tries to fix that with board farms and with continuous integration testing infrastructure but it's hard to copy that kind of infrastructure if you're a small company just trying to build a product so there's a problem with reliability there's a problem with determinism you can even build perhaps a test scenario but you won't be necessarily able to guarantee repeatedly that you're going to get the same result with the same input so in practice your continuous integration setup will be well less than perfect so yeah we need to solve that challenge next slide and now about TensorFlow Lite Micro itself this is the part of the TensorFlow Lite machine learning framework it's part of the light branch of that framework and the light version is oriented on mobile phones so if you go to the TensorFlow Lite page you'll see a mobile phone there as you can see on the right but of course like over time tiny devices micro controllers became so powerful that you can actually and then people at Google thought okay let's try to run machine learning on them and so if you want to see where TensorFlow Lite Micro resides it could be found in the following of GitHub and what it targets is kind of submittal devices like in general of course in practice those devices may be bigger than that but the end goal is to be really really small and focus on stuff that can go on on battery for years right or perhaps even without battery if it's kind of powered by solar energy and so on and what's important to understand with TensorFlow Lite Micro is that it's agnostic to architecture it works with different operating systems so it's not necessarily arm focused or it's not just separate focused it's just a framework for machine learning you can kind of snap on too many things and the collaboration with Google has lasted a while now so we started working with them in 2018 we've been doing a bunch of work in like open source A6 FPGA software machine learning but specifically this work also kind of started in a sense in 2018 when we enabled running TensorFlow Lite on risk 5 that was a proof of concept we did in 2018 for the risk 5 summit and we presented it together at the workshop and from there we kind of went on to continue collaborating we did an initial integration with Zephyr and did some co-marketing with Zephyr in risk 5 about that and then we continued on that path and we integrated that work with simulation and re-node which resulted to in this blog note we did with TensorFlow Lite team on the blog and that in turn turned into a collaboration that's currently like a big collaboration where that team has adopted re-node for their testing for showcasing TF Lite, Micro and so on which I'll be talking about today and the demo that I'll be kind of walking you through a little bit it was created in 2019 well actually late 2019 where we put a software script CPU in a low cost FPGA board, the digital RTA7 and we simulated the entire thing and re-node of course but I'm going to get to that the important thing to note is that that was a prototype of a Zephyr integration so Zephyr plus TF Lite Micro working together and we also got it to be an end-to-end flow where you could of course deploy it on real hardware that's what everyone wants to do eventually but you could also deploy it in CI in the cloud or run it on your computer completely without hardware I'm interested to kind of read more about where that led to there was a blog note published middle of 2020 about well running this entire thing in simulation and in CI okay so I've been telling you about re-node but I haven't told you what re-node is so perhaps we'll start with yeah it's a framework it's a tool for developing IoT stuff it's a simulator of course in the most basic context in the framework because it's actually a development framework and people have used it for various things we initially created re-node for development of complex software for embedded system for IoT you can simulate your hardware and then run your software on this virtual board or set of boards in re-node but it turned out that people actually want to use re-node for various things like architectural research like pre-silic and prototyping and hardware software code development in fact the flexibility framework has enabled different kinds of use cases it's been in development since 2010 so it's a pretty kind of framework for long history we open sourced it in 2015 and like to give you a third round number in 2020 which is today admittedly not the best year in history re-node has been pretty successful and has been gaining a lot of traction I'm going to show you a little bit of that in a second what we think is good about re-node is basically a few concepts that it follows first up it's because re-node has those plug and play building blocks that you can kind of use to assemble your platforms you don't need to write a lot of code you typically just go and write configuration files and that's it your platform is working secondly we have the batteries included approach where we have a lot of demos and binaries you can just play around with just after downloading re-node you don't need to kind of compile your own I mean you should eventually but if you just want to get started there's a bunch of demos that exist and you can we host them on our servers you can just download them and play around it's also very flexible and I think what's important to note it's the fact that it's software agnostic so it's like I'm talking about it in the Zephyr context of course it doesn't need to run Zephyr it can run various kinds of software but us being strong supporters of Zephyr of course we're kind of very happy when people run Zephyr on it and the last thing to be said here is that it's very very CI oriented even though of course I'll be talking around some interactive use cases in a second actually a lot of our infrastructure a lot of our features is kind of related to continuous integration we have a good support for the robot framework for writing tests we have integrations of Jenkins GitHub CI, GitHub actions and so on and one other thing perhaps that needs noting is we enable people to test protocols and stacks like connectivity is also kind of part of what ReNode enables you to test and people have used it to test stuff like OPC UA we've actually developed TSN in Zephyr so we used it to test TSN 6Lopan thread and so on and so on sorry one important thing for understanding ReNode is to look at this picture and realize that even though simulators if you think about simulators they typically make you think in this context of a system on chip so on the left side you can see a system on chip and we can simulate that of course that's pretty normal so we can simulate a CPU we can simulate a bunch of IOs around the CPU but then you can go and simulate an actual board a full system with sensors with buttons even screens we can do frame buffers and stuff like that and you can go even further in ReNode you can simulate an entire system with a network with a gateway connected to multiple sensors and that gives you an ability to test your system end-to-end the entire use case with all the software that's running in it and especially important is the notion of simulating peripherals and sensors so we don't just focus on SoCs but kind of all the IOs and sensors like thermometers and humidity meters accelerometers, microphones especially in the machine learning context you can imagine that we can test the entire use case where we see what's going to happen if you put some data through the sensors into the machine learning framework like TensorFlow Lite Micro and what kind of output are we going to get and how is this output going to affect the entire system because you can imagine that this device then goes and steers another device to do something in response to a positive outcome of a machine learning algorithm and we can do this end-to-end testing of entire systems. We support a number of vendors and platforms here's a bunch of course our friends at Nordic, NXP Microchip, ST all the familiar faces in the Cortex M world I'm going to tell you a few words about QuickLogic later on and of course the excellent 5 architecture as well as OpenPower, both open source ISAs, so plenty of stuff of course our major focus is microcontrollers but we also have pretty beefy platforms like Microchip's PolarFire SoC which is a 5 core RISC 5 FPGA SOC that runs Linux so quite a beast and we can simulate that too if you want to take a look at boards there's a supported board section in our documentation here's some of them here's like I think it's on this slide and on the next slide we can see 10 more and that's not even all of them but you might recognize some of those and kind of get excited and hopefully go and download, re-note and run a virtual copy of that board okay so how's it work if you want to see a repository here's the repository on GitHub and I'll walk you through some of the files in that repository which are meaningful for re-note the first one is an I2C controller in C-Sharp like basically re-note is written in C-Sharp it's the .NET platform so we can actually write peripherals in Python if you want we're actually experimenting with writing peripherals in Rust but the majority of our IOs is actually C-Sharp and this is like an interesting case because here at the point in time when we did this we didn't have this I2C controller inside of re-note so what we did was we did that externally and re-note can load peripherals on the fly you don't have to recompile the framework you can just kind of load a file and you're getting a new type of peripheral model inside the framework if you go to the next slide that's data files so obviously as I mentioned we can do an end-to-end flow where we input data into re-note and see what happens so like that's the cool thing we have determinism right we can fully deterministically run stuff and the result will always be the same so being able to feed like the same data over and over again and see what happens is crucial for continuous integration on the next slide we see the REPL file so if you go to the next slide that's our platform description format so re-note platform file REPL is a human readable modular extendable format and as I mentioned before essentially if you write the REPL file it's just a script right it's like a device tree file so you write this and you can essentially make it simulate a new re-note platform without writing a single line of code if we go to the next slide we'll see what this REPL file looks like here's a UART cpu and an interrupt controller for a RISC 5 system and basically that's it right the next slide is RISC file which is a script file so any command that you can input to the re-note CLI you can also put in a script so it's just a scripted language and the last file there what happened here sorry let's skip two slides then that's actually the demo that if you run this repository if you go download this repository and try to run it as instructed you're going to see this kind of output so to start from the beginning you know you go to re-note you run re-note you run the script the console appears with a nice re-note and the UART output you start the demo and then you see those files are being fed into re-note and they're being recognized as gestures this is a ring gesture and the other is a slope gesture and this is really TensorFlow Lite recognizing those gestures from the data that we're inputting that's the end of the demo basically and it's going to slope twice if we may advance the next slide please okay so a little bit about testing on metrics now getting to this testing part effectively re-note is meant to be used in the company environment so even though like on a local PC you can do a lot of cool things with re-note in the interactive use case it's meant to work in a broader context of the company and you can get some help from colleagues in that context you can kind of have a server that runs continuous integration and a bunch of deterministic tests and we envision re-note to be but like people have said it's the docker of embeddent I think it's Pete Warden who actually said that so I love this comparison because in a sense it's kind of not exact but in another sense it's exactly what we want it to be a platform in which you can build and test embedded systems next slide we can see how an example CI could look like if you go to this repository it has a built-in Travis CI we can work with good lab CI Jenkins we have examples for all these things but this is kind of the easiest to see re-note in action we also have stuff that gives us abilities to analyze metrics of performance and execution this is very good for CI because we don't only see whether things broke or not we can also see whether things are getting better or worse and how they're working over time we can generate metrics from how many instructions are being executed memory, how it's being accessed and so on we have virtual time so we can kind of trace this specifically deterministically because in real time of course it depends on your host machine how fast it simulates things but in virtual time domain it's all deterministic to see this in action we see that's a use case that we did where we kind of analyzed the quantization method optimization method it simplified a CNN network and that was done completely without instrumentation of code, right? This is data extracted entirely from simulation so we can experiment with various things without touching the code we can for example give the code more memory to operate in and see what happens so it's pretty nice for these kind of things if you want to see more of re-note being used in action for testing we have this testing.re-note.io framework where we just run a bunch of different firmwares and systems through re-note continuously every week we have for example Zephyr's TSNSOP system being tested there but also other things, ContiqOS LightEx and MicroPython and so on and in that system you can get nice logs this is actually something that we can set up for our customers to where you can see all the builds on the next slide, you can see build logs and artifacts and so on so this is kind of an entire CI system that's built from open source components and we run it as a CI dashboard so to say for various firmwares on the next slide let's see how you can kind of what we're going to do moving forward and how you can try re-note yourself so currently we're focused on developing this Nano33 BillySense platform that has an Nordic NRF52840 on it, it's a CoreXM4F and that's connected to an AutoCom mini-cameras, an SPI camera which enables of course vision-focused goals we can do person detection for example, we'll be able to do voice detection using the built-in microphone it's a really cool board because it features a lot of sensors, you can see that on the right and yeah, this we'll be supporting that platform pretty well that's a primary platform for the TensorFlow Lite guys it's also being used at Harvard for their courses of course, this is not going to be our only focus we'll also be adding support for more platforms including a very interesting one with RISC-5 on board and we'll also be revamping the entire TensorFlow Lite micro-CI infrastructure to use re-note and specifically there will be a CI for Zephyr integration that's also in the scope of that project lots of incredible things going to be happening in the coming months and one thing that I'm going to highlight too is Google Colab which is going to enable us some kind of, you know, demos where you can record your voice or record your image you as a person and then we'll be able to run that through TensorFlow Lite Micro and see what the results are if we go to the next slide, there's more about Colab here I'm not going to read it all but it's like it's a fantastic tool for presentation demonstration, effectively it allows you to run the code in the cloud you can run re-note in the cloud so you can run embedded devices in the cloud we'll go to the next slide we'll see the results of such a Colab you know, these are graphs coming from the performance analysis framework and this is as good as completing the Cloud it's not connected to any kind of system I mean, this is a system running somewhere in Google infrastructure it's a computer that Google Colab provides for you but you don't have to install anything you can run in five minutes, you take that link from the previous slide and you can get running very, very quickly we're also using re-note for education now we have a course at the positive diversity technology in collaboration with ST we're going to make a board available to students virtually because the pandemic situation has closed up labs in alternative diversity and the course is going to be using a lot of cool technologies including re-note but also like Zephyr, TensorFlow Lite Sphinx.Zephyr also uses for documentation so the entire technology stack will be provided by a micro and there's interest from Harvard to also kind of do similar things if you go to the next slide this is almost the end now just kind of highlighting that these problems are universal and kind of these kind of ideas how do we empower ecosystems, how do we build out a community are shared with of course Google I've been talking about them quite a lot but then also ARM and microchip and quick logic ARM actually is also working using cloud and TfLite micro microchip has been a great partner working with us on the RISC 5 PoloFire SoC and they built an entire pre-silicon development platform based on re-note and quick logic which I'll highlight on the next slide these guys I hope I got that slide yeah, quick logic has been an incredible partner we've built an entire ecosystem of open source with them this is an open source board that we built for them re-notes of course simulates this it's a Cortex-M4 as well Zephyr Arthos that we ported to this board and most importantly there's the first ever FPGA vendor to do open source tooling for FPGA fabric so this has an FPGA on it and you can program this FPGA entirely with open source tools that these guys sponsored and that they support and what's even more exciting is that there's some upcoming products from them that will feature some even cooler stuff FPGAs, bigger cores all of it supported in Zephyr and re-note and so on and it's a joint project with Google so pretty exciting stuff and I'm gonna talk about more about this I'll be able to reveal more as well at the RISC 5 summit where I'll be hosting a keynote discussion panel with Google's Zephyr project on quick logic entitled building an open edge machine learning ecosystem for Zephyr, Zephyr, TensorFlow Lite, micro and re-note I know it's a long title but you know that's all I had I think so if you get started just go ahead download re-note we have packages for various operating systems including various Linux distros macOS and Windows so I encourage you to just kind of keep going thank you, thank you very much thanks Michael thanks for all our speakers we'll start our Q&A session now all the speakers if you please unmute yourself and turn on your camera we'd love to get live discussions going thanks for typing in questions throughout the session so we'll some of them already got answered I'll start with that in the meantime please fire away with your questions and we'd love to get some live discussions going here so the first one I have Michael is for you about re-note do you plan to integrate DTS into re-note meaning the board's DTS would be enough to describe the board you would like to simulate that's a question we get a lot right so effectively go ahead Michael DTS is very similar to the format that we have it's kind of typical DTS descriptions lack a bunch of detail that we might need but on the other hand they do contain quite a lot of information so there's no fixed plan but like that has been a constant discussion around it so many people ask about it we'll definitely have to revisit that and do some thinking a similar question has been raised with SVD files which are like description files for boards that some vendors provide for CPUs mostly and SOCs and with that we actually do support SVD for example where you can load an SVD file and get register values and so on but yeah we'll be working more also in the relationship with Google we're thinking how to make more like industry standard ways to describe hardware to enable simulation more easily so no fixed plan but like yes constantly on our mind thanks Michael Brett we can stop presenting so all the speakers will be on live here so we can just thanks for your help thanks so the next one I have from Barak do you have plans to extend support for FPGA integrated SOC as Altera Aria or Xilinx MPSOC I don't know where we're going with plans I do believe there's sorry if I may there is Cortex Air 5 support Ultra Scale Plus so if you're not running I mean if you wanted to run it on the big course the Cortex A53 then no you can't do it yet although I don't see why you shouldn't be able to at some point I'm sure that will happen but it's not there yet but with the Cortex Air 5 course which are included in the Ultra Scale Plus indeed Zephyr already works there and Michael has done some work but no I haven't seen anything on the Intel Aria stuff Marine do you have anything to add to that? no great we have another question from Henry are there any examples using TensorFlow Lite with Zephyr without using Renode so I guess I'll answer that well actually if you think about it Michael do you have any it seems I have a slight delay that's why I keep starting to speak before you finish so effectively absolutely yes in the sense that Renode is just a target that you run against instead of a board so in fact if you think about it any example that we make for Renode you should be able to take and run it on the board as well so even if you go to that repository yes of course we focus on the Renode way of running things because it's just easier for anyone to run it but if you grab a physical board there is also instructions how to upload the same exact binary that we run in simulation on to the board and that doesn't go through Renode in any way because Renode is just like simulating your hardware but it's not in any way influencing the way you do your software the software you develop exactly the same way you'd normally develop it for your thing so the software development part is completely just Zephyr plus Tf Lite and then you get a binary and then you can choose whether you run this binary on Renode for whether you run this binary on hardware thanks Michael well keep the questions coming next one is from Andreas are there any plans to add api for crypto accelerators for asymmetric crypto Rud, I'll have you take this one you're on me if you're talking thanks yep good points because the current abstractions that we have basically started from the requirements for BLE and we don't have Zephyr specific api or abstraction for asymmetric crypto current what we use for asymmetric is the TLS solution so asymmetric is available and we might you know pick another api standardize on that there's a few candidates we could do some because CS11 we could do the embed crypto but no firm decision on that yet so for now it's the embed TLS api thank you the next one I have is on Zephyr how tiny can Zephyr be code plus data I want to compare to with this thread export to an M class core with just the bare minimum to support few threads and synchronization elements I'll take that one can you take this one we get this question a lot it can be a challenge to answer because the minimal footprint or minimal set of features kind of depends on who's asking the question but that being said I would encourage you to take a look there's an entry sample application that we use to try to build from a Zephyr perspective the smallest subset of features possible and that will get you down into the single digits of flash and RAM and that's going to be architectural dependent but that ballpark unfortunately I don't have numbers with Redex so I can't give you a comparison there but in general the footprints for comparable features do tend to be somewhat comparable so you're not going to see huge differences great thanks Marine well thanks for the ongoing questions so keep them coming if there are follow-up questions we'd love to have a discussion going as well speaker's point of view if there are anything that you want to highlight while the questions coming in here floor is yours here we are as said safety is also related to handling random fault from the hardware there is or there will be some features to help on that point Amber do you want to take this one yeah of course yeah good question there are no plans for that yet and that's not to say that once we get further into doing our safety analysis that we might add some features to mitigate hardware fault but that's unlikely to be in our initial certification that would likely come in future future investigations I could add there that there was a pull request I think that relates a little bit to that for non-maskable interrupts so there is a framework coming for that I think typically this kind of memory errors that are generated they would come through as non-maskable interrupts so 29585 is the pull request that was submitted a couple of days ago oh thank you Johan yeah so I guess the question is whether that falls into the initial certification scope it's the code base that we intended on already so yeah I'll have to look into that thanks Johan thanks Amber I have another question from Hernan are there some regular ongoing meetings when team meets so we can participate I know we have various meetings do we want to start from TSC or other aspects how these meetings are accessible to the contributors marine yeah I'll take that there are plenty of meetings depending on your area of interest to start off with there is a wiki page that we post all of our meetings including links and dial-in numbers and things like that and I'll pull that up in a moment and post it here but a couple of things to highlight so the technical steering committee meets weekly on Wednesdays there is a weekly API meeting where we discuss proposals for changing adding new APIs things like that there is a developer review meeting that's another good one for new people that are interested in the community this is a venue for people to kind of get on the phone and actually discuss open issues that sometimes you know it's difficult to go back and forth on github too many times so that's kind of the purpose of that review meeting but there are a number of other meetings around security safety you know it all just depends on your area of interest so I'll pull up that link in a moment here and get you on your way and there is also wealth of documentation and getting started information available on the Zephyr site so we welcome you to check those out what's the best way to find maintainer of a subsystem just write a ticket on the github or use another channel how do we want to how do you approach this so we have a maintainer file it's called maintainers.yaml at the top level of the tree and that will point you to who's responsible for each subsystem thanks marine how do you rate the current C++ STL support for Zephyr OS related abstractions like SCD thread, SCD lock any of my panelists taking this one there have been a number of members of the community that are interested in C++ support I can't say offhand what the state of STL and those specific examples are but I'd encourage you to reach out to on the Slack channel to ask questions thanks marine my daughter started playing piano so you might hear that a little bit Zephyr is licensed under Apache 2.0 and the Linux GPL v2 only which are incompatible according to the FSF have you discussed addressing this example by adding an exception for linking with GPL v2 code I'm not sure if any of us have this or we can take this question and follow up thanks for the question follow up on this one I'm taking a note here I would love to get a discussion going so please keep your questions coming if you have follow up questions for any of our panelists still regarding safety is there some plan to help qualifications of the tool chain tool chain bug analysis and usage constraints Amber I'll have you take this one yeah we do have plans to qualify any tools that are classified as TI 2 or 3 and definitely the tool chain are going to be one of those we are in the initial stages of determining all the tools that are in our scope and doing the classification so details about how we will do the fall for the tool chain are still to be determined comparing to IAR thanks for the question Florent thanks Amber keep going all right Guy is there a particular IDE you would recommend for Zephyr application development and debugging comparing to IAR Marine, Michael if any of you guys can chime in there are a couple of options on that front if you are using excuse me if you are interested in eclipse type of environment you have two options there there is an exporter so you can export your C make into an eclipse project then you can then import on the eclipse side of things so that will allow you to use Zephyr in vanilla eclipse or a vendor eclipse like MCXPresso so that's one side now I'm aware that there are some people that are also using it in visual studio code I haven't tried that myself but I've heard that there has been some good success on that Nordic did a good tutorial recently on how to use Zephyr in visual studio code there is also support for Sega embedded studio specifically on Nordic platforms oh and I forgot going back to the eclipse just for a moment there is also an eclipse plugin that Intel has shared with the community as well so that's another eclipse based option that you can use Yolman are there any that I've forgotten or Michael in the VS code world there is platform IO it's essentially a plugin to a bunch of so platform IO is kind of both a manager of firmware so you can run Zephyr and other things from within platform IO but in another sense it's an IDE that enables you to debug stuff both on boards but actually also in Reno we have an integration so you can kind of run simulation through platform IO it's a pretty neat little tool thanks Marine, thanks Johan any other tools from where that you guys found helpful that you want to call it out here for the community alright I have a question from Stefan are there awareness tools getting insights on contacts which is IRQ etc awareness tools in the ecosystem like OS aware tools I guess that's really in terms of like tracing and debugging and so on I'm not aware of any built in ones but yeah there is tracing support tracing subsystem it generates common trace formats so there are various tools that can be used with that multi experts in this area but for sure there's support and the standard tool change so GDB also has spread awareness I've also heard of people using a Sega embedded studio for that as well yeah let me add to that as well so OpenOCD and PyOCD both are GDB servers both have support for Zeper thread awareness and so you can plug that into if you're using a GDB client it can parse through the different threads there's another one I was going to mention that I've forgotten now that I started talking I've lost it well if it comes back to you we're here with these are all great questions Florence, Stefan, Andreas thank you for actively participating here and please keep the questions coming but we're always available on Slack Twitter, LinkedIn easy to reach out and as Marine mentioned there are meetings also you can participate in and there's also a question from Efrain are there any plans to use more inclusive language similar to what GitHub is doing so I know we have a lot of effort going on on this space Marine if you want to chime in I actually was going to ask Amber since she's leading the effort on that okay sure, yeah thanks Marine yeah thank you for that question there is absolutely a bunch of activity happening right now on this project we've had a few discussions in the TSC and kind of one-off meetings of the TSC to figure out how our overall plan for how we will transition to more inclusive language and this takes many forms right from changing from Zephyr Master Git to something more inclusive Zephyr Mane for example also changing from the use of Blacklist-Whitelist an alternative, Blacklist-Allowlist changing things like the name of sanity check so we find this throughout Zephyr both in the branch and among the subsystems and so kind of high level our timeline for this is to for Zephyr Mane branch to make the transition in parallel with GitHub because once they make the transition it will give us a lot of it'll make our transition easier and that's looking like it's around the end of the year maybe beginning of next year so that should happen either in Zephyr 2.5 or 2.6 release and then for our subsystems you know some of them like I2C, SPI, Bluetooth they are tied to a corresponding spec or standard and we decided that we will not change until the corresponding spec or standard to avoid a number of complications that may arise and so that's going to trickle in slower over the end of 2020 and 2021 but we plan to publish kind of an overall summary page of our plans and the timeline for all of those updates so that's coming soon on Zephyr documentation I don't think so Sanity check did you mention that? Yeah Thanks Amber, thanks for leading that effort and I have a question from Patrick how will the safety Zephyr be made available and is there a specific cadence plan for this safety Zephyr configuration similar to the LTS cadence? Great question Patrick Yeah, so I mean the plan is there's the different aspects of safety there's going to be the auditable code base which we're calling it so the code base that has met all of the safety requirements needed but then there's also all of the corresponding artifacts and documentation and so the code base will be publicly available but for the artifacts that are submitted for certification will be primarily reserved for platinum members of the Zephyr project and then the question disappeared but I think the second part about cadence that's a little TBD so our initial goal like I said is to align with LTS2 our LTS releases are on a two-year cadence and you know likely if there's a research it might make sense to align with those right release would be the best for safety having that longer term support but we haven't really finalized plans past this first release for LTS2 Thanks Amber, I think we have time for one or a couple more questions well going ones maybe someone is typing but I will wrap it up here thanks for your active participation we appreciate all the questions and enthusiasm to the project and as we repeatedly mentioned throughout the talk Zephyr is open source so we welcome you to join us and join the community to contribute and I think I have one question so let's oh a couple more coming in here is there as we recommended first choice CAN open stack for Zephyr I'll take that there's an integration of the can open node stack that's been integrated as a a west module I think I actually saw the Bricks here who's on the call he did that work so yeah that's already built in and integrated with Zephyr today I think it's been in for two or so releases already so it's already there Thanks we'll make this the last question there are plans to plans to add MMU support to Zephyr at least for several architectures is it also an attempt to compete with embedded Linux are there plans to propose Zephyr usage for something high performance so we already have some level of MMU support this is by the way an area that I'm not that experienced in but there is limited support for that already in Zephyr as far as competing with Linux I don't think that's the intention I know there are some use cases where people might want to get real-time capabilities on one core and rather than running the real-time budget for Linux to run Zephyr there or something like that that could be a use case where you want to run it on a very high performance course but that's I think of as far as this question is concerned please if somebody else has anything else to add let me continue on that so the MMU support basically started as an implementation of the memory domains and the memory protections that we have with processors that have memory protection and PU so the current supports basically gives similar protections so he tried execute protections for certain memory regions it doesn't provide virtual memory or things like demand paging etc there are some activities on going on to use MMU hardware for more purposes so some limited virtual memory maybe but definitely it's not the goal to start competing with Linux these solutions serve different purposes using high performance I guess Zephyr can be used for for high performance or high compute performance or dedicated compute task at hand that can be very high performance but it doesn't mean you need a general purpose operating system as you all mentioned if you need real time and just a more dedicated solution predictable with the security but also the safety certifications if you need a safe solution then Zephyr would be your choice thank you both I have one more question here from Guy is there a plan to for creating a medium independent firmware upgrade infrastructure whether it's over SerialSocket or USB Marine Yohane if you have any input for this one so we have support for this simple management protocol provided by the MCM manager in Zephyr and that one normally supports a couple of transports so there is a page in the Zephyr documentation that outlines what you can do with that and firmware upgrade is definitely one of the use cases for it there was actually a question earlier similar to device management and I provided the link there somebody might be able to find it there in the answered questions MCM Booth also supports say the motion of firmware updates so it manages two flash blocks so you always have a fallback option but we don't have things like remote management or infrastructure for updating many devices there's several ways of updating in Zephyr firmware great, thanks everyone well that is a wrap speakers thank you for your time and walking us through these developments on the project and for all of you thank you for being part of the community and to keep developing the great products using Zephyr so with that we'll see you in the next Zephyr Summit thanks for that thank you everyone thank you, bye