 All right, it looks like we got a pretty nice crowd here, so I'll get started. So my name is Drew Festini, and I wanted to talk today about the feature of Linux on RISC 5. If you want to, there's a tiny URL there that will give you the slides. It's rv at the end there, slash rv dash linux dash 21. I also just pasted it into the Slack for the Embedded Linux conference. So I'm a Linux kernel developer for Baileb, and we have five team members that are speaking at ELC this week. So yesterday, Neil Armstrong gave a great introduction to pinmuxing and GPIO in Linux. And it had been a long time since we'd had a pin control talk at ELC, so that was quite nice. And then Bartos tomorrow is going to be talking about some lessons learned from both libgpod and the GPIO subsystem in Linux and the evolution of the API there. And then also tomorrow is Kevin and Alexandra from Baileb as well, talking about RISC 5 support in Zephyr. I'm also on the board of directors of the Beagle Board of Work Foundation, and I'm involved in our Beagle 5 initiative to create open source hardware boards, or open source hardware RISC 5 boards. I'm also on the board of directors of the Open Source Hardware Association. So if you haven't heard of us before, one of the things we do is we have a certification program for open source hardware, so you can go and register your project as open source hardware if you'd like to. And I'm also an ambassador for RISC 5 International. So one of the things I wanted to highlight here before I get into my talk is what's going on with RISC 5 this week at Open Source Summit in ELC, because there's a lot. So actually yesterday, Ateesh and Anoop from Western Digital gave a presentation about PERF on RISC 5. And actually later today, there'll be a talk from Vitaly on XIP, which is Execute in Place. So running directly from Flash. And then also later on today, there'll be a tour of RISC 5 for ARM developers. So this is from a couple of people from, I believe, Penguin Tronics that work on BureauBox. And looking through the slides, I think it'll have some good correlations there if you're familiar with ARM, how things relate to RISC 5. And then also tomorrow, there's going to be a talk about RISC 5 support in Zephyr. And that was all virtual, actually. So all those people, most of them are in Europe and they're already up to a 10. So the things that are happening in person is actually just prior to this, Kim from RISC 5 International gave a talk. And then actually, I guess concurrently to this, there's also one about an exciting new thing that's going on called the Open Hardware Diversity Alliance. So Kim from RISC 5 International talking about that right now. You'll be able to, I think, catch that in the virtual platform after this, or stop by the RISC 5 booth in the Expo Hall. And then Kalista, who's the CEO of RISC 5 International, will be talking later today at 4 PM. And then on Thursday, we have a special event. So the theme is Open Hardware and Open Software. So it'll be people from the RISC 5 and Zephyr communities. So if you're interested in doing this, it's on Thursday morning. You do need to add it to your registration. So if you stop by the help desk, they can probably help you with that. We've got three hours of things happening on Thursday morning. So if you haven't had your feel at the end of these three days, then you can do that on Thursday morning. And then one thing I wanted to highlight was, last week, was Linux Plumbers Conference. So other than Embedded Linux Conference, I would say my other favorite conference is Linux Plumbers. And one of the things that's unique about Linux Plumbers is we have what's called microconferences. So there are four blocks where there are short presentations and then a lot of discussion. So RISC 5 is still evolving and also the support for RISC 5 and Linux is evolving. So there's a lot of things that we need to discuss among developers and people working on the specifications. So there was five sessions last week. You can go watch the recording, the live stream. I also took a bunch of detailed notes. So if you're interested in RISC 5, which you're here, so you probably are, I highly recommend checking it out. And then coming up in December, in San Francisco is the RISC 5 Summit. So it's co-located with the Design Automation Conference in San Francisco. So that should be exciting as well. You can still register for that. And then there's also meetups around the world. So if you go to community.risk5.org, you'll see there's a bunch of different meetups. Some of them are still doing virtual meetups. And then hopefully, at some point in the future, we can get back to having in-person meetups. And if you live somewhere where you don't see a group, you can actually start one. So there's information on community.risk5.org about how to start one if you're interested in doing that. And then something I started up recently, I guess just a few weeks ago, was I wanted to have a bi-weekly meetup for people to interact in real time. And part of this is we haven't had conferences in a long time. We aren't having in-person meetups. So it's just like mailing lists, which is sometimes insufficient for human connections. So we started doing this thing bi-weekly, where we just do a video conference. And it's loosely formed. The idea is to talk about open-source software support on risk-5 and also development boards. But it's pretty open. So to make it possible for people around the world to interact, we actually have one that happens in Thursday morning in Asia. So the next one will be October 13. So if you're here on the West Coast, it'll be in the evening. It'll be in the morning in Asia. And then November 3, we have one that's in the morning here in the West Coast. And it'll be late afternoon for Europe. So hopefully, we can get everyone around the world involved between one of the two time slots. And if you're interested in maybe doing a short presentation, please get in touch with me. Otherwise, this is kind of an informal chat. So this is embedded Linux conference. So some of you are probably familiar with risk-5. But if you're not, risk-5 is a free and open ISA. So it started back in 2010 with computer architecture researchers at Berkeley. And they were looking for an instruction set to do their research projects around. And risk-5 kind of evolved from a three-month project to like, well, 10 years later now. And the main person behind it at the beginning was Krista Sanovich. And he has an interesting talk from the summit last year called risk-5 the next 10 years, because it was the 10-year anniversary. So if you want to learn more about the history of it, that's a good one to check out. And then what's the V? Well, that's the Roman numeral for five. So it's the fifth instruction set, risk instruction set to come out of Berkeley. And then most importantly, why is it free and open? So it's free and open because the specification is licensed as Creative Commons Attribution License, which is an open source license. So that's why when we say it's open, that's what it is, that specification is under an open license. So it's different about risk-5 because there's a lot of ISAs out there. So it's a simple, clean slate design. So when they started in 2010, they took all their knowledge from previous generations and kind of did a new thing from scratch. The key thing here is it has a small standard base and then multiple standard extensions. And that's also stable. So we have a base and standard that are frozen and then we have additional functionality as added in through optional extensions. But the base ISA and those standard extensions won't change in the future. And the other thing that's nice about this because we have those extensions is we can scale from tiny microcontrollers all the way up to supercomputers potentially. So there's several base integer ISAs. The basic one is 32-bit I, which is 32-bit integer. And it's only 50 instructions. So you can see right there, it's pretty small. For Linux, we're gonna be most interested in 64-bit. And then there's also even 128-bit, which is a kind of feature-proof address space. So there are standard extensions that we will be interested in in terms of running Linux on risk-5. So there's M for multiply, A for atomic, then there's different precision of float, F, D, and Q. And then there's G, which is shorthand for all of those. Well, for multiply atomic, float, and double float is G for general purpose. And then we have C for compressed. So this is similar to like ARM thumb. So Linux distros, like Debbie and Fedora, are targeting RV64GC. So if you're looking at a risk-5 core and you're wondering, oh, could it run like Debbie and Fedora, you wanna be looking for RV64GC. So a great way to get up to speed with risk-5 is there's a short book, like 100 pages, called the Risk-5 Reader. And you can find it at risk-5book.com. They even have translations to other languages. So it's a great way to get up to speed in like a short time. So sometimes people will ask me, or I'll hear people ask like, is risk-5 an open source processor? But risk-5 itself is just a set of specifications under an open source license. So the implementations to risk-5 can be either open source or proprietary. But the key thing to me is that open specifications make open source implementations possible. So we have an open ISA that allows us to actually do open source processor implementations. And there are actually a few, like one out of Berkeley there's Rocket, which is popular, also out of ETA search. There's a couple other popular cores, which have now been adopted by another organization called OpenHW Group. So there is actually a nice community of open source processor implementations. So the other key thing for running an operating system with risk-5 is the privilege architecture. So this gives us three different privilege modes. So at the lowest level, we have machine mode, or M mode, where our firmware runs. And then we have supervisor mode, or S mode, where our OS kernel runs. And up the top we have user, or U mode, where the application's run. And as we go up, we lose privilege. So U mode can't do things that S mode can do, and S mode can't do things that M mode can do. So the boot flow for risk-5 is probably similar to what you see on ARM. In this case, we start up in M mode, which is that machine mode with our boot ROM in our first stage boot loader. And then at the end, we're in S mode, where U boot would load and then jump to Linux. But in between there, there's something new, and that's SBI. So SBI stands for Supervisor Binary Interface. So this is a non-ISA risk-5 specification. And it's the calling convention between S mode and M mode. So if we have S mode software, like the Linux kernel, one of the ways that we can make it be portable across implementations is by abstracting the platform-specific functionality away. So that's what SBI allows us to do. So SBI originally was required by the Unis class platform specification, and there's a mailing list where this is discussed. It's now being replaced by something that's upcoming called the risk-5 platform specification, and I'll talk about that a little bit later on. So there's a base extension, and then there's also other extensions for like timers, inter-processor interrupts, remote fence. And then the common implementation is called Open SBI. So this is an open source implementation that many platforms are using, and it has like layers of implementation. So at the core, there's just a core library that implements SBI, and then you have platform-specific library, and then on top of that, you have a full reference firmware that could run on a platform. And depending on the platform and the vendor, they will either maybe just use the core SBI library or the platform library, or just use the full reference firmware as well. So one of the new trends with Open SBI is to go to using something called generic platform. So these are systems where, they're device-tree-based systems where the boot loader hands off a device tree to Open SBI. So that's how it understands all the platform-specific functionality. So the nice thing about this is that it allows us to have the same Open SBI binaries across different emulators and dev boards. And then there are several systems that are using generic platform right now. So one of the things that's exciting right now is there's a hypervisor extension. And in hypervisor extension, we have a new mode called, so we usually have three modes, which was user, supervisor, and machine mode. So hypervisor adds HS mode, which is hypervisor, supervisor, and VS mode, which is virtualized supervisor. So this, instead of just having M mode to S mode, in between there we have the hypervisor, supervisor, and then the virtualized supervisor where our guest kernel could run, and then top of that we have the virtualized user where the guest applications would run. Oh, and then the exciting thing here is a few weeks ago, this specification finally went up for public review. So on Halloween, it ends, and then after that point, we'll be able to move into the next phase, which will get us closer to this being ratified, which is exciting. So SPI, the specification's still continuing to evolve. So in the latest one, which was recently released point three, it added a couple of features. It added suspend to the heart state management. It added performance monitoring units, or PMUs. So that's what allows us to do statistics of what's happening on the CPU for things like Perf, and then also a system reset extension. So rather than having platform-specific ways to do a reset, we now have an SPI away for the kernel to say, do a system reset, and then SPI handles implementing that. So the term heart confused me at first because you see a lot of references to this, and I was like, what is heart? So heart means a hardware thread. So kind of an analogy would be like, let's say my laptop here was risk five. I have four cores, and each of them has hyperthreading. So those would be eight hearts, which is basically the number of schedulable processors in Linux. So the number of penguins that you see when you boot up would be the number of hearts if it was a risk five system. Another interesting area of development is domain support. So this allows system level partitioning of the hardware resources to give different hearts, or to give different systems, different memory regions and hearts. So we could have something like, in ARM they have the TE, I think it is, and they have like the non-secure and the secure domain. So with something like open SPI domains, we could have a similar thing where we have a partitioning between non-secure domain and a secure domain. And a new Patel from Western Digital gave an interesting talk about that at the last risk five summit. So we also have UFI support, pretty much across the board in risk five. So both U-boot and Tiano Core ADK2 both implement the UFI for risk five. A grub two can also be a UFI payload on risk five. And there's also UFI support in the kernel for risk five. So at the point today, you can do something like have U-boot do a boot UFI into grub, which then boots into Linux on risk five. Or alternatively, you could use Tiano Core ADK2. And that's kind of the graph here of what it looks like when ADK2 is being used on risk five. So there is full support in QEMU for risk five. So for both 32-bit and 64-bit, there's even for one of the common dev boards, there's a machine so you can run the same binaries in QEMU that you would run on the dev board. It also has, in these new extensions that are being worked on, they add support to QEMU. So we have support for the hypervisor draft extension and the vector draft extension in there. And then from Fosdum last year, Michael from Bootland did a really great talk where in 45 minutes you build a system from scratch. So with BuildRoot, building a system that has just a simple busy box environment, but building everything including open SPI and BuildRoot and U-boot in the kernel all in 45 minutes. So it's a good way to kind of familiarize yourself with risk five in a Linux environment if you haven't done that yet. So there's been support in the kernel. So Palmer initially added back in 4.15. And if you're interested in following what's happening with the Linux kernel on risk five, there's the linux-risk5 mailing list. And the archive is on lower, which is another good way to keep track of it if you don't want to subscribe to the mailing list. And then last year there was a great talk from Bjorn from the Munich risk five meetup, talking about how it's actually a pretty nice time to get involved because it's still pretty small and it's a great way to get in there and learn the nitty gritty details of the Linux kernel. So the idea that Bjorn had in his talk was if you go into the kernel and to documentation features, there's a shell script called list arch, which if you run it with risk five as the argument, it will show you the kernel features for that architecture. And you can see here there's still several to do. So there's still work that needs to be done in risk five. So if you're interested in getting involved in the kernel development and you're looking for an area of the kernel that needs work, risk five is definitely a good place to get involved. So some of the kind of recent patch sets that are notable is KVM support for the hypervisor spec. The latest patch series we just posted on Monday by Anoop. And now that the hypervisor spec has gone into public review, we consider that frozen and it shouldn't change. So now we're looking good at possibly getting it merged in. Though if you're interested more in like the nuance of that, I highly recommend watching the plumbers session from last week. And then there's also the vector ISA. Which is in a draft as well and there's support for that as an RFC on the list right now. So there is support in several binary distros including Fedora. So Fedora aims to have a complete Fedora experience on risk five. And they've been working on it for several years now. So they both have a, you can go right now on your laptop and go and download the Fedora image and you can run it with QEMU and Libvert. And you can have a full graphical environment as well. And actually on your laptop, if you have a modern laptop it probably will be somewhat usable. And then they also support real hardware. So, and I'll talk about the dev boards in a little bit but most of the dev boards that are out there Fedora has support for. Though it's not like official Fedora, it's like I guess remixed technically because it's not like an official architecture yet. And Devin also has pretty good support for risk five. So Devin has the massive, I think it's more than 20,000 now but they have a lot of packages. And that graph there might be hard to read but the top line is gray. So these are Devin ports and risk five is the gray line there at the top. And so over 95% of packages are being built for risk five which is pretty encouraging. So there are other distros that are working on risk five. So Ubuntu has support in 2104 for QEMU and some of the sci-fi boards. And I know they have a team that's focusing on risk five. So I think we'll see good things out of Canonical. OpenSUSE has support that's currently under development and so it's considered an early preview. Gentoo has 64 bit risk five stages available and Arch is still kind of like an experimental development mode. But if you don't need a full binary distro, open embedded slash Yachto are a really good option. And there's the meta risk five layer that Camaraj maintains and some other people. So it has support for both QEMU. So you could actually right now go grab the meta risk five layer if you're familiar with Yachto and go and build a risk five image that would run in QEMU. It also runs on like most of the boards that are available like the sci-fi boards. And then an alternative to Yachto is Buildroot and Buildroot also has support for risk five. And yeah, going back that was the presentation that Michael did at FOSDEM that shows you going through from scratch with Buildroot to have a bootable risk five system in QEMU. So the board some of you may have seen and like I think actually it was 2017, ELC in Portland was the first time I saw it, was this board called the sci-fi freedom unleashed. So this was the first board I believe that Linux ran on. And this had a 64-bit risk five SOC from sci-fi. And the nice thing about this was because it was a hard ASIC processor, not an FPGA, that it ran much faster. So prior to this, a lot of the implementations were running as soft cores and FPGAs, which is great for flexibility, but not so fast because the clock speeds are just limited when it's a soft core. So this finally gave us a usable Linux risk five board finally. But it was expensive, it was $1,000, it's no longer made and the chip wasn't sold separately because sci-fi's business is designing IP, not making chips and boards. But it was cool to see Linux with a full Fedora GNOME environment running on a risk five board. So more recently, Microchip has the PolarFire SOC. So this has the same quad core complex that's in the sci-fi unleashed SOC, but in this case, Microchip's added in FPGA fabric as well. It also has support for DDR4 and PCI Express. The other nice thing here is it's a full commercial product family from Microchip. So they'll be available in distribution, they'll be good public documentation, all those things that come along with, a full product family from a top tier chip vendor. And if you're wondering like, I didn't think, I didn't know Microchip did FPGAs. It's the former Micro-Semi business unit and they acquired them. So this came out of that. And last year they came out with the Icicle board. So this is a $500 board, you can order it on crowd supply currently. So it's still kind of expensive because it has a very large FPGA fabric on that chip. But it was half the price of the unleashed board and also adds a big FPGA. So that's a benefit. Those still may be too expensive for some use cases. So at the really low end, there was this nice chip called the Kendrye K210. It's actually dual core, 400 megahertz, which is actually pretty nice, you know? You can make a usable Linux system with that, but it only had eight megabytes of SRAM and no DRAM, no external memory interface. So you can get dev boards that are like $13 like this one here. And support was added back in 2019 in Linux 5.8 by Damian, Lamal and some other people. And there's support in it for several of the boards in Uboot. So it's also a nice way, if you just wanna run Linux on RISC-5 for less than $15, you can go through that and do it. But it's not necessarily particularly all that useful because it only has eight megabytes. Beyond that, it doesn't have an MMU that's functional. So the MMU implements the pre-draft spec, so it's not supported by the kernel, which means we don't have shared libraries. So actually the eight megabytes runs out really, really, really fast. Damian's still trying to work on some ways to get around that. So there's a link in there to discussion of this Elf to binary flat converter, which is one way to maybe get around things, but with eight megabytes, it's limited. But it was a nice way to get some hands-on physical RISC-5 hardware that could run Linux. So PSY5 recently launched, well actually I guess it was like the end of last year, but it's shipping now, on matchboards. So this is kind of their next-gen core in a new SOC called the FHU740 instead of the 540. So same sort of configuration of four cores that would be running Linux, but it's much faster. It's also in this interesting mini ITX form factor. So you can actually make a workstation. It has PCI Express and M.2 connectors, so you can actually make a useful developer mission with this and do native RISC-5 development. So another high-end design comes from Alibaba, has a chip design division called THED, and they have this design called the GenT910. So they announced this a little while ago. It's a 16-core, 2.5 gigahertz RISC-5 processor design. It's really high-end. It's a 12-stage out-of-order core, so it's targeted towards high performance. They wrote a really interesting paper about it, which is linked there. They're actually using it in some of Alibaba's production in FPGAs for certain things, and it's kind of comparable to an A73. And as part of this, Alibaba surprised everyone. Alibaba, THED surprised everyone back in January. When they said, like, surprise, we ported Android to this test chip, which at the time, like no one really thought we were close to having Android really running in any meaningful way on RISC-5. So this is really exciting. If you click on that link, it takes you to the GitHub repo, and there is now an Android special interest group with RISC-5 International, so they have meetings to kind of push this forward. And this board here that you see here with this like cell phone shape display on it is called the ICE board. So this was like a low-quantity test board that they did with this test SOC, which has that 910 design in it, so it has two cores in there. So this isn't something you can buy, but it was a really interesting, I think, proof of concept. But so THED asks multiple processor designs that they've done. And another core is called the C906. So this is much smaller. It's just the five-stage in-order pipeline up to one gigahertz. So all winner, who many of you are maybe familiar with from their ARM SOCs, has taken the C906 core and put it into a SOC called the D1. So the D1 is probably like the first low-cost RISC-5 SOC that can run Linux like reasonably well, because the Kendrite's kind of limited by not having an external memory bus. So all winner, all winner has a division called all winner online, and they've produced this official dev board called the NESA. And you can find it online for like, starting around like $115. There's several different companies that are reselling it outside of China. So it has that one gigahertz, single core, and then it also has either one gigabytes or two gigabytes of memory. It's kind of like a form factor that's common for single board computers. So if you're interested in getting development boards, RISC-5 International has a really good program called the Developer Boards Initiative. An idea here is that RISC-5 International wants to get boards out into open source developers' hands. So for this initiative, like RISC-5 International is looking to work with everyone that's making boards, right now, this really just the all winner D1 board in the sci-fi fun match board. So if you wanna participate, you can click on the link there. It takes you to a form. One thing is it's preferred that you're a member of RISC-5 International, but individuals and nonprofits can join free of cost. So if you're interested in doing this, probably best if you sign up, become a member, and then you fill out the form. And I'll talk a little bit more about the different things that you can evolve with in RISC-5 International as well. So explain what you're gonna do with it. So it might be like, oh, I wanna add RISC-5 support to a particular upstream open source project that I'm working on. But I will say don't overestimate the hardware you need. So the most common board that we have available is the D1 board with one gigabyte of memory. And then we do have some of the sci-fi of unmatched, but because they're so much more expensive and such fewer quantity, like don't say you need 16 gigabytes of memory if you don't need it, because you're much more likely to get a board if you say you have lower specifications that can be met by the D1 board. So the Sunzi community has a great reputation for supporting the all-winner SOCs, the ARM-based all-winner SOCs, and they've continued to do that with the D1. So there's a nice Wiki page on the Sunzi website. There's also a page for the D1 SOC and then a page for the Neza board specifically. And Samuel Holland is one of the developers in that community and he's done a great job of trying to get different mainline projects to run. So there's like the low-level bootloader and then on top of that open SPI, U-boot and Linux. So he has his own branches right now. And if you're interested, check out the Wiki, check out these repos, see what he's working on. There's still things that need to be resolved, but if you want to, you can grab these like recent versions of the upstream projects with patches on it and run something close to mainline. And Fedora also runs on the D1 Neza board. So Wei Fu, who's also a RISC-5 ambassador and an engineer at Red Hat. He right now has a Fedora raw hide image with XFCE for a desktop environment that runs on the D1. And he also made these nice diagrams of like the boot flow and like the SD card partition layout. So if you click on that link, takes you to the Fedora Wiki, you can check all of this out there. So there is a bit of an issue in terms of getting support for the D1 SOC upstream. And it's mainly due to the C906 core in it. So there was a great session last week at Plumbers called what's the problem with the D1 upstream. And Gal Ren is like the main kernel engineer at THUD. And they also had someone from Allwinner and then Wei Fu as well. So please check out the slides if you're interested. You can click on the links to their slides. There's also the full recording in the live stream. I have the timestamped in there. So the SOC itself is mostly reusing what they already have in our RMS SOC that's fully supported. So all the peripherals and stuff, all the drivers for everything that all that's upstream. But there's some issues that the RISV core that need to be addressed. So there are some not critical things to boot that are really performance optimizations like cache synchronization, instruction cache synchronization which helps out with I think like Jets for like Java and TLB synchronizations in the vector. So these are like performance things. They're not critical to be able to boot and have a working system. But there is something that actually is serious and we can't boot until we get this resolved. We can't boot an upstream kernel until this is resolved. So TI designed these C9XX cores. So both the C910 and the C906 I talked about. So the core that's in that D1 chip back in 2019. And when they designed this, there was no like, there was no way per the RISV specs to be able to handle DMA on non-coherent interconnects. And the RISV privileged spec back then said, don't use incoherent interconnects. Have your hardware handle the coherency for you. Which is actually a nice way of doing it. However, you know, with all winter they wanna make affordable SOCs, which is good because then we can build low-cost dev boards, which everyone wants low-cost dev boards. And people wanna know affordable chip that they can use in their projects or products. And one of the things there is to make these lower-cost SOCs non-coherent interconnects so are usually cheaper to use in designs. So we kinda have this thing where it's like, the spec said all the hardware should just handle the coherency. However, if you looked at some of those previous dev boards in test SOCs, they're pretty expensive. So like the cost-down SOC used non-coherent interconnects to try and make it a lower-cost design. But then we have this issue of the hardware doesn't just magically handle the coherency for us. And Galran did post about this back in 2019, but like the extension for handling this was still in a really, really phase. So it was kinda like they kinda had to decide to do something. And unfortunately, they didn't quite make the best decisions which it was not possible for them to really know back then, but like it's kinda one of those things. We're in a situation where we need to like have a resolution on this. So what happened in the meantime was this thing called page-based memory types or PBMT extension. So this came out of the virtual memory task group. So with RISC-V, there's all these different task groups for different areas. So there's one that works on virtual memory. And this specification came out. So similar to what we have in ARM is we can describe for a page the type of memory it is. Is it normal memory? Is it casual memory? Is it IO memory? So like these sorts of things. Which RISC-V didn't have a way of doing it until this extension got proposed. The nice thing though is this extension has now been frozen and put into a 45-day public review period which I believe will also end on Halloween. So we are actually close to maybe going into next year this becoming a ratified specification. So for future chips that are designed that don't want to have coherent interconnects, they can use this extension and be able to handle the caching behavior for pages with these extensions. However, we have the issue of, T had made certain decisions two years ago and as it were, they don't really match up with what the PBMT extension has. So I don't know if you can read that but basically the deal here is the bits, they're using the same bits in the PTE format, the page table entry format, but the bits, what the bits mean are not the same. And even like the semantics are different. So like it's not a one-to-one mapping. It's not just like, oh, like bit one here was like non-cashable, but like bit three over here is non-cashable. It's like the semantics of what those combinations mean are different. So it's not something where we can really easily work it out. So there's a lot of concern about merging support for this custom PTE format into the kernel because it does not conform to a RISC-V specification. So the first thing that's easy to tackle is, well, now that PBMT is a frozen spec and under public review, we can start to get ready to add support to Linux for the page-based memory types, which is good and we need that anyways. So Gauran has posted up a patch just recently, like in the last week for that, and there's a lot of good discussion on that patch. Though we still have this situation is once that gets merged in, future people will be able to use it, but then what do we do about the C906 core in the D1? So that is still something that's, we've not come to a conclusion yet. So I would say if you're interested, go watch the stream from Plumbers. I took a lot of notes as well and also watched the mailing list. So this is kind of one of those things where like, you know, we finally have a low cost DevBoard that can run Linux and like it can actually run pretty close to mainline, but in order for it to actually run mainline, we need like some resolution on this page table format issue. So I'm not sure exactly what happened, but hopefully this caught you up to speed. If you're interested, you can now start following the mailing list and see what's going on. I mean, for a practical sense from the users, like it's not that substantial of a patch set. So, you know, it might be one of those things where like the D1's almost upstream, you know, like most everything's upstream. And then we have like this patch series to fix the page table format. But hopefully we don't have to do that. Hopefully there's a way to handle this as a Rata or something like that upstream. But it really kind of depends on if the maintainer of the ArchSupport and Linux for RISC-5 is able to be convinced that this won't set a bet president. So let's say you don't have any hardware at all. Well, one of the really nice things you can use is Renode is an open source project for MapMicro. And it can simulate a full hardware system. And it even has configurations for different boards. So I mentioned that Sci-Fi Unleashed board that's expensive and rare. So let's say you want it to pretend like you had one of those. You can go install Renode. And then on your laptop here, you can have the full Sci-Fi Unleashed running. And actually because, you know, if you have a modern laptop, it's very fast as compared to like these RISC-5 boards. So it actually runs pretty well. It doesn't feel like a super slow simulator. So it's actually usable. So I mentioned a lot like these different specs, which is probably confusing if you've never looked at them before. And there's all these different new specs and extensions being proposed. So if you're interested in this, I highly recommend getting involved. If you're not a member of RISC-5 International, you can join for free as an individual or a nonprofit. And then once you get involved, once you sign up, become a member, there's a lot of links and emails and groups and meetings and this can be confusing. So there's this technical Wiki landing page, which is like the best single place to go to try and find links and things to different things. So from here, you can see the technical organization chart. You can see what ISA extensions are on the deck for freezing and which ones are coming up for ratification. You can see the different technical working groups. You can see the, you know, the software ecosystem, basically everything that's going on. It's kind of like a central place to go off from there and find different resources. And then the way that most people interact on this is through mailing lists. So there's the list.RISC-5.org, which is groups.io run. And once you become a member, you can participate in the list, but all the lists are public. So even without being a member, you can go look at the public archives in the mailing list. But if you want to like participate in the mailing list, then you should become a member. But you can still do that free of cost as an individual. And then a lot of these different groups that I mentioned have bi-weekly or monthly meetings. And you can find all of those on the technical meetings calendar. And if you've previously been involved in this, they might be confusing because we used to have a different calendar, which is called tech groups calendar. And then we don't use it anymore. We use technical meetings calendar. So if you are like me and you used to attend these meetings, make sure you're looking at the new one now. So here's just a screenshot of right now what it's like. So you can see here like for many days there's things happening. So there's maybe like four that I participate in. So there's like bi-weekly meetings for them. So, you know, every other week I'll have a meeting that I attend. So I wanted to go into some that are important for a full operating system like Linux. So one is the cash management operations task group. So this is another thing that is also relevant to SOCs, especially low-cost SOCs, that wanna be able to handle devices, peripherals that are gonna do DMA that are not on a coherent interconnect. So they need to manage the coherency of the DMA transactions. So there wasn't really a way to do this until this extension got proposed. So this allows us to be able to do things like invalidate, clean and flush like the L2 cache, for example. So this one also now is under a 45-day public review. So hopefully soon going into next year it'll get ratified and people can start building hardware that has these new cash management instructions. However, there's already chips that exist that don't have that. So one of the things that we can do is we can implement this cash management operations in the kernel. And then if we're on hardware that doesn't have these instructions, with RISC-5 it'll always trap into SBI. And then, for example, open SBI could emulate those instructions. Which wouldn't be fast, but it would be a way to handle these for older hardware. Another one that's important for operating systems like Linux is the advanced interrupt architecture. So we had these existing interrupt controllers called the PLIC. And now we have the advanced platform level interrupt controller. And we also now have the incoming message signal interrupt controller, or MSI, which is important for PCI Express. So with the new AIA we can handle things like PCI Express buses. Kind of similar to this, but different than AIA is the A-clint. So this is like the local interrupt controller that's on the core. And we used to use this thing called the Sci-Fi of Clint, but that was very limited in what it could do. So this one kind of re-images that with market abilities, but doesn't bake backwards compatibility with the Sci-Fi of Clint that's already used on a lot of existing boards. And there was a presentation last week at Plumbers from Manup. He breaks it down on this table here so you can kind of see the different combinations, which if this is all new to you, it won't probably make any sense. But once you read a little bit more, it's kind of useful because you can kind of see the different combinations of things that would be allowed under what scenario. So that would be. And then finally, a very important one for Linux is the RISC-V platform specification. So if you're thinking like, well, there's all these different extensions and letters and numbers, and like how do I know if like my software will run on a RISC-V system? So this is what the platform specification is trying to solve. So in the platform specification, we have OSA, which is A for application. So this is meant for a full operating system like Linux. And then it has, it says for the ISA level, we have these profiles, which are kind of like combinations of those little extension letters like RV64GC. So this says like you need to have these ISA extensions. So there's that level. And then beyond that, we need to talk about the system beyond just ISA, like interrupts and how the different like serial ports and these sorts of things. So all that's in the specification as well. And for people that come from the ARM world, one thing that will be of interest is that part of the baseline here in the OSA platform specification is that you have to comply with EBBR. So for example, you can use device tree to describe the hardware, but you need to boot with UEFI in U-Boot, which is fine. And then for the server extension, it mandates ACPI, which I know, but you know, it actually is kind of expected for servers. So there's also M-platform for microcontrollers, but it's not very well defined right now. There was a session last week on the platform specification. So if you're interested in this, check that out, because it's all the people that involved just talked about this for like a couple of hours last week. And finally, I mentioned ACPI. So for the server extension, there is now actually a proof concept of ACPI on RISC-5. So you know, in that feature where we have high-end RISC-5 processors running on servers, this will be a part of that. So if you're interested in that, this was also a presentation of plumbers last week about how the current ACPI proof of concept is working. And to end on, I just wanted to, if you're interested in this, and we've just been talking about this for 50 minutes, if you're interested in Linux on RISC-5, there was just five hours of discussions last week at plumbers from like the people that are actually doing all this development. So the best thing I can do, if you want to learn more, is go watch the live stream from plumbers last week. So with that, are there any questions? In the front? Yeah? So there's a lot you can do with FPGAs because you don't have the whole 18 months to do. Oh, sorry, yes. So the question was, what's the difference in the context where we have a RISC-5 core in FPGA versus in one of these ASIC chips that I was talking about? So the one limiting factor in FPGAs is even on the really fancy ones, like 200 megahertz is like super high end clock rate for a soft core in FPGA. So like you're limited in terms of your clock rate of the core in the FPGA. However, you have a lot of flexibility to do things. So there is actually a really strong community of people that are doing FPGI, RISC-5 FPGA designs in Linux on FPGAs. And one of the things you can do is like you create like systems with many, many cores. Like there's a group out of, it's like Stanford or something like that, Princeton called OpenPeton and they have like a thousand cores. So they're running Linux on a thousand cores in FPGA. So maybe the cores are only a hundred megahertz, but you can scale it out massively. So kind of different ways of approaching problems. So in FPGAs are great for that because the downside to the hardships is it takes like 18 months or more to get one made, right? So you could have like the same design. They tend to sometimes be designed somewhat differently to take better advantage of the resources that are in FPGA versus like a silicon design. But it can also just be the same design. Like the rocket core from Berkeley has been put into FPGAs. It's also been taped out in A6. There is an interesting one called VEX RISC-5. That's really good for FPGA designs. And there's a project called Linux on Litex, VEX RISC-V, or just email me, I can see the link. And then like within a half an hour, you can have Linux running on a soft core in FPGA with like multiple cores. So it's a great way to like experiment with things. What development tool do you have IDE together that sometimes takes together? Yeah, so you're kind of asking about like the software tool chains that exists, compilers and IDE's. So for tool chains, it's pretty much what you would expect like GCC and LLVM all exists. So most of the major open-source tool chains already have had support for several years for RISC-V. For IDEs, for graphical IDEs, a lot of the commercial vendors definitely have, there's a bunch of different commercial vendors that do RISC-V development, like they develop cores and they also give you tools. So like Sci-Fi, for example, has an IDE that's based on Eclipse. And most of the different RISC-V IP vendors all have yeah, like graphical IDEs, usually based on Eclipse. Yeah, yeah. The which one? Oh, Renote, yeah. So Renote is independent. It is similar to what QEMU does, but it kind of has like everything included. So you can just say like, present this board to me. So it's similar to what QEMU does, but I would say it's easier to use and more full-featured. Yeah, yeah, yeah. So it's really great because you can say like, you know, like I want to have the same environment I have in this physical dev board or if you're developing something, you can like configure it to act like hardware that doesn't even exist yet as well. But they have, if you look for, if you search for Renote, there's a lot of great talks from AntMicro about it. I'm not sure about the exact speed, but I would just say like, it's not like terrible slow, like a ISA simulator is really, really slow. So this is actually like usable because it's emulating it. It's not actually like simulating the actual core. Uh-huh, I think there was one over here. Yeah, uh-huh. Yeah. You mentioned that the Fedora is the center. So for the people that couldn't hear, Matthew, who's the, from Fedora was that saying, well, it's a re-spin because there's not like official rack mount hardware. So if you could get a risk five server that you could put in your data center, then it could become like an official Fedora. So how far away are we from that? I mean, probably the closest right now is the sci-fi on a match board, because it's mini ITX. So you can kind of make a server and actually Stefano from his Fire International over here, he's, I think, involved in some CI and testing. Like, I think we even have an idea of having like a data center colo with some boards. So they're not that fast, but they're usable. And like, so David Abnerachmanoff who does the Fedora US builds for that. Like, you know, it's, you know, they do it natively, but it's not like, they can do it natively, but it's not super fast, you know. So like, the point where we could do like a native building, I think we kind of need like the next generation of like SOCs to come out for that to be really be feasible, you know? Yeah, go ahead. Yeah, yeah. Yes, so that's the URL there. Did that kind of answer the question or? Yeah, like native compiling on risk five now, like the best thing you can get is really the sci-fi on match board, which does have PCI Express, so we use NVMe. But it's, you know, it's not gonna be anything like what you'd have in other like ARM or X86. But I know there are companies working on things. So hopefully maybe a year from now or two years from now we'll have, you know, better hardware. And that's kind of what the platform spec is doing, like imagine this feature where we do have companies making like servers, and then like in order for distros to like it, like the platform specification hopefully able to say like, this is a, you know, a risk five, it complies with the risk five OSA platform specification, so we know it'll run like Fedora on this server that I buy, but I think we're probably like a year or two away from that future to have like actual usable servers that are risk five. Were there any other questions in the room? Otherwise, I was gonna take a look at Slack here to see. Most of my colleagues are in France, so I feel bad that like most people aren't able to like, you know, be with us here in person, but I don't actually see anything in Slack. But if anyone has questions, you can hit me up in Slack or email me. So yeah, thank you.