 delay some technical problems. The talk today is about Frostat, which is an acronym for free operating system for tiny embedded devices. We are making it fully GPL, so the whole kernel is fully open source licensed. Our group is called Insane Adding Machines, and we're trying to do non-profit development and research into Internet of Things, especially free software. The management platform we chose to use is GitHub, because it's quite obvious. So the target is the main target at the moment is the Cortex-M family. They're not too big yet, so it's still a challenge. We go from Cortex-M0 to Cortex-M7 support at the moment. So the Cortex-M family is a 32-bit architecture. It's low power devices with physical addressing, so there's no memory management unit. They have integrated network and a whole bunch of buses. The M4M7 also do digital signal processing, and they also have accelerated floating point. So the thing is that we want a real-time OS, and if you look at the embedded Linux, it's not really feasible because it's grown very big. Even the MMU variant, like Micro-C Linux, it's too big for the resources these boards have. So our goals are primarily to have a POSIX API to allow easy porting from Linux user lands to Frosted. It's very easy to port applications because at the moment, if you port something and there's something missing, it's just a library call or a sys call that needs to get added in Frosted and then things work. We have a hard kernel user space separation approach. We can do physical memory segmentation using memory protection unit on this family of microcontrollers, and that allows for the kernel to have its own memory segment in every process as well, and they cannot access each other because, yeah, then seq fault. We also want to be real-time. So at the moment, we already have real-time capabilities. The ultra-low power is something we're still working on. TCP connectivity is already there. We have both normal Ethernet and USB Ethernet using PyCode TCP as TCP-IP stack in kernel. So, yeah, all the kernel code is GPL, but you can run any license in user land as you please. So at the moment, we're almost fully profile 54 POSIX compliant. It's real-time, multi-proc, multi-thread, but the threading still needs a little bit of polishing. So the components, we have the application layer is in user land. Then we have a modified new Lipsy library that we compile into our own cross compiler tool chain. Then in the core, you have the core itself, the scheduler, networking, virtual file system, memory manager. Then under that, you have the device drivers. And for the operating system to know which pins do what, you also need some board-specific code to define which pins are where and stuff like that. So the kernel code area size is fixed, and base applications and shell scripts are compiled into binary flat, and then stored into a KSIP-FS that's execution in place. So for the application code in user land, the goal is that it's basically no work to port NICs executables to Frosted. The reality is that some stuff is still missing in Frosted, and we don't have fork, but we only have V fork. So the applications are in binary flat format. They're compiled with our own tool chain and with some flags here. If you're interested, we also have a Frosted user land repository with some base user land utilities. The context separation is thus that the processes are really executed in their own context. They cannot access supervisor code. They cannot access kernel memory. They cannot access each other's stack, and they have separate stack pointers, and through the MPU we can enforce this. This is an overview of the system interrupts. So the power on state, reset handler, accessing memory you're not supposed to, mem fault handler, and then the process gets killed, of course. System calls come into the supervisor call handler, which then executes the sys call, and then we have GFS with sys ticks, basically. The schedule is a double list. We have processes either marked as idling or running. It's around robin policy, so every process usually gets scheduled the same amount of time, and once everybody got this chance to do something, just goes back. But we also have a real time priority option. So in the real time, if there's an interrupt coming in for a process marked as real time, immediately everything is preempted and this is scheduled for execution. And the latency for the real time processes, it's predictable, so that's really good. This is just a nice graphic of it. So the repositories. We have the main repository of the kernel, which is the whole kernel. We have a repository for our own tool chain, which we build with cross tool and G, and we also have a repository for that, but we also make periodic releases of the tool chain. We have a special headers repository because we need to include some common headers, both in user land, in kernel, and in the tool chain. Then we also have the frosted user land repository, and as the hardware abstraction, we use Unicore MX, which is our own fork of LipOpen CM3. This is a nice graph of the dependencies and interconnections of the different repositories. The tool chain, it takes a while to build and that's why we make releases periodically. Why our own tool chain? Because we want to be able to compile our applications and be able to automatically resolve, include paths and stuff like that, and also to produce flat binaries. The nice side effect is that the tool chain can both compile the kernel and the user land application, so a number of DevConfig for a number of popular boards like the SDM32F746 disco here. So we also borrowed the KConfig system from the Linux kernel because it's quite handy and applicable in this case. The user land configuration is also done with KConfig. The apps that are selected are archived in XipFS and that's getting mounted to slash bin on startup. When the system starts, slash bin, slash init is executed, and if slash bin, slash init is present, it's going to be parsed using the default shell, which is called fresh for, shit. Where does the e come from? And fresh is cool. And once the options are selected, just make to build and then you end up with the image.bin file that you can flash. There's a couple of binaries produced actually, so there's an elf file of the kernel, there's an image file of the kernel, and there's an apps.image. And then at the end, the kernel.image and the app.image gets concatenated together to image.bin, and that's the one you flash. We also have a query report that has a modified M3 target to have a bit more resources, so you can also run Frosted Inquem with networking and stuff. All works really fine. We also have CI using Jenkins, so every commit Jenkins rebuilds stuff and harasses us on IRC if it fails. The flashing to the target, you can do either over the ST link, because those boards have their own ISP on board, or you can copy it over USB if it has an embed bootloader, or if it supports the FU, you can also do that. Okay, that was it. Now we'll see if something wants to work. If you want to show the shell, you should probably do it here. Ah, yeah. Yeah, but yes, yes, first flash. Yeah, in the meanwhile, if you have questions, most of the development team is in this room, so we can be able to answer those. Can you get us a question there? I've got a question. What is the typical size for installing Frosted On The Flash? The question was, what is the typical size for installing Frosted On The Flash? Normally, it depends, of course, on how much features you enable in the kernel. We're able to build the kernel as small as 25, 30 kilobytes, but it needs to be a power to the flash part where it starts with the kernel, so I would say that the minimum of 32 kilobytes of kernel size is needed, and then, of course, on top of that, there will be a partition on the flash that contains all the applications, and that would be sized, of course, based on the size of your applications. I would say that a board with 64 to 128 kilobytes is able to run a minimal Frosted. Yes, question there. Is it really ready for solution? Do you have some real example that company has used it or something? Is Frosted really ready for production, and do we have real example of company using that? The answer is no, but we're having a lot of fun with it, and it's getting better and more stable by the minute, and so we're looking for someone that's daring to use it in a production thing, but it's for sure ready to show this. We ported the historical IDSofters Doom game that's now running on the frame buffer that someone wrote the driver for, and yeah, so it's quite stable as you can see, and the nice part about it is it's mostly POSIX, so it's basically a really tiny, tiny UNIX where you can port your UNIX application, Linux application with almost no effort, yes. I don't know what this requires beyond POSIX, but can you run GDB under it? Yes. The question is, can we run GDB to debug, I think, both the kernel and the applications? Yes, we can run GDB directly to the target to debug the kernel, and we can run a GDB server from the user space to debug single applications, so you can actually connect a GDB to a different port if you want to debug your own application. So our toolchain contains a GDB binary as well. Maybe do we have time for another question? Yeah. Yeah? Yeah. I made a Docker image if you want to try that on your laptop. Okay, that was more an observation, but Zobab made a Docker chain in case someone wants to try that on their own laptop, so you don't need to download every single component or clone recursively the GitHub, but you can download the Docker image. One more question? One more question, maybe, or there? Okay, so the question was, what are the actual limitations, the hardware limitations we met on the target, on the basic target that we chosen is the Cortex-M. Yeah, maybe one bigger input thing, the first thing that comes to my mind is that the Cortex-M has a limit of eight different memory areas for the memory protection unit, so we're not able to protect different areas of the heap at this point, so the heap is still shared, but the stacks of the single processes are isolated. With more flexibility in this area, we would be able to have a better memory protection, but ARM has already worked on the ARMv8 family and they already have a datasheet that explains that the number of MPU slots has increased, so we're looking forward to port Frosted as soon as possible to the Cortex-M23, what is it called, the new one? The V8 architecture. Yeah, the V8 architecture that's coming up this year. Okay, you want to show another little demo? Maybe we're out of time. Yes, question? It's a more practical one. Why move to Cortex-M, you know, processor architecture if you want to cloud the full-posting system and not either keeping a Cortex-A architecture? Yeah. Or if you want the real-time thing. Exactly. So that's a very interesting question and I'm really glad that someone asked this. So why didn't you guys use a Cortex-A that already has MMU and a lot of resources to run a Unix or you just stick to the Cortex-M which is limited in resources and just have a pure real-time operating system? The answer is we lack something in the middle. We lack real-time Unix on a small, cheap, embedded CPU that doesn't have to have an MMU to run smoothly and the approaches on the embedded OS are nowadays are a bit too primitive. If you can tell me this, like Friart is for instance, it's not much of an OS. It's just a bunch of a schedule with a bunch of support for locking mechanism and a very basic heap but for the rest it still has a number of limitations especially on the readability of your API so you can't have the flexibility that you have if you're coming from the Linux ward. On the other hand, you've seen probably a couple slides with the Linux kernel ramping up in size because nobody in the Linux foundation right now cares about the embedded developers but that's a major problem. I'm not saying that we, a small group of independent developers are providing a solution to this but I hope that this at least gives some kind of point to reflect upon that we really need something Unix-like to look at except when we crash and pinging it. That's your manager of some other operating system then. Can you explain what you do? One minute. Basically what I did right now was boot up the board with the USB Ethernet configured and connected the USB cable to the laptop, assigned an IP address to the interface that we got and pinged the board over USB Ethernet. As you can see, the board is replying so we have connectivity. Yay! Thank you.