 All right. So welcome, everyone. Thanks for coming. You heard about RISC-5 this morning from Jensup, and so I'm going to talk about the RISC-5 port, architecture port, actually, on Open Embedded. So where we are, what we've done, and where we are going, and what are things that are still pending. So pretty much introduction a little bit on both projects and what works. I'll try to give a demo if it works. And then what we are working on right now and what are some of the items for future. So RISC-5 is a free ISA that started in Berkeley. There are others like Open Risk and MIPS and all, but RISC-5 started off as a clean slate. And it's not called RISC-V or something, it's called RISC-5. Genealogy goes from RISC-1, 2, 3, 4. Likewise, this is RISC-5. And it's licensed under a BST license and started in 2010. So there were other architectures that were available at the time, but they were lacking in few things. And they were also copyrights and other stuff that were causing issues back then. So this started as a clean slate in 2010. So by now there is a foundation, RISC-5 foundation that manages the activities around development and the ISA and specs around RISC-5. They also have a GitHub handle. You are welcome to go there, they have several projects and they see a lot of projects there that are being ported to RISC-5. And then eventually they make upstream and they still manage them for a while, but eventually once they are upstreamed then you see less and less activity on these projects, more and more activity upstream. There are several commercial adopters for RISC-5 right now. It's still in very early stages, but you've heard of low-fi boards, high-fi boards. So there are boards that are coming out which are based off of RISC-5. Yachto and Open Embedded. So it's actually an infrastructure to create your own distributions. It's not one of the given distributions that you might know. You know, like we have Fedora, Debian and others. They are distribution with policies and things, whereas Yachto project along uses Open Embedded technology to provide that feature for you to be able to generate your own embedded Linux distribution. And Yachto project actually is not a single project. There are several projects underneath it with a motive to improve embedded Linux development experience. So they are contributing to several other projects under the same umbrella. It uses Open Embedded build system, as I said, and they enhance it, improve it, add new features to it. Open Embedded gives you a lot of flexibility at the cost of some learning curve. But this is required in embedded systems. Many times you want a possibility for you to customize things. The beauty of this is that it gives you a horizontal scale. You have the same infrastructure that can scale from a very small, you know, a system to a very large system, large in the sense of packages and features that you want to put on the box. So right now it provides development environment, workflow tools. Test is big. So you can run other tests. For example, there is a lot of work happening in this area. And SDKs is another stellar feature which you can distribute your SDKs to others to let them do development on top of what you would have put together as a platform. Layered architecture is actually very powerful because many times you have this monolithic systems where you might be needing only a handful of packages, but you end up, you know, with a big blob of thousands of packages. Even if you don't want them, you have no big choice. And in many cases it's fine if they don't interfere with your work, but most of the time that's not the case. With layered architecture, we can actually leave out certain pieces that we don't need. And you can add specific pieces that you need into your projects. So that gives you more targeted packages and leaves out a lot of unused code for you. So bringing all this power of open embedded to a new architecture like RISC-5 is fun, so we're going to go into that and just talk about that today. So feel free to ask questions or comments, anything you have in between, and we'll take it there. So what we've done, we talked about layers, so we created a layer. It's called Meta-RISC-5, and this is actually architecture layer. Right now it has an emulator machine, and there might be more reference boards added in the future, but right now it only has an emulator for a machine. And it has additional packages that you have to kind of either fix or tweak to get it working on RISC-5. And if you go there, look into the layer, there aren't very many left anymore. And we'll talk about that as we move. Six months ago, it was not so the case. So the setup is... This is a minimal setup I've mentioned here. It only depends upon the core layer, so you just check out the core layer and then check out the RISC-5 layer, and then set up your environment, and you're all set. After you have set it up, you select the machine to be Kimu-RISC-V64, and off you go. You can start your build. So it's just these three steps. There is only 64-bit Kimu right now. 32-bit is not yet supported. There are some gaps there. For example, G-Lipsy doesn't work yet. So there are portions missing. As far as 32-bit port is considered. So while you're building for the first time, the build might take a little longer. So I just mentioned that here, so you can have your lunch. Coffee will not be enough. And once you have the image built successfully, you can do both user-level, user-mode networking as well as normal tap-based networking. Both of them work. So Open Embedded provides infrastructure to run QMU, and all those options that you are required to supply are actually very nicely abstracted underneath these tools called Run QMU. And it runs in the same environment where you build it. It uses that environment to extract out information about your architecture, your machine, and then uses that information to search for images in your deploy area and then run it. So essentially, from user perspective, if you just run this command with no graphic, which means you want a console-only image, then it comes up with the images. So you don't have to worry about all the options you need to pass. Yeah, you could modify it if you want to. So all those are actually parameterized in the machine configuration file. So you can change values if you want. For example, the default memory is 256 meg. So if you want to make it 2 gig or something, you can go in the machine.config and change that to whatever value you would like to have. So if you're running in user mode, the port 22 is forwarded to on your build host. And you can do local SSH using that. Or if you use the normal tap-based networking, you can directly SSH into it using a specific address 192.168.7.2. We'll talk about that a bit later. So porting status. So right now, if you build it, these are the key components that I've listed here and then listed their status. Kernel, actually, I'm building from Linux RISC vPort, but actually the support is all upstream. So I haven't yet tried 4.16 RC4, but it should be buildable. So 4.15 is when the support was upstreamed. G-Lib C is all upstream. And in Open Embedded, we are using G-Lib C 227. So we carry no patches. It's just using it from Open Embedded Core. GCC is in the same way. There are no patches. It's in the core. B-needle is in the same way. GDB. Well, this is a little obsolete information here, but yesterday it was accepted upstream. So this slide is a little obsolete. And so it's still using RISC v-needles. QMU is again, it's using RISC vQMU, but QMU support also got accepted last week upstream. So the next release of QMU will have RISC v support out of Vox. So as you can see, the tools, major tools I mentioned, two of them are already upstreamed. So basically everything that's on that slide is upstream, except the RISC v tools. And these tools are essentially, we'll mention more about those, but these tools help to launch the kernel, so you can think of them as, you know, BSP tools like bootloader tools. So what works? So there are several reference images in Core, and so most of the command line, or most of the non-graphic images, they are buildable and they run. So Core image minimal is very small, just, you know, console utilities and library. Then you have the base image, which has a lot more like networking stack and things like that. And then there's Core image full CMD line, which is essentially a full kind of serverish image. And on top of that, the SDKs equivalence of those work too. So you could generate an SDK for any of these three images. You can generate an extensible SDK out of these images. So if you are an open embedded Yachter developer, you probably know that extensible SDK is a new feature in open embedded where you ship the open embedded build environment as SDK. And it's very powerful, it's extensible because generally SDKs are pretty static. You give your SDK, and suddenly there's a dependency somebody needs, and so either you regenerate the SDK or you have to create that dependency in your package. Extensible SDK kind of helps you there because you can just add that dependency right there and extend your SDK. So it's very powerful from that aspect. So init systems. So we have three init systems in open embedded, all three work, sys5init and systemd and busybox. All of those you can pick and choose, and they all work with sys5. As I mentioned before, you could use networking, you can run QMU, and both user mode as well as tap, both of them work fine. So a little bit of booting in QMU. So the kernel, so the way this five boots up, they have something called proxy kernel, and what it does is it bundles a Berkeley bootloader, BBL, as kernel as a payload into that bootloader. So what you will see is when we run QMU, we give BBL as our command line to kernel, or we call BBL as our kernel command line to QMU. The reason for that is that the proxy kernel basically provides that as a payload to BBL. So I've provided a link if you are interested to dig further into the sys5pk recipe, how it is grabbing the kernel after it's deployed, and then generating a BBL, which is basically your bootable kernel in QMU. And the root of s is normal, normal root of s that you generally have for other QMU images. It's exactly the same. There is nothing special about that. So when you boot, so this is a couple of screenshots I've attached. They are very blurry, but I can probably show you... So here you can see it's booted right now. So if you just launch it with no graphics, that's what those screenshots are showing you. And it's launching the BBL logo at the very beginning, and then you get to see the login screen. And you might have observed that there are two login screens. It's a bug in the serial driver that's interfering with... with early printk. So that's a known problem. So we talked about SDKs, so I thought that I actually generated an SDK and I've installed it. So while it's working, I'll just show you that. And so it's installed here, and I've set up the environment. So if you see, you can see that right now, it's actually showing the CC variables and all those from the generated SDK. And then I have a little script here, which basically builds a hello world and then transfers it over to the emulator. And then we'll see whether it runs. So it just copied it over. And let's see if it is there. So we can see it. And so that basically gives you a full cross build environment where you can build your apps in a cross environment using the SDK and then transfer it over to emulator and do your work, build it over there. So now I'm going to move on to some of the work in progress. In other words, what currently doesn't work and is being worked on. So what we currently have is, as I mentioned earlier, graphics. It doesn't work. And as you can see, when you build one of the graphical images, it ends up in building G-streamer. And then G-streamer actually throws this error at you. You could not detect architecture. Don't know whether it supports unaligned access, please file a bug. So clearly there is some work to be done in this area. We haven't yet doubted deep into this. So we did some patches. There is a potential issue in GCC as well where when you enable p-thread option, then there is an internal define minus re-entrant, which seems to be missing. This becomes a big deal when you have other tools trying to detect threading support. And they use this variable, this define rather, to validate whether threading support is working on a given tool chain and architecture. And without this, it just comes out to be not supporting threading. So I think there was some discussion on the this file mailing list on that, but there hasn't been much traction whether we need to fix it or not. So probably we need to delve more into it as we move. So LT-TNG, again, when we build this development images and larger images, LT-TNG and other profiling packages, they get included. And currently LT-TNG fails to build, cannot build unrecognized architecture detected. So I hope that doesn't remain the case for long. And GCC sanitizers, they don't yet build. And so that's also work in progress probably. We will have some support that in GCC 8.0. So in OpenBerid, auto testing doesn't yet work. There seems to be some issues with how it connects to Emulator. And it seems to be that there might be some misunderstanding between how the RISC-5 Emulator is showing the consoles to the KME testing framework that's in OpenBerid. So I've included here, if any of you are interested in trying it out and fixing it, sending patches, then this is how you could basically enable your test image and then you can reproduce the problem. This is actually very helpful if we get that fixed because then it enables a lot of testing, runtime testing for the packages on Emulator. So a lot of bugs can be found and fixed once we get this going. So we've supported, actually all the support that is needed in CoreLayer is actually submitted upstream, all the patches. Some of them are already applied, some of them are in-flight right now and hoping that by 2.5 release or Yachto in April 2018, we might have all the core pieces that are required to build RISC-5. And obviously you need to have the BSP layers, meta-RISC-5 for now and then maybe further board-specific layers as they develop. So cross-prelink, we use cross-prelink not only to support accelerated loading, that's one feature of cross-prelink, but we also use it to help us detect some library dependencies during cross-pills because LDD cannot be used. So we use pre-links RTLD to do that detection and currently what that means is pre-link has to understand RISC-5 architecture as a machine for it to work, even in cross-environment. So but there's a patch, the porting patch is already submitted upstream for cross-prelink to be included. Then libatomic ops support is actually upstreamed already. We don't have yet a release of libatomic ops that is being used in open embedded. So we are actually carrying patches for libatomic ops in meta-RISC-5. Whenever the next release happens and open embedded upgrades to that release, we will basically be able to throw away these patches and then just move to the upstream releases. On the same lines, there are a few more libraries which are carrying RISC-5 support patches, LibFFI, NSPR, LibGPGR. So those are few of, actually probably the only ones which are currently left as far as OECore is concerned. The good thing is they are carrying the local patches which are already submitted upstream and I'm hoping that they will get included in the future releases of these packages as well. So some of the future things for the architecture in open embedded, if you want to make it core architecture, there are things that are missing. For example, GDB, well, it is upstream now, but likewise muscle support, you know, there are patches already available. They are being considered for the next release of muscle. Hopefully, we'll be able to get them upstreamed into muscle next release. So muscle support, it is a core infrastructure in open embedded, so we would basically require Golang to work as well. And we need the KMU support upstream as well, which is already accepted upstream, so hopefully the next release of KMU will have, you know, the needed support for RISC-5 in upstream as well. So there is a hackathon going on today and they are actually working on the sci-fi freedom U540 SOC based board and the plan there is that we would like to have open embedded support at BSP as one of the first, you know, real boards to be supported on open embedded. So hopefully, you know, in the hackathon, some of this will come out and probably will have a few patches done for supporting that platform directly using open embedded. 32-bit RISC-5, I talked about it. We need 32-bit G-Lib C support and I guess other major tools like GCC and everything they do have 32-bit support already in there. So probably once we have 32-bit support in G-Lib C and muscle, maybe either of those, or both of them, even better, then we'll be able to support 32-bit user space as well along with this one. So here are a few RISC-5 resources. If you are interested to work on RISC-5, there's an IRC channel which is pretty active on FreeNode. So feel free to hop onto that and ask questions if you have any. And there are several repositories on GitHub on RISC we handle that are very interesting and if you are interested in contributing to some of those, then you are welcome. And there are mailing lists. They are not very high volume right now, but one of them would be interesting is the SW Dev. For example, that a lot of software issues are being discussed and then questions and answers. So it's in very early stages. It's a time where you can make contribution to the ecosystem, how they define the various building blocks. So it's a very good time if you want to influence that to go there and participate in those discussions about various things like how directive structure should look like or other pieces, how the multi-lib should work or should it work at all, and those kind of questions are being discussed. If you are interested in Yachto project resources, finding out more about it, I've listed a few links here to the Git repositories for Open Embedded and Yachto project and also link to the main website. So there's a new newly launched website which probably is very informative now. And you can also look into Open Embedded Wiki or their IRC channels as well, Yachto and OE handles on FreeNode. And mailing lists, if you're new, feel free to contribute to Open Embedded or to any other layers that are on top of Open Embedded for coding RISC-5. So I think I'm open for questions now. Thank you for listening patiently. Yes, sir. Okay. So I think the question is that people have, why RISC-5? So I think if you look at software in the past 20 years or more, how it has become so prevalent. So today you are talking continuous delivery, continuous integration. You commit the code and you want to see it in next hour deployed. There are projects like that. So it has achieved that level by becoming mature and all this actually involves a lot of open source software that goes underneath it. So what RISC-5 is trying to do is it's trying to give you an open ISA if you're a hardware developer who are developing some IP and then tools that you can then build on top of it. So you are not licensing. There are no needs for that. You can pick the ISA, add your IP on top, and then build a custom chip. On top of that, the tooling that's being added, that is actually very powerful where you can design a custom chip in a very fast time, turnaround time. So in this IoT world where all applications will be different, I believe that you can't solve everything in software. You shouldn't, right? Many of those are you might want to have custom hardware doing specific things. If you can have an infrastructure that can let you make a system within the costs of hardware systems, I'm sure you would do it. Similarly with software, what you're doing with software, your cost of free-spinning and changing are lower. So RISC-5, it could be something else, right? As long as it is an open ISA. So RISC-5 happens to be an open ISA, right? So that is why it is being picked right now. So it's not that it has anything specific. Obviously it has features that you want to have that were lacking in the other open architectures. It's not the first one, as I mentioned. Open RISC is there, right? That was already available. But it's missing certain pieces, like IEEE 758 implementation is not there, right? So there are the compressed instruction sets are not there. So what it is trying to do is provide you a modern architecture in a more open-source ISA. So anybody who is trying to invent or innovate on top of using hardware IP, they have a little easier for them. Thank you. Yeah, so I think the question is, if you customize, then what are the challenges of customization on software? So I think it is challenging if you change ABI, for example, right? So, and I'm encouraged by seeing RISC-5, like, foundation, take this and define it, right? So they are adding definitions as to how the ABI should look like. And the idea that we shouldn't be breaking ABI, you know, so basically having a system where, yes, you added more IP, but from software aspect, you may not want to add that as to your, you know, user experience. So I think it's a good idea. If you added more IP, but from software aspect, you may not want to add that as to your, you know, your basically your standard interface. You still might have extensions that you might want to add to compiler and things like that to take advantage of that. But it will not break your software, say if you are generating without your customizations, that software will still run on your system. But if you customized it and, you know, you want to run that on the older hardware and, you know, the non-customized hardware, that might not work. But if you recompile it, it might work. Thank you. Yeah. Right. Yeah. Right. So again, it's an extension to the question that previously we were discussing. Actually, there are actually four variants that are currently allowed if you look in there, right? So in a sense, there are four ABI's. If you consider map it to MIPS, there were much more, right? So the four ABI's are pretty much set in the tools and also in the kernel. So as long as you remain within the bounds of those four ABI's, right, that is the intention to go forward, right? And any extensions you might have are extensions on top of those. They should not be breaking the existing ABI's that are in there. So how you add those support into your tools, for example, you know, you are not going to submit a patch into GCC saying that, okay, let's change vectorizer to use my fancy extension. That's what I'm meaning here, that the fundamental instruction set still remains same, that the compiler uses to generate the code. You might have additional instructions that you want to use for those specific extended profiles. But fundamentally, if you were to build for, say, QMEaRisk 5, you can take that same binary and run it on your custom chip, and it will work, right? So you are able to reuse a lot of source code when you are customizing. A lot of the programs that are already available to you are reusable from that sense. So it's more of your building on top rather not forking on the side and changing the compatibility. Yes, yes, correct. So I think you should basically be able to... I mean, there will be M-tunes and all those things, you know, so you want to take advantage of instruction sets. So GCC will have pipelines and all those optimizations, which actually currently don't exist as much. So you could choose those, depending on what is your fundamental micro-architecture that you are customizing on top of. So I hope that, you know, if you ask me whether you can fork it, yes, you are allowed to, right? So nobody is stopping you from doing that, but that is not the intention. So the fundamental support that went into Linux, for example, defines the Linux ABI now, right? So that's your contract for future. There are no new additions that are going to come without, you know, being discussed in the community and being agreed upon, right? So it wasn't the case with MIPS, right? For example, people submitted their own ports and they did all bunch of stuff in there. Yeah, yes, yes. I think that's a great idea. I mean, the thing is, as I'm saying here, you know, there aren't very many variants available for that to kind of cause a pain right now, but something of that order is probably on the cards, right? When somebody comes up with a real chip that kind of have wide acceptance and has few additional things that you want to consider, and then you have an array of machines to support and all those tools, you probably might have these plugins or extensions that plug in into those tools. So it's pretty much on the cards at that point. Yes. I can't speak to that because, you know, I don't work for a company that implements it. So even if they have, I would not know. Yeah, I'm an open-source developer. Yes. Right. Yeah. So I think the question is whether BBL is the only bootloader or, you know, so BBL is one of the bootloaders right now. So it is used to bootstrap, actually, FPGA and things like that. But there is work happening on Ufi and work happening on Uboot. And actually, you know, you are welcome to contribute to Uboot a lot. So there's a hackathon going on. And I think, you know, if you step up there, you know, they would be happy to kind of brief you on what they are doing in terms of bootloaders. But certainly it's not tied to those bootloaders. Those are just ones that are available. The reason for that is that there is a spike simulator framework from Berkeley that was used before, you know, QMU and all this came along. And the way to bootstrap the system was, you know, using BBL. So that's just, yeah. So more questions? Yeah, so I think there is a talk whether this will be taken up by Race5 Foundation. Okay. So they might maintain it. Don't know yet. I think it remains to be seen hopefully that, you know, it will find a different place. It's just seated there right now. Eventually, idea is that, you know, as I talked about making it first-class architecture in open embedded, we might not need it per se. You know, it might just be supported out of box. So, but yeah, good question. So more questions, comments? Okay. So I hope you enjoyed the talk and, you know, you go home and check out. And, you know, I'm expecting patches from you on my GitHub handle. Thank you very much.