 Thank you for joining this session. My name is Masahih Sikawa from Sony. So I'm so happy to be here today because this is the first time for me to talk about NATX at the embedded Linux conference in Europe. So today I'm going to talk about NATX for embedded Linux developers. So here is the agenda. Firstly, I introduced about our audio products based on NATX. After that, I talked about sound free speech study that's like S&P, so symmetric multi-processing, and also talked about porting the ABS, Alexa Video Service SD device SDK. Then I will introduce Sony's process board and finally I'll talk about the NATX workshop so held in Netherlands in July. And about me, so my background includes various fields such as 3D graphics and networking and embedded systems. And in 2006, I proposed to use Linux for a portable media player. And we started to develop the first Linux-based portable media player which supports video playback. Then in 2008, I proposed to use Android for a new generation of media player. And we started to develop an Android-based media player which has dual-quotix ANI. And since 2013, I proposed to use a NATX for smaller devices such as a headphone with a storage. So before starting NATX, I have little experience with RTOS. So actually, I was a RTOS beginner at that time. So this slide shows a brief introduction to NATX. And NATX was released in 2007 by Gravelin.net. It's mostly project spawn-band, real-time OS. So it's suitable for robotics. And actually, in drone and project, and loss-to-project, which means as a robot operating system, they are using NATX for embedded real-time OS. And NATX supports many CPU architectures from 8-bit to 32-bit system. And Footpoint and Lantan memory are very small, so it's suitable for resource-constrained devices. And as for driver source code, NATX does not use a vendor header, so hardware abstraction layer. So the code is very straightforward and consistent. And many key features are implemented, such as a flat-file system and smart FS, which is a flash-file system with wireless support and networking and many USB-class driver for both device and host class supported. And also, many example applications are included in such as a NATX shell, which is very useful for debugging and web service as well. And so you can easily try these application ways on NATX. And from here, let me talk about the Sony audio products based on NATX and PHB2 studies. As I mentioned in 2013, I proposed to use NATX for some audio products. At that time, we use 7. It's not code M7, of course, so base processor to port NATX, because our audio products use this processor. However, this processor's S-ROM size was so small, so we use NATX to QMU as well to port a proprietary port to stack. And in 2014, we ported NATX to a new processor, which is called LCA23450, and continued product development. And so finally, in September 2015, we released the first NATX-based audio product. And these are our audio products. And in 2015, we released two voice orders and one music player. And after that, we released many audio products, including wires, headphones, voice support, this HTTP sync, and HSP, and HSP. And this year, we also released a voice recorder, but not listed in this slide. And these are several reasons why we choose NATX for our audio products. The most important point were projects and review support. As I mentioned, we have much experience with Linux and Android before. So I thought we should apply our software development approaches, even if we use NATX for operating system. And with this, we were able to reduce existing software and also reduce running costs. And also, our support was very important for us, because some audio products do not have SPF for us to reduce cost. And so we had to divide one big application to small applications. And other items such as driver framework, and framework support, and Linux-like configuration support are very useful as well. And this slide shows processor features, which we are using for our audio products. This processor has dual-quortex M3 running at 160 megahertz and has a 1.6-megabyte internal SM. Kind of products use only single-core hardware. I've been studying if we can use the secondary core in SMP mode to increase more performance. The reason why I'm being studying SMP with this processor is that we want to learn existing application in SMP mode to scale performance. However, this processor does not have a CPU cache, so we need to confirm performance effects on memory contention. I think it's a very challenging theme, because Natex is not just a scheduler, but has many features such as networking and also includes application as well. This slide introduces my approaches to support SMP on this processor. So firstly, I ported existing driver to latest Natex. Then I implemented SMB-related code. Usually, ARM supports load-exclusive and destroy operation to implement spin lock. However, this processor does not support these operations, so we had to implement it with hardware mutex inside of the processor. So the next topic is networking. So motivation of adding to networking was to confirm Natex network stack feasibility. Actually, this on semiconductor evaluation board does not have Ethernet but has a USB. So I decided to use USB remote and disk driver with this evaluation board to test audio streaming in SMP mode. So as you can see at this slide, Natex supports many networking features, such as Ethernet, Wi-Fi, USB remote and disk, and IBV4 and V6. Of course, you can use a VSD socket API as well as select and port interface to wait for events from the socket. So it's very easy to port socket-based application to Natex. So then I started to test USB remote and disk based on semiconductor support. So there are several issues at that time. For example, data cooperation in the USB remote and disk driver, and no TCP window control, and no HTTP streaming support in NX player, which is a media player on Natex. So I had to fix these specs and added features. And now it works well in SMP mode, and which I will show you a demo video later. So another networking study in Brutus personal area networking. As I mentioned before, in our older products, we've been using proprietary Brutus stack. But in this study, I chose BT stack by Brutus Kitchen, because in this study, I chose BT stack because it's open source and free for normal commercial use. To learn about this panel on Natex, I added a TAP mode to Natex turn driver, so which is a similar way to learn about this networking on Natex. This shows an actual software stack to learn a BT stack on Natex. This orange box shows BT stack components by Brutus Kitchen, and blue box shows Natex sort of components. And Natex network stack can communicate with BT stack via a turn driver. And actual interface name is BNAPZero. This means that Brutus network encapsulation protocol 0. So the next topic is ABS Devices SDK. So the motivation of this study is to confirm OSS portability with large software systems, because this SDK consists of many open source software components, such as embed to TRS, NG, HTTP2, and RIP card, and so on. So approaches for porting this SDK is firstly built and run SDK on Linux and understand how each component works on Linux. Then port each component to Linux and also implement some missing components, such as a media player, but with a minimal efforts. And finally, I reduce runtime memory on Natex. So this shows the audio signal for inside the SDK. You can see on the left-hand side an audio input format is PCM 16 kHz, 16 bit, and more. And with this SDK, you can see your own keyword detection. However, in this study, I decided not to use keyword detection, but to use a push-to-talk. So communication between the SDK and Alexa service is transported with HTTP2 over TRS. And voice data from Alexa is encoded in MPEG audio format. This is 24 kHz, so mono and 48 kbps. And to decode MPEG audio, I decided to use hardware decoder inside the processor. And as I mentioned before, ABS-device SDK consists of several open source components, such as MPEG TRS and NG HTTP2, and so on. So here, I had to implement our own media player and microapper, because G-streamer for Linux is too big to port it. However, total core size of this system was about 3.6 megabytes, including Linux kernel, not X kernel. So to run the SDK, I had to use SPI Flash in XIP mode. So this is a network topology to test ABS-device SDK. To connect the board to a network, we need a remote-endless forced PC. And also to connect the internet, I use my iPhone. And in the demo video, I'll show you where ABS-device SDK works, so with NATX, so right here. So the next topic is spread sense. So in 2018, Sony released a new low-poor processor called spread sense for IoT products. And this processor has six Quotex M4F application domain and also power domain control and the sensor control unit with a large firewall and GNS position features. And these hardware features are implemented in a very small package. And we, Sony, also released a spread sense SDK as well. So it is available on GitHub now. And this SDK includes many drivers for spread sense as well as middleware and sample applications. However, the kernel version is a bit old. So since June of this year, we've been contributing a spread sense-related driver code to the NATX upstream. And this slide shows the latest streaming status. And as you can see, this slide, most of the driver code has already been merged to the upstream. So this is very important for both of NATX, community, and Sony. And for NATX community, they can try the latest NATX code with spread sense evaluation board. And for Sony, we can easily merge the latest NATX release to our SDK in the near future to reduce maintenance cost. The next topic is also Wi-Fi. So in this study, I implemented Wi-Fi driver for GS2200M. So we support 11 BGN at 2.4 GHz. So this driver supports both station mode and access point mode. So to implement that driver, the NATX user SOC feature was used. So here also, what is a user SOC? So the answer is that it's a user-spaced networking stack API, so defined in NATX. And user-space demo and the hard-provide NATX networking. And these are all similar integration of hardware-provided TCP IP stack to NATX. So this is an actual use case for web server example. In this study, we can reuse existing applications such as TerranetD and the web server. And spread sense can be accessed from Firefox for on-opened and to access files on microSD card. So for your reference, I've just put a code size of this use case compared to a remote end disk configuration, so which uses a normal TCP IP stack on NATX. And code size was almost 10% code size was reduced with using a user SOC-based driver. So the last topic is a NATX workshop. So on July 16 and 17 of this year, the first international workshop of NATX was held in the Netherlands. In this workshop, over 40 people joined. And we, Sony, also attended this workshop and talked our activities. And at the workshop, so many applications, so such as drone and drone and drones and robotics and sensors and Q-satellites were introduced. And of course, we also introduced all the products and the spread sense at the workshop. And at the workshop, so many developers talked about this, why they chose NATX for their products, for their applications. And of course, real time is very important keyword because some drone and robotics are very important to use real-timeness. And however, as you can see, this right, so many developers including us use Linux to develop and to test software. And after that, so they deploy and develop the software on NATX. So the portability and the scalability are very important for software development. And that's why they chose NATX for their applications. So finally, I'd like to show you our demo videos. So the order is changed from the order which I talked, this talk, because it's a complex order. So first one is ABS devices, OK? So first is start ABS test. So you can see many logs. So HTTP stream is running. And in background, I run a media player as well. And can you see? Right now in East Queen Anne, it's 52 degrees Fahrenheit with clear skies and sun. Tonight's forecast has clear skies with a low of 35 degrees. So and now check task rate and the pre-memory. So so many tasks is actually running. And so it consumes almost one megabyte of memories. And next is a suppressence plus Wi-Fi. And its setup is very long. So I change playback speed. And from here, it's normal speed. So turn it to suppressence. You can see your name is suppressence. And log in again. And this PS. And run our web server, access web server on suppressence via Firefox. And you can see a jpeg file. This files stores on a micro-sd card on suppressence. And this RMP3 file is also on MPC's R's micro-sd card on suppressence. And Firefox is accessing. So downloading this MPC file and playback. And next is the audio stream in SMP. This is used using HTTP audio streaming in remote areas. And CPU coax changes automatically. So it depends on our CPU load. And run our command via telnet. And CPU coax goes a bit higher for while executing commands. And stop run commands and clock goes there. And then clock goes high and while executing commands. And clock goes down after stopping our commands. And then run a busy route. And just busy route only CPU 0. So you can see CPU 0's idle ratio is down to 0. Then run busy route on CPU 1. In this case, you can see idle 1. So CPU idle for CPU 1 is going to 0. And run busy route. Or in this case, busy route runs on CPU 0 or 1. So both idle ratio is not 0. And finally, run two busy routes. And in this case, CPU scores are high. But both CPU idle is going to 0. So that's all of this demonstration video. So that's all from my talk today. So is there any questions so far? It's so very quick to talk this session. And maybe I'll cover so many topics in this session. So is there any questions? If you have, you can pass our mic. No questions? What kind of tool chain do you use? Do you have to make your own cost compilation tool chain to use the netx lip say and so on? Or is it a self-contained project? And you can use the standard GCC or? So you are talking about the tool chain or something? Sorry, I forgot to mention about the tool chain. We are using a normal GCC tool chain. And currently, in the product, I think GCC version 5.3 or 4 was used. But currently, we are using GCC 7 or GCC 8 to test these netx on semi-context as well and as presence board as well. So we are using a GCC-based compiler. Is that OK? OK. Thank you. Is there any other questions? So thank you for joining this session.