 All right, so today I'm here to present Orbut. I'm Raino Larry. Orbut's a project worked on by quite a few people. Ron is a big contributor. There's some contributors in the crowd today. I see Christian Svensens here. So who here is familiar with Quabut? A lot of people. So Orbut is basically a fork of Quabut without C code. It's all written in Rust. That's the main thing behind it. So in this talk, I'll talk about what Orbut is. Some of the familiar challenges we ran into, some of the challenges we ran into with Rust, what targets it supports. So there's a few RISC-5 targets it supports, and some design decisions that has gone on in making it. So what is Orbut? So I'm missing someone's favorite project here. This is a list of some other open source firmware projects, like UBoot, Linux Boot, Quaboot, Nerf. The big thing behind all these projects, all the existing projects today, is all written basically in C. Most of these use C code somewhere in the project. And that's kind of a, across all firmware projects, that's kind of a big common pattern you'd see. And C is kind of an old language, probably like 40 or 50 years old. And what we really wanted to do is use a modern, more safe sort of language. There's also another, there's other things we're trying to fix in Orbut. So for example, we want to jump to the kernels quickly as possible. We want to push as much work into the kernels possible. We kind of want to use the Linux Boot model. We don't want to implement lots of device drivers in the firmware. Linux has great drivers already, very secure drivers, very fast. We want a stricter policy on what is accepted as open source code. Remains, Orbut supports a few targets, including Visk 5, also supports X86 and ARM, but we really want to limit it to platforms which are fully open source. We want to, yeah, another big, okay, so I'll go over what the very simple, simplistic view of what firmware should be doing. So when you power on the system, all it has to do is get the system ready to run your software. We kind of want to cut out from the firmware everything else, like we don't want a whole network stack, we don't want a whole USB stack. We want it ready immediately to run your software. One of the big goals behind that is a one-second boot. We want to build a boot, a platform like a BMC or a laptop in one second. And we'll believe if the advances in REST and other things we could use, we could achieve this goal, possibly using code teams or a parallelism. REST provides lots of safety in that regard which isn't seen in many other pieces of firmware. So I'll go over the boot flow of ORBOOT. This is very similar to how core boot works, but there's a few modifications. So at the beginning we have the boot blob. This is where the first instruction resides. It excludes directly out of flash, initializes the CPU and the basic hardware and it prints a single debug message, welcome to ORBOOT. Then it sets up the static RAM, like the caches RAM. And then it jumps to the RAM stage. The beginning of the RAM stage is still executed directly from flash and has very little memory to work with, probably about 30 kilobytes on some embedded platforms. And the only purpose of this stage is to initialize the RAM. Once the RAM is initialized, it's ready to jump to an operating system. So the next stage is a payloader stage. So this doesn't delete with network stacks and disk drivers, it jumps directly to the operating system. And the operating system might be one such a Linux boot which does have the network stack, does have the disk drivers and that jumps to whatever your software would be. Skip this piece of time. So how many of you are familiar with REST? So quite a few people. So for ORBOOT we came up with this driver model. So each driver has four basic functions, initialization, shutdown, as well as a read and write. So P-read is positional read, so read has specific position. So let's see implement stuff like block devices. So here's an example of how you would use the P-read function. Just say you had a block device which is 100 bytes. You have your 32 byte buffer. You keep calling the P-read function. On this buffer, it reads 32 bytes every time and eventually it gets to the end and you pass in the cursor every time you read from it. The reason we do this instead of a read function is because P-read is immutable. You pass in the cursor every time. Which from a REST perspective, it's a lot nicer to work with because in REST you could have multiple immutable references to the same object. So these are a few examples of the drivers we've implemented in ORBOOT. So we have a memory driver which reads directly from memory. We have some serial drivers. We have a spy driver. We also have what we call virtual drivers. So these kind of work on, they don't work with physical hardware but they work with, it's a nice abstraction. So for example, just say you have a console in your firmware where you write output two and you want that output vision to multiple devices. For example, you have multiple UARTs. You can use the console driver and you give it a list of drivers and it kind of replicates the output to each one. So this is kind of a nice interface. In REST makes it safe to implement. If you compare this to C where they don't really have language support for interfaces, it's a very nice breath of fresh air. And in REST you also get printf for free. So printf is part of the core language in REST. They have a printf implementation which you could rate the output to whatever you are to a device you want. So for Orboot we didn't use CBFS. We didn't use the core boot file system. Instead we came up with a new system called the DTFS. This is basically a file system implemented using the device tree. The main reason behind this is we just have one, we already had to rate a processor for device tree. So we might as well just reuse it for the file system as well in the firmware. You can see an example of one that we put in a 60 megabyte part. So we have the boot blub at the beginning and then we have different payloads, et cetera. And then the other nice thing about a device tree is the Linux, you just pass in the device tree Linux and it's exposed in the Sys file system, Sys slash device tree. And you can see all the payloads and items under that. And here's an example for the Sci-Fi board. This is the DTFS that we use for that. And you can see this multiple, I think there's three payloads here. So this is kind of how we organize the source code for the firmware. We have, it's very similar to core boot. We have a directory for the mainboards, slash the vendor, slash the specific mainboard. We have packages for the CPU, for the SOC, for the drivers, as well as the payloads. Details with the build system. One interesting feature we're using from rest is it makes it easy to just allocate everything on the stack, which is very useful during early firmware. Everything's allocated on the stack and you could tell at compile time how much stack you use as a tool which tells you. So you could formally prove how much memory your program is gonna use and whether it's gonna fit in the very small SRAM or a current system. Another thing we're trying to work out is coroutines. This is for the one second boot I mentioned earlier. Vast has language safety features which would greatly help in doing this to make it safe to implement coroutines. This is still a work in progress and if anyone wants to help out with this, we'd greatly appreciate the help. So the first target we did was ARM but you're probably not too interested in this. And we did ARM, ARM QMU, ARM on hardware. And then we switched to the high-five unleash board. So it has five cores, so five hearts. It has the heart zero, which has everything but a floating point unit and then four other hearts, which are capable of any index. At first, we wanted to run it in, we preferred to run Linux in M mode. The idea being Linux would run in M mode. The user mode would be in U mode. Linux would run without an MMU. So we needed some patches from first off Helvig. And we found some challenges with this. Then we switched to using Orboot to with OpenSBI as a payload. And that put Linux for us, which works a lot better. But we're still trying to run Linux in M mode. The main reason is we wanted Linux to be the only thing we're doing system like the lowest layer as well as some performance improvements to not having to contact switch to M mode. So I could show you the demo of. So to run it, you just type cargo make. So if you're in the directory for this mainboard, type cargo make run and it runs in QMU. And you can see here it boot into Linux. Linux running in M mode and then it crashed because there's no native MFS. So the next thing that we're working on right now is the next target is open Titan all gray. So there's currently no ASIC you can purchase to test this on. So your work has to be done in very later on a FPGA. It's a more embedded system. So this can't run next. So we can't do something like Linux boot. So we'll have to end up implementing more of these drivers inside Orboot. At this point, it's still a work in progress. We've gotten some simple hollow worlds and jumping to some simple payloads. But our main goal is to boot the tar kernel which is a kernel also written in rest and targeted for embedded systems. So this is how you can get involved. So we have a Slack. You can join that link. We have the GitHub. You can check it out. We have some documentation on how you can build and run it on various targets. Here's some items you could help us with. We have GitHub issues for these. And if you want to work on it, just ask on Slack and we can get you started. All right. Any questions? There's a secure boot in this case. I'll tell you where you wanted to be a hardware we trust. How does it interface? Are you going to have drivers to like the access station hardware? Yes. So we'll need some drivers for the AES hardware to implement secure boot. That's one of the projects we're kind of, that we need help with. Some verified boot system. Mainly right now, we're just trying to get the operating system to boot the tar kernel. But once we get that part, it shouldn't be too difficult to work with the details of a secure boot system. Oh, repeat the questions. Okay. Any other questions? Yeah. So the question is, does Orboot serve SPI calls or do we use OpenSPI? So when we use OpenSPI as the payload, OpenSPI serves those calls. We don't have any code in Orboot to serve OpenSPI calls. Many Vendniks are in M mode. It doesn't require that. So if you wanted OpenSPI calls, you would just use OpenSPI as a payload. Just as a payload. So it's a binary blob. So you just jumped? Yeah, we just jumped to it. Any other questions? Oh, here we go. Oh, okay. So that's where things have changed. I have a backup slide for this here. So this is our x86 policy. We put some thought into exactly what the policy should be. The problem is for x86 platforms nowadays, we need some sort of closed source blobs. We're working on sort of a measure to measure it, like what percent of the firmware is closed source, how much of it is open source. But you could find this policy on the GitHub. I think Ruan is sort of starting work on this. Yeah, but the difficulty is you can't make a fully open source x86 system at this point. Thank you.