 Hi, thanks everyone for coming. I'm Kim. Today I'm going to talk about the status of Embedded Linux on RISC-5. So RISC-5 is a recent architecture and there has been a lot of exciting stuff that has been happening in the community. And essentially, I'll just cover what this architecture is about at a high level and various projects, their upstream status and where things are currently working in progress and where help is needed. So I think in the end you can ask questions as we speak or you can reserve your questions towards the end. And so we'll hopefully at the end of the talk you will have a lot of pointers if you're interested in RISC-5 ecosystem and you know you may be working on various things in Embedded Linux. It could be the kernel, it could be tool chain, it could be other spaces and I'm hoping that all of you will find something new and or something to look forward to in RISC-5 ecosystem. So just an introduction. It's called RISC-5 and because it's the fifth iteration of a RISC ISA from University of Berkeley, it has 32-bit, 64-bit and a 128-bit wide instruction set. As you can see, 128-bit is basically a learning from past industrial experience to have it reserved even though there are no designs yet which are using 128-bit wide instruction sets, but it's there. Primarily, you will find 64-bit is by default the instruction set that is being used today and there are certain embedded variants which are also using or are tending to use 32-bit and we'll cover that a little bit more. It's a little endian by default and I pointed this specifications link. So as we know it is all open source and we all can participate. At least we can look at the specifications. So I encourage you to go there and look for all the specs that has been designed. Certain specs are still being discussed and some specs are locked down so they're available for implementation and so feel free to look through and if you have inputs, there are mailing lists. You can participate, provide your inputs. It's all open. So primarily you will see this RV32i, RV64i and all these conventions. So basically there is a core instruction set and then there are extensions and they are denoted by these letters here and for example if you have an extension to implement multiply division, it will be denoted by M, atomic memory accesses by A, floating point, similarly double floating point and compressed. And there is a naming scheme to represent the ISA that you have in the end and there are also extensions that actually which can be non-standard and you would basically mark them with X. So there is this naming scheme that you would follow when you have a customized instruction set because the idea behind is that you can enhance it the ways you want, provided you built upon the core instruction set. G is basically a abbreviation for general instruction set and it's actually a combination of these extensions added on top of the base ISA. So you would see that it's actually expanding to RV64imafd. So we'll talk about this more because this is generally what is being currently followed for various software ports. So I'll now give you a little detail on where the status is with respect to the various software in the ecosystem. So the software is developing very fast for RISC-V and what I'm going to talk today may be obsolete tomorrow and some of it is already is obsolete because a lot of upstreaming, so the effort is upstream first. This is a learning from various other architecture ports and that the RISC-V community has taken the step to basically make sure that all the basic support in tools, in kernel, everything is upstream first. This strategy is actually being followed by a community and as a result we have seen that a lot of the basic tool support, especially you need compilers and a basic tool chain, a CC++ tool chain to do the rest of the work, all that has landed now upstream. So in Binitl's 228 we got the RISC-V 64-bit support, GCC 7.0, sorry, onwards we have the support, G-Libc 227 earlier this year got the 64-bit port and then the 228 which is the recent release will have the RV32 port, Newlib 3.0 which was also released earlier this year. It also has the RISC-V support, so Newlib is required if you're doing bare metal, so this is a C library you would use for bootstrapping your tool chains. Kimi is very important, it's a very important cog in the wheel when you don't have real hardware and 2.12 actually got the full support for emulator, for RISC-V, word emulator actually in upstream. GDB currently in 8.2 which was released very recently, there is support for bare metal that has been upstreamed. So if you are doing microcontroller stuff you can build all your tool chain upstream from various upstream releases. For Linux actually there is a fork that we have currently on RISC-V.org, github.com slash RISC-V and you'll see there are lots of folks there and GDB is also one of those folks that we use. Hopefully this is being upstreamed as soon as and maybe next time when we meet it will be all upstream. Bootloaders, Coreboot actually got its support very early on in 2016 I believe, all the support for RISC-V was upstream. Uboot has recently accepted the word board support upstream and the proxy kernel and the Berkeley bootloader are actually the original bootstrap bootloaders for RISC-V spike platform. They are in a way used even to bootstrap the Linux kernel right now. They already were upstream and they are already available on the RISC-V github. So with kernel 4.15 was the first time when it got first user space ABI changes into kernel and the basic support. Drivers were not all there and since then it has been trickling slowly and 4.19 which was released recently actually contains the drivers for communal word board. So you can build the kernel from upstream and boot on QME if you use the word board as an emulation platform. So there are major contributions that happened from Berkeley and sci-fi and Andes to do all this great upstreaming work over the past few years. So now moving on to other operating systems these are kind of like the basic high level components that we have that you would require to bootstrap other softwares. And Zephyr is actually one of the RTOSs that is hosted on the Linux foundation. It was one of the first RTOSs that got ported to RISC-V and there is a sci-fi high-fi one board which basically was the initial target along with the QMU emulation for RISC-V32. And then since then there have been a few more boards that has been added. So 1.13 was the first release for Zephyr upstream and that got the RISC-V port. So now if you download a standard Zephyr release SDK you would find RISC-V supported by default in there. It is one of the supported architectures. So distribution port so moving on to primarily the Linux ecosystem distributions. There are a few things here. For example there is a understanding so most of you might have attended this morning's talk about RISC-V org and so there has been an understanding. So this organization basically is there to steer some standardization of efforts around RISC-V. And there is an understanding with all the distributions and RISC-Vs to basically adopt RB64 GC as the general ISA because we talked about there are so many variants that are out there but this will be a generic binary distributions could use and it's a understood or I'd say agreed upon ABI to be used. So a portable software can be written. So you'd see there is RB64G and C. C stands for compressed instructions. And those of you familiar with the ARM or MIPS these are the thumb equivalent of ARM instruction and MIPS 16 equivalent of MIPS ISA. And these are by default so you can get best of both code compression, code density and performance. The embedded Linux distributions that will cover a few of those. They do have RB32G port as well that ABI variant is now upcoming now that G-LIB C port is upstream. We would see that there are distributions that are already now supporting that as a possibility. I'm not expecting that in desktop or server distributions to be the default but embedded distributions and frameworks they will still have these options. So if you're designing one of those boards you might want to look at some of those infrastructures. So Fedora has actually done a lot of initial heavy lifting and they have actually a dedicated page up there now for which lists actually all instructions in detail how you could install Fedora on RIS5 or you can use an image to bootstrap into an emulator. So they were releasing certain phases of bootstraps throughout last year and the final bootstrap was finished this year, earlier this year which means that now RIS5 is like any other architecture supported in Fedora and the Koji build form which is the default build form for building the packages in Fedora is actually churning out the RIS5 RPMs like other architectures and you can see Fedora 29 and Rohai which is their kind of like the bleeding edge Fedora. They all the packages in there they are now had they have moved over to build using their standard Koji build system which is a great achievement for RIS5 within a few years to be one of the main supported architectures over there. Currently it supports the high five unleashed board from RIS5 from sci-fi and also the Kimi which is emulator so you could have images installed either on Kimi or also on the high five unleashed board. Debian has also done a lot of work and I'm just pointing to the top of that wiki. I encourage you to go there read about it. I've included this one slide here one graph here that is from from Debian packages how many packages are how many percentage of packages are building for various architectures and it's not a very high definition here but as you can see RIS5 is somewhere you know hovering around along with X32. So not bad actually you know it has left behind several other architectures that has been around for a long time. So what this tells us is you know the the porting effort is actually ongoing at an accelerated pace and more and more packages are being ported as we move into 2019 and that's actually a great sign. Fedora does have I think the cross-bill system currently does have few caveats there so it doesn't have the tool chains building for cross-bill system as of yet I think they are but they do have a way to do it and they have documented it really well on this wiki page. I tried it it works so if you are working with Debian you know you are no less behind any other distribution if you are considering considering RIS5. They do publish images which are actually from a sign developer. Minimal images are there and then you can boot strapper system from there on and the standard ISOs are not there yet. Open embedded so I'm also an open embedded developer so I've been involved in doing port on open embedded quite a bit so I can give you some information on open embedded as well. It was one of the initial distributions that was actually being uh ported to run on RIS5. Back in those days you didn't have QMU you had the spike emulator which is actually a spike simulator very slow but very good for you know accuracy and hardware simulation. It was sort of a fork and it never merged back for a few years until last year when we started to work on it to upstream all those changes so a lot of work was already done there and so we started for upstreaming all this all the all the work from the fork into upstream and because the way open embedded is organized we could actually create a separate layer and then we could use the forks like glibc fork and gcc fork and pinutiles fork and everything and then take all the core changes and still bring them to the core but have the tool chain boot strapped from a separate layer so that kind of helped to to do the the upstreaming effort fairly early on while you know other distributions were probably doing some work but primarily were pushing the changes upstream and eventually today after like you know the 2.6 release which is going to happen there is actually all the core changes are upstream there are hardly any changes that we are carrying in that layer except the BSP layer changes which basically defines you know meta RIS5 related tunings and options and machine definitions and things like that other things are already upstream so currently it does it supports emulator and it supports the sci-fi freedom u540 board you know and you could also build the cross SDK so you know the the power of open embedded is that you can build so many artifacts to do different kind of developments so you could build a cross SDK if you're building things in a cross environment or you could build a on device SDK which means you build an image which has all the tools and everything in it you boot it on emulator or you boot it on on the freedom board and you can develop your software so this is currently working really well and you could also generate bare metal rv32 SDK so we talked about Zephyr and the bare metal SDKs are useful actually there and the SDKs that Zephyr project is generating actually is using open embedded Yachter project to do the SDK work so currently the 32 bit tuning especially from the bare metal perspective that's in there and the rv64 for a hosted environment like Linux is also in there so currently actually we are also working on trying to add continuous integration so we can kind of run builds on when people summit patches against meta v5 for example we have few challenges there in terms of because the build times are too long so we have to have a dedicated CI loop somewhere and so we're still figuring that out we do have the infrastructure in place we don't have machines to run it as of now so hopefully we'll figure out something by you know next time so open embedded builds a whole lot of packages cross build packages and as you can see we run through the world builds almost a few maybe three days a week and currently there are a few packages which are failing obviously you know the reason being they haven't been reported or there are other compile related problems or other issues in there but if you consider out of 8,000 9,000 packages 38 failures you know it's not that bad as far as I am concerned but there is some work to be done in there especially like you know supporting gstreamer and some of the key packages that are currently not compiling so this is a snapshot from the we could run tests actually in a cross environment in yachto so basically when you have a package change it can actually run the full test run in in an emulator so that is also currently working for risk 5 emulator and currently we have failures in xorg test as as of recent so we need to look at those but there are several other tests that we want to enable on those so you can have a lot more auto tests that are then happening automatically build route actually build route has done a great job of putting the changes recently I think the 64 bit port went in it was accepted and there was this fork we had on risk 5 github handle and the risk 5 start branch actually describes how to build build route for 64 bit emulator and very recently as of I think yesterday or day before the 32 bit port was submitted for Linux to build route so actually that's a great news as well and there is also a article actually that is published and I think you can find the links over there to that article which describes the step by step procedure if you want to build you know the build route for risk 5 so if you are a build route user go ahead and try it out and you know interact on the mailing lists if you find issues just the build route mailing list should be able to help you out so now on to some of the ongoing efforts this five llbm actually most of the support is upstream so you can build actually a llbm compiler but then there are few patches few features that are still in there that are still being upstreamed so if you go into this repository it lists actually all the patches that are being rebased and then being sent upstream for review and merge so I think the base support is being there is a big step so these are basically enabling other features that actually is a more of incremental changes that are going to go in there so that's a great news and similarly the lld is the llbm linker and that port actually has been also submitted upstream I'm not up to date as to whether that has been accepted yet or it's still under discussion muscle muscle is another sea embedded sea library and it has been ported to risk 5 and it has been actually recently submitted upstream as well and you can see the discussions or basically it is planned for the next release there are a few discussions currently happening between the developers and before it gets submitted but I'm hopeful that very soon we will have the muscle support as well upstream so what this means is that we will have an embedded library along with glibc and this will also make sure that you know we have projects like openwrt actually be able to build from upstream openwrt does have a port by the way for risk 5 for I couldn't cover all that here but even the openwrt port is already published and they have submitted the port completion emails to risk 5 mailing this so that's also a great news openocd so moving on to some of the jtag stuff if you're doing embedded development there is a risk 5 out of 3 support it hasn't been upstreamed so they but the port kind of worked and it probably might need some refinement if it needs to be submitted upstream and I think that will be something that I think some of the openocd efforts would take over but if people here are interested you know there's room for improvement there the linux os port or the linux application gdb port as I mentioned earlier is not upstream yet it's available on the fork though and so in due course I think that's also going to go upstream similarly there is ufi I think the standard body has accepted there is 5 into 2.7 I believe version of the specs and there is some work in grub v8 node jas I think all of these there are all the ports are available on some of these ports already available on risk 5 handle and in some cases they are fully functional ports in some cases they may be done on a previous version of package and you know it needs to be first forward ported and then upstreamed similar for golang and others are also in the same category so contributions so I did this little search and on linux kernel so you can do some get munging there to find out the unique contributors and as you can see in 4.18 risk 5 shows 31 contributors so we need to take this number off so you know please join and start hacking on risk 5 and submitting more and more patches hopefully you know this number will go up rapidly and we'll have a lot more to report next time so if you want to find out more it's a very good page that is maintained actually on risk 5 or and a lot of stuff that I have here is also reflected over there in different form so please check there all the time that page keeps updating as and when the upstream effort is going on and things are moving upstream there are also a page for you know various risk 5 course because several people are designing course based on risk 5 so this page is very important and very interesting from that aspect that you want to know more about you know who all are designing risk 5 course and what's available for you to use go in there and yeah check for this so so linux kernel actually has a separate mailing list now it's called linux risk 5 so if your discussions around risk 5 want to participate use that mailing list so there are more things more ways you could get involved so there is still standards work happening you would see that the specs are being discussed and proposed and finalized ABI for example the embedded ABI is still under works and so you know you could influence and provide your inputs there and we could improve you know the linux distribution port so I covered a few of those there are more that can be that are being worked on to be forward ported and then the existing ports for example can do better there are loose ends that you know you could support due to to be fixed in the distributions that are already supporting it and port more software packages to risk 5 so you know if you are maintaining a package or using or developing a package that is not yet ported to risk 5 go ahead you could basically currently you have everything to to start pack is porting those packages to risk 5 most of the software is upstream right so you really don't need folks upstream first strategy is actually core to the risk 5 software development community and most of the software that's already upstream you can participate as usual if you have a gcc patch participate in gcc community llvm participate in llvm community there is no specific involvement from risk 5 community that you need to have you might want to cc them that's fine but most of these discussions are now taken upstream like any other architecture so there are specifics under github risk 5 handle so these are some of the in progress ports so if you see a fork of something there then you know that it is in progress and some of the projects are actually upstream there itself for example you know some of the projects i mentioned over there like the architecture layer for open embedded or the bbl and all those and spike for example they are those are basically the upstreams for those so there's a software discussion mailing list feel free to join that and risk 5 on free note actually it's a channel available if you are on irc and there is a stack overflow tag as well that you could use there is a buff today actually so at six o'clock this is hosted by the folks from risk 5 and sci-fi and then western digital who are actually at the forefront of risk 5 architecture today in terms of hardware and software so if you want to learn more in depth you know some of other stuff that you have questions for encourage you to go there they're very knowledgeable people and they'll give you like you know the latest and details that you might be seeking if seeking for so i just want to leave with this parting thought before i end and then open for questions seats have changed so um some so many years ago you know there was this mail that was sent which was describing i wrote this small os and then you know you want to play around with it please go ahead and today that project is 22 million lines code 14 k plus contributors and it's actually the most successful open source software project the key is open source right so in the software world it did change the paradigm of software how people thought about doing software and all of you who are sitting here are actually the people who made this happen so i believe that history tends to repeat well usually when we forget it but this time to build upon some proven efforts that we have taken in the past so this could be a history repeating for hardware a open source hardware so with this thank you very much for listening to me and so if there are any questions i'm open for those is it micro coding so i actually don't have much information into this area but it's a s it's a cp implementation that is based on risk five i'm not sure if it is microcoded though it's a pure design yeah paul might have more details yes so question is have you tried building open embedded SDK with new lib the answer is no we haven't yet tried it um well in a way yes so um we've tried the bare metal bills for open embedded that did not use nearly as per say as a library but it used it to bootstrap it so in a way yes but the new ways that you probably think where we add nearly as a library option that hasn't been used so it has been used just to bootstrap it yeah because um it's primarily done for zephyr and zephyr doesn't need any libc they have their own yes sir so can you repeat a question uh so development box costs um uh just below thousand dollars um but keep in mind it's a very high-end board um and it's first of its kind right so um it's just gonna go down as we kind of like have more iterations of those boards and currently i think it might be a little on the higher end of the pricing and i'm hopeful that you know there are more boards coming which will be basically affordable and i see that happening very soon more questions okay so going once twice no more questions okay thank you sold thank you very much