 Hello. I'm appropriate greetings to the virtual room and thanks for coming to attend my talk. Today, we're going to talk about the state of software development tools for RISC-5 architecture. I'm sure you have attended two talks on RISC-5 in this conference so far and this morning's Kerstis keynote. In this talk, we're going to cover primarily Linux-oriented tools, but I'll also cover operating systems and try to go and cover some of the hard tosses and things like that. This is the agenda. Essentially, we'll talk about tool chains, its components, and then some system tools, emulators, simulators, some new language runtimes, and the operating systems, and what's the progress in there, what's new, and what's happening right now. If you have questions, feel free to ask them. I'll give some time towards the end of the talk so we can discuss those questions. Emulators, QMU has upstream support for RISC-5 and it can emulate RISC-5 on a X86 system and vice versa too, so we can have a X86 system emulated on a RISC-5 machine. QMU 5.0 has added hypervisor extension support and the Linux Syscon drivers and the RTC support as well. There is another emulator called TinyMU and if you're interested, you can just go in there and try out a few things you want to play with a pre-existing image and without any setups. This is really handy and it runs a build root-based port of a 32-bit as well as 64-bit tool chains and it also emulates the RV128 bit ISA. Spike is the oldest available simulator. It is also available and you can try it out and there are several operating systems that deploy Spike as well for emulation purposes. Renode is essentially for virtual development tool for simulating the hardware and I've pointed out some of the documents here where you can get a lot of details what's going on there, what different devices are being emulated in Renode and how you would be able to use it for your own purposes as well. With emulators, I would also like to talk about Linux Kernel. There has been a lot happening in Linux Kernel since 4.15. That's when the 64-bit RIS 5 support landed in there with stable API and the recent versions of Kernel, we have seen there is a CanDrive K210 support that has been going in into 5.8. It started with 5.7. There is a KGTV support in progress and KVM support is also a working progress and it has been submitted upstream for review and the KExec, KDump and KRAT probes is also working under progress and similarly the UEFI support for RIS 5 has been also under review and vectorized support as well. As you can see there is a lot of work that has been in flight right now and landing in various versions of Kernel and Clang built Kernel is also in progress and it is booting on KMU. You will see a few patches in the mailing list that are specifically supporting Clang built support. A lot of activity there on the Kernel side as well and on the bootloader side, I think Codeboot, Uboot they already have upstream support, the VBL, the Berkeley bootloader that was one of the initial bootloaders when the others didn't exist but recently OpenSBI has gotten a lot of attention and the new spec has been implemented as well and most of the KMU is also supporting OpenSBI and I think it is one of the primary ways to boot even in open embedded we switched to using this as a primary payload carrier. So moving over to tool chains, GCC 10 was released a few months ago and upstream support for GCC has been there for a few years now for RISC 5 but in GCC 10 we find there is support for this new assembly instructions they have a dependency on new binitals and bitmanip extension that's very interesting. They are also supported in GCC 10 and bit manipulation instructions these are extensions that are basically going to implement common bit operations that are specific to encryption or security related algorithms and they are very useful in those and they can be emitted into code as well as they are available as intrinsics if you would like to use but I don't think that all of them are still implemented there is a subtraction that has been implemented but I think more and more will be implemented as you can see but basically the basing fry is already in there so that's a great progress for bitmanip. LLVM and Clang, so RISC 5 was added in LLVM 9 as a experimental architecture and since then it has received quite a bit of development in Clang 10 release time frame Clang 10 was released again few months back and as you can see it has added the LTO support for RISC 5 so basic LTO support is in there you will be able to build on top of that a lot of other support that will kind of use LTO effectively and compiler RT which is the runtime now supports both RV and the RISC 5 32-bit as well as 64-bit and the sanitizers are available for 64-bit RISC 5 as well so I'm hoping that there will be a 32-bit version available soon as well and bitmanip instructions are also available on Clang as well as you can see BINUTILS again support has been there for a few years what you will see in recent versions is they have added support for the privilege spec version 1.9.1 and assembler has now capability to set the instruction set versions through command line so you could use MIS a spec to specify which spec you would like to adhere to in the assembler a GDB now supports the GDB server for RISC 5 for Linux which means now you can remotely debug your applications on RISC 5 targets and it has added the support for the native target for Linux as well since 8.3 but the GDB server is relatively new in GDB 9 of course the bare metal embedded support has been in GDB for quite some time now that is already there but this is a good point now that we can do the application development and debugging using GDB jtech debuggers there is a lot of free support for OpenOCD and it does support 64-bit multi core and then of course there are some of the closed sources or commercial tools that are available in jtech field SAG Air embedded studio which basically has the 32-bit support for microcontrollers a lot to walk and I think there are a few more and micro and others that are available as well if you are using proprietary or commercial solutions system C libraries have seen quite a few developments in the past few months and muscle which is kind of an embedded C library relatively new in the space has added actually a 64-bit RISC 5 support since 1.1.23 release that was early this year and 32-bit port is not available yet but what we can see is that 64-bit supports little engine it can support hard float ABI soft ABI as well as single and soft double floating ABI and it doesn't yet have big engine support or others but I guess so far little engine is what is more important 32-bit support for G-Lib C has been submitted and it has been under review for quite some time now it might show up in 2.32 release there is a discussion around whether it should be added in there there are some dependencies on 64-bit time T being implemented fully in G-Lib C on that because I think this will be one of the architectures that will support 64-bit time T on 32-bit architectures out of box as the initial port it will not have the legacy implementations and 64-bit RISC 5 requires a minimal kernel version for the Linux Lib C headers to be 5.0 the reason there is that there are certain syscalls that stops that needs it so it was discovered and therefore this has been added in the G-Lib C documentation as well New Lib which is the embedded C library used primarily in bare metal kind of like standalone applications there have been syscall implementations there and there is a LibM support that is now available for RISC 5 called New Lib Nano and a new size optimized memory functions has been added for RISC 5 as well so if you are using New Lib in embedded targets these are great improvements to the system C library and New Lib that is Now moving on to the language runtimes Go has been added so as you can see this slide is a little probably not up to date but if you have downloaded the PDF there I have updated it so Go 1.14 has added RISC 5 64-bit as experimental architecture in 1.14 release and this support existed out of tree for some time but then 1.14 has accepted the port the CGO support is not yet accepted it is still out of tree but the implementation is available and this is required for some of the container D implementations for some plugins like SQLite and then ButterFS and Pi build mode is also added which is actually not yet upstream but I'm hoping that it will be soon accepted for maybe 1.15 release so that's a great news for the Go community and the RISC 5 community as well we have added the Go support in open embedded when it was out of tree as well which was based on 1.13 it was available in the RISC 5 layer because the main Go compiler back then didn't work but with 1.14 perhaps we will not need those out of the RISC 5 implementation that we have in there so there is bootstrap that is done and I've pointed this link here if you are interested in bootstrapping Go compiler then you could go and you can work on the compiler itself but if you are doing applications and the major distributions will have it available for you so that's really great progress and moving on to Rust Rust actually has been there for the embedded side of things for quite some time now and for bare metal so for 1.36 release onwards it was available and some of these packages like low level access for RISC 5 these were also available in recent versions however recently RISC 5 has been also added as a target to Rust and it's a tier 2 target so I think Rust has like tier 1 targets and tier 2 and tier 3 and initially it was added as a tier 3 target because it wasn't documenting how the tests are run the just tests are run, test suites and then it basically engineers from code think contributed a lot in this area where they got the tests working as well and also promote RISC 5 as a tier 2 architecture but I think it is only for cross compilation as of now I think there is work on going to make it for the host as well so I think next time when we talk perhaps we'll have RISC 5 as a tier 1 architecture for Rust community so I think this is also a great news for RISC 5 community because there are several packages in various distributions that depend on Rust and this will just make it better for we'll see that some of those packages which are probably missing in distribution because of these run times are now available the Vazem time is actually a WebAssembly implementation I found it very interesting they are supporting RISC 5 as well and so I don't have much details on what the details are in there but if you are interested in WebAssembly I think CraneLift and VazemTime they are good projects to look into so before I jump into the operating systems I also wanted to mention about Java OpenJDK they do support the 0VM backend but the hot spot perhaps is still missing in there so you can in theory get like Java applications working on RISC 5 they may not be as optimized as other architectures because the JVM that is underneath is Chastain interpreter and OCaml also has a out-of-tree support that is available and perhaps in future we'll see also submitted upstream and it will be one of the supported architectures for OCaml as well so I know that Fedora and other distributions they do have for OCaml implementations and Linux operating systems Debian is supporting the Freedom U540 as well as a QMI target and there is a nice wiki page if you are a Debian developer or user and want to participate in RISC 5 community please go read through this and to get acquainted with it and what I always follow is this graph here and as you can see the gray line is what the RISC 5 port is it started somewhere on 2018 and you can see like how steep it was and then of course now it is somewhere above 90% I believe or touching 90% in many cases so as this new language runtimes they get implemented all these tools are helping more and more packages in Debian ecosystem get compiled and be available for RISC 5 architectures so that's great and I'm hoping that one day it will be nearly 100% or some of those green lines you see on the top Fedora so in Fedora RISC 5 is called as an alternative architecture and there are like minimal developer and GNOME images that are now available and it supports GMU as well as the Sci-Fi Unleashed target that is available and I think it can also have like expansion boards for PCI graphics and some like data storage and you can have like a full experience of a desktop as well on the freedom board so that's actually really good I know that several of us use Fedora natively on this port OpenSuzi also has the implementation and Tumbleweed which is the bleeding edge and the ruling release for OpenSuzi has a RISC 5 port and also it has a RISC system DNS 1 available and if you want to look at packages the ports packages what all are available I've provided the link here Gen2 I'm not sure I couldn't find much information but I think you know there is a landing page in there for Gen2 as well and so on the embedded side I'll cover OpenEmbedded as well as some other like build routes so in OpenEmbedded we have both 32-bit RISC 5 as well as 64-bit RISC 5 support and they are available in the 3.1 release the 32-bit 64-bit QMI support is in OpenEmbedded core which is now it's upstream in OpenEmbedded and Linux Yachto which is the kernel that Yachto project uses supports RISC 5.64 as well essentially that is basically an upstream implementation but adds the configurations and other patches that OpenEmbedded and Yachto project needs for testing and the purposes so that's great because it provides mainstream experience for testing the architecture and using this kernel to run through all the existing test infrastructure that we have and it supports both muscle and glibc for 64-bit as of now and it also supports multiple ABI's so I know that the desktop distributions primarily stick to more common ABI but in embedded space you might want to choose a no-float ABI for example RB64i and there is a no-float ABI for RISC 32 as well as 64-bit and then of course you have the ABI's for the general ABI's the GC versions there is a architecture layer called meta-RISC 5 that's hosted on the RISC 5 handle it supports bare metal SDKs so you could build tool chains and SDKs that you could use to do bare metal or stand-alone application development so you can generate SDKs for both 32-bit and 64-bit they could be either using new lib or could be purely bare metal depending on your use case and it also has support for the U540 board so all the board support package is there and the 32-bit QMU machine is also part of meta-RISC 5 eventually if it gets accepted into G-Lub-C 232 you might promote it into open embedded core and thus it will be migrated from here until then it is in there it has been supporting the cross-building Go packages and as I mentioned early in the Go slide where we were able to build Go 1.13 when it was out of free there is work in progress to get that into 1.14 and perhaps we'll be able to get all the cross-build infrastructure for Go that is in open embedded onto this here as well in coming few months and this also has a client support as a system compiler for both 32-bit as well as 64-bit RISC 5 and 64-bit RISC 5 can run the P-tests which is the Yachtos automatic test framework and there has been some work in there that has been pending in the past but thankfully there were few issues we had in QMU and they have been addressed so today you could run the tests on QMU we haven't yet built root all the support is upstream and it fully supports both 32-bit and 64-bit architectures like open embedded and currently it's supporting kernel 5.4 and it's regularly tested and you can see that the auto builder I've kind of pointed here their builds for RISC 5 64-bit as well as 32-bit and much like open embedded it supports both muscle and G-Lib C and of course muscle 32-bit port is not existing there yet so therefore there is no 32-bit support for muscle but G-Lib C they should probably have both and similar to QME targets there is a RISC 5 64-bit and RISC 32-bit are available OpenWRT you can see that OpenWRT added support and it was added for Hi-5 Unleashed and there was a Vertex 7 based implementation FPGA based implementation and also could run on QMU and it does support both muscle and G-Lib C I am not sure whether it has been upstreamed yet but it is still available in the link that I pointed here and FreeBSD actually one of the oldest supported operating system for RISC 5 it similarly supports Hi-5 Unleashed as well as QMU but in addition there is a spike implementation also available so you could use spike as a emulator as well and I think there is a healthy community and they are on IRC as well for and that BST has added support for this in the 10.0 release which is a nice addition to the BST family of the operating systems and I am hoping that soon we will get like OpenBSD and others adopting RISC 5 as well pre-RTOS there was an announcement from AWS supporting RISC 5 as one of the primary architectures and they have several embedded boards that are running RISC 5 as supported and I have listed here there are demos available for the Mi5 and to GL025 and there is a RB32M1 Vega board demo and they are called the RISC 5 on the RISC core and there is a key implementation for the sci-fi e-model as well that is available so it is well supported in pre-RTOS when we consider the embedded side of the RTOS Zephyr has added the support for 1.13.0 that was few years ago and it has supported Hi-5.1 board I have seen it's 1.13.0 and there has been more board that has been added the softest is the VEX RISC eCPU and it's offered actually as part of the standard Zephyr SDK if you go download it you can find several RISC 5 boards that are now supported out of box they have also added the hard float support recently and they also exposed the compiler tunes through the Zephyr build system which means you could easily port it to a more variant of devices which might not be supporting the standard ABIs or you have different ABIs that you would like to use it's now easy to use there RTEMS has the upstream support for simulators and RISC 5 Clang and LLBM support is also available in the build system for RISC 5 in RTEMS and it has added a GDB support and tool chain support for 64 and actually the target support for both 32 bit and 64 bit is actually unified in one so there is a new board that is added called ES310RT so there is a BSB added for that as well so interesting developments in that area as well from RTEMS there are a few educational or academic RTOSSes like XV6 from MIT that does support RISC 5 as well and HELL NOS which is microkernel approach also implement 35 by SA as well so that's pretty interesting as well so help needed V8 there is no port for V8 as yet as a result there is no node jazz as well that is available so I guess those are targets that will need some help in the community and Java of course there has to be some jitted Java JVM available and that's not yet available and similarly new like Dart and these are upcoming ecosystems that will require to do and there is I think some help needed in there I have also seen that the gradual growth in the contributions for example Linux kernel but it has been steadily growing but we will probably need more contributions in that area I listed several features that are being implemented in the kernel but I guess there is a steady rise in contributions and that's a very good sign for the community growth as we can see and I'm hoping that V8 community and node jazz community will also start supporting it soon and perhaps next time when we talk about we will have some activity around those ecosystems as well so as you can see the upstream first strategy that RISC-5 community is following in general the out of tree support remains there when it is under heavy development but always effort is put in place so they show up as upstream supported targets and that's actually the mantra that the community has been always following so most of the software is upstream so if you want to participate in any of those communities we talked about you can use the projects regular communication mechanisms there is no specific RISC-5 out of tree ports or regular channels would be sufficient in some cases there are architecture specific mailing lists for example for kernel the reason being that's how the kernel is organized so there is a RISC-5 mailing list specifically for kernel but if you were to do some GCC, Clang or LLBM development or Go then you would directly participate in the upstream communities then there is specific to RISC-5 there are some mailing lists on RISC-5.org and there is a SWDAV there are a lot of software discussions that go in there and there is also a patches at groups.risc.org where all the patches for RISC-5 ports are sent and there is a channel RISC-5 on pre-node on software, hardware, other areas and there is a if you are a kernel developer there is a Linux RISC-5 specific mailing list so please subscribe to those participate there and there is a growing questions on Stack Overflow as well so if you would like to answer or learn about what has been answered Stack Overflow is also a good resource to try out various other things so RISC-5 International maintains actually a very active software status and if you know that status is not up to date for the project that you are looking at please submit pull requests and it will get updated in there it is a living document and it is always updated and the community provides that input in there so please submit any update requests or you find that it is out of is not up to date for whatever reasons and also go through that list and see where different ports are and they also have ports that are basically in there for example OpenOCD the reason is that the work for streaming it has been ongoing alright so that was all thank you for your time and I will now take few questions here I think we still have time here so we will go over questions please feel free to ask questions here alright so there is a question do you do any platform similar to the hardware support 64 bit kernel and 32 bit user space I am not aware of that is done yet but ILP32 kind of you know the ABI is under discussion there but I am not aware of whether we have that setup yet there is another question is android ported to RISV5 and the answer is no I guess it will take someone to work with the android community maybe someone from the silicon side and port it over but I guess Java support as I mentioned earlier perhaps there are few large blocks that needs to be solved first but I am hoping that we will hear some good news in future next one is what is the normal use case for 32 bit at this point 32 bit I think again there are microcontrollers that will use it and have been using it in some cases and there is perhaps going to be a Linux port as well because obviously the architecture is future looking there is also space for not only 64 bit but 128 bit as well but I guess practical purposes will still have 32 bit in the embedded space and rightly for space and memory reductions and there could be other reasons maybe you have like software that is 32 bit primarily but I think it will always exist there so is RISV5 free RTOS and Zephyr supported in Yachto answer is yes in a way that free RTOS actually there is a I think there is a meta free RTOS layer already available so I am not sure we have done specific work for RISV5 in there but I guess mostly what you can see is the TMI ports like emulator ports that are available so I am sure that it will work for RISV5 as well but there hasn't been specific PSP added I think for PR TOS in Yachto and Zephyr actually the STKs for Zephyr are built using Yachto project again Zephyr has its own build system which is CMake based but they do consume the STKs that are built using Yachto project so in that way it is supported but if you want to use Yachto as a build system for Zephyr then I guess I know that will not be there okay next question is can RISV5 be implemented in Altera FPGAs yes I guess so because there are many vendors you heard about in this morning's keynote as well that there is a polar fire I believe that is coming out and I think there are other FPGAs toolkits that are now having RISV5 in there so I guess it can be but I guess it is more of a question for Altera okay so the next question is which RISV5 boards are supported in Yachto project and in the core for the emulators primarily for QMU but if you use the architecture layer then there is support for the sci-fi freedom U540 board and as new boards come out there is support for adding that support as in when available but as of now you have the freedom board okay so there is a question on which modes used in U-boot and Linux for RISV I am not sure which modes you are talking about here but if it is related to ISA or otherwise I mean it depends upon tools more than the kernels but I guess the general support is there for the GC modes okay there is another question on should one use TileLink or AXI in a RISV SoC I think it depends upon the implementations right so RISV5 what we are talking about here is not architecture side so perhaps that will be implemented by whoever implements the RISV base SoC okay so there is one more question which approach would you currently suggest to support custom instructions on the software side generally I think if inline assembly if compiler supports that particular API and I guess adding that to the compiler would be a good approach and so you could use it as intrinsics or you could use it as inline assembly doing just it in assembly perhaps is in my mind a bit more maintenance is required so having it enabled in the compiler would be the right thing to do and given that now we have LLBM backend available for RISV5 a lot of other language runtimes that are using that as to target the compiler backend you will be able to use for example all those bits for different kind of languages so I think that's perhaps good to have that implementations in the compiler I guess I do have yeah so one of the questions that was clarified on which machine mode so basically implements the supervisory mode as well okay so I guess thanks everyone for asking good amount of questions and thank you for attending this talk I hope it was useful to you and I will be hanging out here in the virtual session so feel free to ask more questions after this talk and thank you everyone