 Hello, everyone, welcome to Rix 5, both background, background, Cascadian will be presenting this session. Thank you. Hello. So great to see a pretty good turnout. I am mostly a RISC 5 jury leader. I don't have a huge amount of background in ISA development or anything like that. But I'm pretty excited about the prospects. And I wanted to get together and chat about it with other people. I'm trying to leave the IRC session open on here. So if anybody sees a question that can be brought to my attention, feel free to highlight vagrancy in IRC on the DevConf 18-Z room. And then we'll try and get more remote participation engagement. Basically, mostly I don't have a lot of slides prepared for this at all, really. But I'm going to go over the Wiki page on wiki.debian.org slash riskv, or RISC 5, as it's supposed to be pronounced. So RISC 5 is an open source instruction set architecture based on established reduce instruction set computing risk principles. So this is kind of a more low-level opening and hardware at the processor level, which is pretty exciting. We've made a lot of progress on RISC 5 just in the last six months. So this is a fairly new port. It's currently in the Debian ports repository. There is a 64-bit variant of RISC 5, is basically what's being targeted initially and quite possibly for the foreseeable future. The status is roughly, it's been hovering at about, let's see here, I believe it's been hovering around 80% complete, give or take a little, for the last several months, which is pretty impressive for a very important port. A lot of thanks to the people who've been doing a lot of work on bootstrapping to make that a lot easier. There is the riskv.org website and upstream mailing lists. The tool chain support is pretty widely. Almost all of the major tool chains already have support. The notable lack is GDB. If there are any people interested in doing GDB hacking, we would love to have people working on the RISC 5 port for that. There's actual real-world hardware in actual real Debian community hands, which is pretty exciting. The high five unleashed is the main board, which was unveiled earlier this year at FOSSTEM, if I remember correctly. There are, of course, future plans. We'll believe it when we see it. But there's a lot of work going into that, and look forward to it. And for people who like tinkering with PGAs, there are also implementations for that. One of the main blockers for the Debian port, let's see. One of the main blockers for the Debian port was fixed recently, and that is getting support into Stable's dPackage to acknowledge the existence of the RISC v64 architecture at all. So that opened the door for several key packages. The Linux package now has Linux libcdev. Glibc was able to be uploaded and binutils. So a lot of the core tool chain is already available no longer requires a porter to do a custom build and then upload that to Debian ports. They can just rebuild a source package from the official Debian archive, simply adding RISC v64 binaries. And there's also, for those who don't have access to hardware, keymuse support was recently added, and I did some nudging to get that into Debian a little earlier, which is maybe one of my more significant contributions, though I mostly just nudged patches to happen quicker. And very, very recently, mostly because of the dPackage change, you can actually even use regular old Debootstrap to at least get a minBase variant without having to pull in the unreleased portion of the Debian ports archive. And that's probably about all I really have going on right now. So if you would like to chime in or bring up some ideas, issues. Yeah, hi, this is BDL. One of the things that's sort of important to understand in RISC 5 space is that while the instruction set architecture is a completely open architecture and an open design, the actual implementation of that into a particular chip may or may not stay really open and without binary stuff, I have one of the sci-fi unleashed boards with me. If you haven't seen one before and you'd like to see one up close and personal, I'll be happy to pass this around as long as I get it back. This one was expensive because it's one of the very first ones that was sent out. But the problem is the sci-fi folks have happily pulled in intellectual property from other places to get to where it's a complete chip that does useful things. This is a quad-core 64-bit processor with reasonable performance for playing around and doing Linux stuff. But the chip's implementation is not particularly open. It has sort of the same level of documentation about how everything works that other people's processor chips have. And it's based on RISC 5, which makes it a reasonable platform for doing RISC 5 development. But this chip itself is certainly not transparent in terms of all of its content and how all of its peripheral bits work. That's why my personal interest is sort of leaning more towards, in the long-term, can we actually get to the point where we have implementations that are completely open and that are either the chips are being developed by people that we know and trust and are willing to sort of collaborate with on future development or in some way we end up with chips where we can actually sort of trust what the content is all the way down to the sand. To that end, I've been playing around with some of the FPGA targeting stuff and I have with me one of the Digilent boards that's the default target for use with the low-risk version of RISC 5, which is another FPGA targeting thing akin to the rocket things that you mentioned in the Wiki. Folks, want to look at that board you're welcome to. This is a relatively inexpensive board. I heard someone talking a couple of days. You were talking about actually targeting a lattice part with a completely open tool chain. I would love to hear more about that and I have it in my head that it might be really, really interesting for us to find or pick some or make some board that has a suitably large suitably fast FPGA that we can target with a completely open tool chain to not only collaborate on making a devion port that works better but maybe in this community there's enough enthusiasm that we could collaborate on a chip implementation that was completely open too because I worry that the existing FPGA targeting communities that are trying to do completely open things are right now sort of silos. They're each working on the things they care about and maybe some place like devion is where some of this could come together and we could have a larger, more collaborative approach. Anyway, that's enough for me. Yeah, yeah, D-Dale made a great point that there is a piece of these chips that is open but there are other parts. Although to sort of play the apologist here, I think it's great to see any major component opened and it sort of creates the, it sort of breaks the chicken and egg problem and gives you something to hang all of their buses on top of and all of the other chips. So I'm a big fan of incremental improvement and so in that sense, I think it's still a great step forward but yeah, there are some currently not free components that are attached to the RISC-5 chips. Anybody else? Has anyone in the room been running RISC-5 port or tried to run it besides V-Dale? So what's back of these boards so far? Right, the Hive-Hive Unleashed has about eight gigs of RAM. I think a processor that can run in the 1.2 to maybe as high as 1.5 gigahertz range, quad core, they don't have much in the way of IO. So they have gigabit ethernet, but your typical dev board connect a whole bunch of just about anything to it. So yeah, so I didn't bring it because it's too big and too heavy to put in a carry-on bag but one of the things the Sci-Fi folks collaborated with Micro Semi on is there's this huge expansion board for the Sci-Fi Unleashed and I have one of those too and what it basically does is extend the, it's kind of open but seems weird to me, serial interface bus thing off the processor through a big chunk of Micro Semi programmable logic to implement the things you normally expect to have, PCI, all that kind of stuff and that board has a lot of IO and the ability to hook up real disk drives and video cards and stuff like that but the Sci-Fi Unleashed board by itself, it's basically a cat five connector and not a whole lot else in a Micro SD slot and not a whole lot else that seems useful. Right, Merkur from IRC was talking about some of the FPGA implementations noting that the ICE-40 series is probably too small to actually build a RISC-5 chip that's Linux capable. Project Trellis is a similar FPGA bit stream that looks promising, targeting the ECP-5 which would probably be large enough to actually run Linux I'm inferring so it sounds like there are some options. I am interested, it sounded like there was somebody in the audience who actually had experience doing at least one of the FPGA implementations using the Debian tool chains, is that correct or did they not show up? Cause I talked to somebody briefly about it and I'd be really curious to hear. Sounds like they're not here. Okay. Oh, please grab a mic and. Okay. I accidentally have the ICE-40 board I mentioned on the IRC and yes, it doesn't run some kind of Linux or those kind of huge operating system on it and mostly can just run some kind of bare metal program that blinks some LEDs or those kind of stops and the open source Torch and the author of the open source Torch and Clifford Wolf is actually working on reverse engineering some side links, AC something FPGAs and maybe one day when the reverse engineering process is complete, maybe we can have the implementation that is capable of running Linux that day. I guess there's a org.org links to the status of the free FPGA tool chains, anything else? Anybody kind of interested in getting involved, cutting their teeth on helping with some of the porting work? There's the DebianRisk5 channel on your typical offset.net server for IRC. So which hardware is currently used for build demons? It's mostly a bunch of Kimu virtual machines emulating the hardware, so there may be one or two of the high five unleashed boards just to have at least one bare metal or actual physical implemented Risk5 board, but they're mostly running Kimu virtual machines. So that might possibly introduce since it's such an early implementation, there might be bugs in the Kimu emulation. I'm not totally up to speed on what those might look like, but yeah, that's definitely a blocker for inclusion into the proper Debian archive. Yeah, it's not clear to me that we're anywhere near actually putting Risk5 support in the main archive, and I've been involved, as those of you don't know me, I personally was involved in starting five of Debian's ports back in the day, and so this is something I spent a lot of time thinking about, certainly until there's sort of generally available larger volume hardware that average users could run, pushing really hard to have this be a release architecture doesn't make much sense. Having said that, I know at least one company that's trying to figure out how to build a laptop design around the Sci-Fi of Unleashed, I think mostly to sort of prove to people that this is a credible thing to want to do. I'm personally, as I said, very interested in driving forward towards a nicely performant for something like a laptop completely open chip design. I was joking earlier that putting low risk on an FPGA board I could do something like put it in my wife's greenhouse or the temperature sensor to track what's happening out there. I don't know how long it will be before people think it's amusing to actually try and run something like a minimum Debian install to do useful work of one kind or another with risk five, and I certainly don't want to hold that back, but right now I also believe that almost everything in the way of building is being done in the QMU environment, because I think it's actually faster than building on real hardware right now, particularly if you got a really fast server to run it on. But I do know that there are a number of people actually running Debian on sci-fi of unleashed boards every day, and I ran out of time before I came here, but I intend to put it up on the unleashed board with the expansion board and see if I can't just use it as much as I can to help bring all of that out and make sure things are actually working. I would like to share something that is not related to Debian or Linux, but I posted the link on the IRC that is a micro Python port to the Pico RB32 that is a very tiny and a small RB32 implementation, and I would like to say that it's kind of operating system because it has multitask support and it has hardware abstraction and those kind of stuff, so in some sense that is an operating system, but it's very tiny, maybe, just saying. Yeah, I think one of the risk five Debian people had suggested that the actual, the main advantage with the Kimu board is you can actually give it a lot more RAM for ability and you actually get a reasonable speed with the IO, although even on a fairly fast machine, the on a fairly fast x86 machine Kimu, it sounded like maybe actually got comparable performance to running on the real high five on leash board, maybe for different workflows, obviously it varies, but they're reasonably close, maybe a little slower on the real hardware, ironically, but hopefully that will eventually change. So what kind of work is pending to do? Right, good question. You can go to udd.debian.org, well actually off of the wiki page is a link to the bugs that are tagged. There are a lot of bugs that are just simple, trivial like one to three line patches that maintainers could really, if they just applied it, it would save the risk B64 porters, it's really an unfortunate name. It would save the porters a lot of work of just applying those patches, building it in a custom location, building it and then uploading it to Debian ports. So maybe how many people have a rough idea of how Debian ports works? Okay, so maybe even just briefly explaining that. So Debian ports typically has at least two repositories, one of which is just packages rebuilt on the archive but based exactly the same source, the exact same source as what's in Debian unstable. The other repository is where we put our ugly hacks and that's typically called unreleased. And in many cases, these ugly hacks are actually just small patches that really can't possibly hurt anything in the official Debian packages on other architectures. So it's just a lot of busy work. Every time a new version gets uploaded, the risk porters need to then upload a correspondingly patched version. So one thing that would be really helpful is if you do get a bug about this on one of your packages to apply those patches, I don't know how people would feel about a very gentle NMU campaign to sort of resolve some of those undeltwith bugs. Fortunately, most of the real core blockers like the Linux libc and glibc and binutels have recently been patched and uploaded to the official archive. But I think also, I don't know off the top of my head exactly which ones, but probably last I checked system D didn't have support, I don't know if there's an outstanding patch for it. But mainly, it'd be nice to actually be able to get a DebootStrap, which can only support a single component. All of the things necessary to DebootStrap, a base to root would be nice. Right now you can do a minimal base to root, but let's bump it up a step further and maybe target some of the remaining patches necessary to do those. It is a fairly immature port at this point. So it's a great time to get in and get a lot of work done. And if that's the kind of thing that motivates you, small changes can make big differences. Yeah, I think talking about how the port stuff works is really useful. And in the same vein, I'll offer up a couple of thoughts based on experience about what it takes to actually port packages to a new architecture like this. One of the challenges is that if you look at the build dependency graph for the Debian distribution, it's horribly complicated. And part of the reason it's complicated is we have single source packages that build multiple kinds of outputs. For example, you might have a base essential package that you have to get built before the entire rest of the set of packages can be able to be built. But maybe that package also provides documentation that needs some fairly complex document processing tools in order to generate those outputs. And so a lot of the time, what you have to do as a porter is you have to be willing to temporarily do things like hack the source package to just not build any documentation so that you can get a working executable. And we spent a lot of time over the years coming up with ways to make this easier because we've done a lot of ports now. But if you look at this list, there are a number of places where it's like, you just need to add this architecture to a list of architectures that the package knows about and knows how to configure for. Or there may even be some packages out there that still have old ways of handling things like config.sub and config.guest versions which used to be a really huge problem. And so a lot of times when you get down to it, the patch required for packages really, really small once you get past this sort of bootstrapping problem and have enough of the distribution built to have a lot of those other dependencies, build dependencies available for building things like documentation and data and all of that stuff that may not be essential for breaking the build dependency graph. Are you using build profiles at all? Is that at all helpful? Because that was what this was for. I believe build profiles are definitely used. A number of the patches recommend, a number of the risk five tag patches are basically build profile, like please enable build profile support. I think we're past some of the very basic bootstrapping and so to some degree it's moving on to more, actually we don't need all of the build profiles but in general when build profile related bugs are really helpful to bootstrapping ports. Question, another question on another topic. Do people think it'd be useful to have the architecture documentation in Debian in a normal package? Because we can't have that for most other architectures, they're mostly proprietary sir. But for this architecture it's possible. Yeah. Also another thing, Karsten Merker mentioned on IRC was upstream really could use some work on getting the kernel driver bits upstream and a proper boot loader. I have one other comment. This is gonna be very predictable. So I should have known of course that Debian is itself maintaining several Debian derivatives. Your unreleased suite is obviously a Debian derivative. I wrote a tool you may have heard me plugging which is supposed to help with this kind of thing. Maybe people involved with ports stuff should talk to me after the session about how we can make all of this automatically rebasing all of your patches more automatic. I believe you're referring to Deget and Git Rebase? Deget. Okay. I saw there was an open risk part at some time. What's the big difference between open risk and risk five and... Right. My understanding which please correct me if I'm wrong was some of the core GCC patches to support open risk. The person who wrote the bulk of that actually blocked some sort of agreement in order to get those patches into GCC upstream. And so basically there was no possibility of getting the GCC patches upstream. So in that sense which that's pretty much going to kill any porting effort at least for a while until somebody rewrites it from scratch without looking at the other code which is highly publicly available. So yeah, that was a pretty unfortunate thing. I know one of the main porters involved in the risk five actually was also involved in the open risk port for Debian as well. Marker also mentioned, yeah, no upstream support in the tool chain. So the fact that we have all the most core major tool chains available upstream in risk five is just a huge win and sometimes that takes a long time for a new port. So any ideas when you think you might be ready to get into the main archive or maybe release? I'd want to see some real world build decapable hardware before that's even a dream. Sure, exactly. It's kind of hard to say with hardware, especially one that's so new and yet come so far. So really just takes some vendor to jump in and make better reality or maybe some huge community driven crowdfunding campaign. I have no idea. So BDEL says sometime in 2019 maybe. That sounds very awesomely optimistic. But yeah, I think once we get some decent build hardware, there's a little bit of a chicken and egg problem here too is like who's going to invest in this open architecture when there's not a working operating system for it? It's maybe a little, you know, other architectures will do that but maybe it requires some driving force behind it to actually carry that through. I think the attendance in this room shows that's really not going to be much of a problem. But I had a different, I'm sorry I came in late. So maybe this is already being covered. A speculative execution has been much in the news as I understand it, the current risk five calls don't do out of order so aren't vulnerable. Does anybody have any knowledge about whether that's in fact true and what the future plans of anybody that's making designs are? Because I know the architect was designed to support out of order but that's starting to look like a thing that you might want to ask questions about. You might prefer more slower calls for example. Right, as far as I know there are no implementations that support out of order execution and obviously going to be hesitant to actually bother building any at this point, I hope. Well this is part of the reason I think it'd be awesome if we could actually see the guts of the processors that are coming along the pipe. And I didn't mean any slight to the sci-fi folks earlier. I'm really thrilled that they built the chip they did and that that board's available but I hope that people aren't confused in the belief that that's what all we ever really want. With respect to the chicken and egg problem, the vagrant, I can report that the people that are thinking about doing things like building laptop designs around risk five are already really, really excited about the fact that the Debian port has gotten as far as it has as quickly as it has and I think that that has proven the sort of, there's a sense that the operating system port is already viable even though it's in Debian ports and not in the main tree and I think that that, I really wanna thank everybody that's been working on the port so far because it really has enabled folks that are thinking about doing business things around risk five to feel like there is a credible likelihood of being able to ship stuff that runs Debian. I'm really encouraged by this. There's two kind of ways of looking at that. One is it's really, really good for risk five which I like because I'm really keen to have open hardware but also I think that in Debian we sometimes underestimate our influence and our ability to change things, our ability to maybe disagree with other people and do our own thing and this kind of thing, this is us making a big strategic impact in like the CPU architecture in like the CPU marketplace. We are making something possible that would otherwise be very difficult and we're doing it for all the right reasons so I'm very proud of everybody else here in the room. Thank you. Somebody mentioned, is there anybody from Andy's technology who wants to say something? I know they're based in Sintu Science Park and maybe got nudged to show up. I know they do manufacture some risk five chips. Guessing that's... Oh, hello. Hello. Cool. Hello. Okay, in fact I don't know how to say it. What? We have our FPGA boards and yes it can run the linux for the risk five, yes. But sadly our company don't intend to sell the board so I think it's a main problem in the risk five world is only the sci-fi guy are intended to build a board to sell other than the company so I don't know. And I think sci-fi even, at least some of them have told me they don't actually want to be making boards, they just wanted to get something out there to kind of seed the world plan so that people actually start doing this though. But yeah, because it's almost no profit. So in that sense it might suggest moving towards some sort of crowdfunding effort but that's a non-trivial task. Josh follows and this talk. Is there any public example or demo we could find on the internet that is running strong on your and this core? We send many pages to the linux kernel and for our port in our SOC we may upstreaming our implementation to QEMU in recently the months I guess. Okay, so that way you may run the linux on our QEMU implementation, yes. And in our app page I'm not sure the schedule, yes. And we may provide a MCU version to run some kind of Arduino compatible programs in the app page at both. But there is no MCU in it. Who mentions from IRC what are the options for security applications that need a multi-core RISC-5 SOC capable of running linux but still need an MMU? Don't need multi-core, correction. Anybody know of anything like that? Are the Andes tech, those are 32-bit RISC-5 or are you also making 64-bit versions? We implement 32 and 64 version, yes. And we send Jullibusy patches for RISC-532 for the last few months and Palmer said he would do the following patch sets. We sent version three, yes. And he said he would follow the, yes, he would do the following things, yes. Cool, it's really great to see projects doing the work to push stuff upstream. In fact, that's astounding. I know in certain other architectures that sometimes happens, but really exciting to see that with RISC-5. There have been a couple of public comments in this debcon earlier about the fact that we're sort of starting with the 64-bit port because of course that's what's of greatest interest the most of us going forward. And there was at least an implication that maybe Debian wouldn't do a RISC-532-bit port. I commented at the time that I think we're gonna have to be careful about that attitude because as we go forward with public pronouncements by people like Martin Fink who's the CTO at Western Digital and happens to have been my boss at a certain point in history, he made a big public announcement about Western Digital's commitment to using RISC-5 and future products. And I think that that means that we're going to see in the industry a number of 32-bit implementations of RISC-5 embedded in various devices that we might very well want to be able to use to repurpose that silicon or maybe we might be able to get access to low-cost 32-bit implementations that are fun for doing embedded, network edge, security, whatever kinds of devices. And so I'm not jumping on the bandwagon to push starting a 32-bit port before we get 64-bits in good shape. That would be ludicrous. But I do want people to sort of keep an open mind about the fact that there may come a time when doing a 32-bit RISC-V32 architecture and Debian makes a heck of a lot of sense. We'll see. Of course, there's also the plausibility of a 128-bit port. Could be the first. But yes, focus on one at a time. So what are people's personal interests in RISC-5? Do you hope to run it on someday, maybe run it as your primary computing platform, as an interesting little hobby, as a handheld device? Like, anybody have any hopes, dreams, visions? Yes, all of us. Freedom! Right. There's a distinct call for freedom in the room. I think there's nothing wrong with speculation. If you can verify the layout of the CPU or so, I want to use a CPU where there's... which is at least tested and can be reviewed to find some security holes. So speaking of someone with experience from previous new architecture ports, please tell me you've got things like ABI nailed down, you've got cross-distro agreement for things like your Elf interpreter path and whatever. I do think... I think at least Fedora is also targeting the same instruction set with all of the extra bells and whistles, the same bells and whistles. I'm not positive. And I know they did a port once and they did it kind of the hard way and then they had to redo it. Debian's also... This is maybe the second major iteration of the Debian port for RISC-5. So, yeah. I think it's pretty much nailed down. I know... I also know the sci-fi folks in particular have really been like, we want to push... They kind of wanted to get a piece of hardware out there to sort of also solidify the spec to some degree. Yeah, there's a RISC here, Steve, that things could, you know, if we're not careful and if as a distribution, we don't sort of make our thoughts about such things known and through action sort of follow through on all this. It could be much worse than the arm situation in the kernel was at one point in history because even the base architecture is wide open and if somebody really wants to go create, you know, RISC-6 or RISC-42 or whatever, there's ample opportunity to do that. But I think you and I and everyone else who's been playing this game long enough understands that for there to be critical mass and for us to be able to do things like build and maintain a distribution, there has to be some consistency, some uniformity, some willingness for people to come together and standardize. And so I hope that by getting involved early in building a distribution around a particular ABI that, you know, until and unless somebody comes along and says, here's why we really, really, really want to change that and why it's going to make the world a substantially better place, that we won't see the kind of silly diversification that drove us nuts with IO structures on arm for a while, for example, and which finally is somewhat rationalizing. So yeah, there's an opportunity to get it right, but there's also an opportunity to really screw it up when we have all the knobs. Absolutely, so, I mean, is there, for example, a cross distro list to discuss this kind of thing or is it way too early? It's probably a little early, but I think people, I've seen conversations back and forth with at least Fedora folks. I don't know if there's actually lists. Sure, so if there isn't such a thing, I would strongly recommend start one and invite the other people to get involved. You know, it's easier to discuss this kind of thing early and make sure that, for example, you get binary, you know, binary. Did the answer to the questions on the screen there? Okay, awesome. Yeah, great. Make sure you have a cross distro forum so you can discuss things as they come up rather than a year later and realize, oh crap, we need to rebuild. Right, definitely, yeah. I wanna put a thanks out to Karsten Merker for showing up on IRC, who's more actively involved in the RISC-5 port than I am, but woke up stupid early to attend, so thanks. Yeah, we're pretty much wrapping up. Yeah, thank you all for coming and let's keep this thing real.