Porting Debian to the RISC-V architecture
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Merker, Karsten
The talk tells the story of how the Debian GNU/Linux port for the RISC-V architecture came to life and describes the steps and challenges involved in adding support for a completely new architecture to one of the major Linux distributions. It provides an overview of the current state of the port and gives an outlook on further developments.
 So, morning everybody. My name is Kastan Merker. I'm one of the Devian developers who are working on the Devian Risk 5 port. And today I'm going to tell you the story of how the Devian Risk 5 port came to life. What we have achieved until now, which obstacles we had to tackle to add a completely new architecture to a binary distribution like Debian. I'll show you what we have achieved, what we are planning to achieve and give you an outlook about what we hope to have within the next one and two years. I'll start with a short introduction of the Risk 5 architecture because I know there are people around here who come from the Debian side, not from the Risk 5 side and are not familiar with the details of Risk 5, so I keep it short. So, what's Risk 5? Risk 5 is a CPU instruction set architecture that has been designed at the University of Berkeley originally as a student project, has grown a bit since then and everybody is free to implement CPUs based on the Risk 5 ISA and the specification that defines the ISA is available under free license under CCBI and to make sure that implementations actually conform to the specification. The Risk 5 Foundation has registered trademarks on the name Risk 5 and you are only allowed to call your implementation Risk 5 if it actually conforms to the spec to make sure that we don't get incompatible implementations. The Risk 5 ISA exists in three different variants. It's available in 32-bit, 64-bit and still work in progress 128-bit, so for practical purposes 32-bit and 64-bit right now. It has been designed to be modular, to scale from microcontrollers up to supercomputing and the ISA designers are trying to have only non-patentable technology in the ISA specification so that it is possible to actually implement the Risk 5 CPU without having to buy patent licenses. There is no formal legal guarantee for that but designers have put quite a bit of effort to make sure there are no patent problems. So we know what Risk 5 is. What Risk 5 is not, Risk 5 is not a specific CPU. It's just an instruction set architecture, the set of commands and the behavior but not a specific chip. And while the specification is under free license there is of course the possibility to implement proprietary CPUs based on the ISA. There are already some. And one thing that's somewhat of a problem for open source projects is that the stewardship of Risk 5 in the hands of the Risk 5 Foundation is open in the way the semiconductor industry defines the term open but not exactly in the way open source projects define the term open. All the specifications once they are released are available under free licenses so no problem with that. But taking part in the specification process itself requires a Risk 5 Foundation membership which requires signing a non-disclosure agreement which is why many open source developers like me are not a member of the foundation. Most of the software stuff is actually handled outside the foundation but the actual ISA specification runs inside the foundation and getting access to previous documents actually requires membership. Everybody can become a member as a personal member but personal members don't have voting rights so actual decisions get made by corporate entities in the foundation. So why is it called Risk 5? That's rather easy. It's a classical risk architecture like there have already been a lot and it's the fifth major risk architecture designed at Berkeley so the name is rather obvious. There have been other risk architectures for example MIPS if you have a DSLR router at home chances are about 95% that it's MIPS based. If you're carrying a smartphone it's about 95% ARM based and there are several others. Most of them are closed architectures designed by companies. MIPS is just now slowly changing there is opening up a bit. Sun Microsystems has actually specified SPARC in an IEEE standard but that standard itself is not freely available so one has to buy the standard which again is not nice for open source communities. There has been open risk and actually open CPU instruction set architecture so why yet another one there are already so many to choose from. Risk 5 has been designed at university. One of the targets of the architecture has been teaching and closed architectures are not suitable for teaching because you're legally not allowed to just implement an x86 CPU without having a license from Intel and AMD. SPARC has the problem that it's only halfway open and the SPARC designers have actually made some choices that well people wouldn't do now today. An open risk is a fully open design but open risk has a historical problem. Originally when open risk was designed one of the GCC porters for open risk didn't allow a copyright assignment of his code contributions to the FSF and the FSF requires a copyright assignment to get code in GCC upstream. Without this copyright assignment support for open risk could never go upstream which is why all efforts to broaden the use of open risk have actually failed. Right now this has changed. An open risk developer is right now working on re-implementing all the open risk GCC support and getting it upstream but well in the meantime we have several years of risk drive so we'll see. Risk drive has been designed to avoid some of the decisions that older architectures have had. It's designed to be easily possible to be easily implementable and to be extendable at the same time. We'll get to the extensions in a few minutes. One thing that's important is that risk drive follows a strict upstream policy so all tool chain stuff is handled in upstream. So we don't want 5000 forks of binutils, compilers, whatever. We want to have everything standard in upstream. The ISA itself consists of several modules which are labeled with characters as you can see there. There's the base ISA which is just the integer operations. There's hardware multiply, automax, signal and double precision floating point and all those together are called the general purpose set which is what one would expect for a system to run Linux, PSD, whatever. Then there's the compressed instruction set which is actually not new instructions but a shorter encoding for existing instructions. Normal instructions in risk drive are 32 bits long. The compressed instructions provide a selected set of instruction with a shorter 16-bit encoding which has the advantage of using having less cache pressure, having less memory bandwidth requirements, better performance. And if one wants to specify which bits of the ISA CPU supports, you get an ISA specifier like you can see below. IMAFD is RB64G. When the Linux distributions have started porting for risk five, we had to decide about whether to assume the compressed extension as available or not that had some discussions at that time. All the binary distributions that are working on risk five support right now assume that the C extension is there. There is work on a platform specification which defines that all risk five Unix style platforms shall have the C extension. The ISA has three privilege modes. Machine mode is the highest level. Microcontrollers usually only implement machine mode. If you want to run Linux or PSD, you need all three modes. The 32, 64 and 128-bit ISAs are actually independent from each other. That's probably strange to people who are used in inter architecture where every 64-bit CPU also runs 32-bit code. That's not the case on risk five. We have a similar effect on ARM64. ARM64 CPUs can optionally support 32-bit code but they don't have to. And actually there's quite a bit of ARM64 servers which only run 64-bit code and no 32-bit code. Short side note on Meltdown Inspector. In discussions about risk five, often people claim, yeah, risk five is the solution to Meltdown Inspector. It's an open architecture. We won't have any problems with that. It's just nonsense because Meltdown Inspector are implementation bugs. They are not a bug in the design of the instruction set architecture but in specific chip implementations. So why currently we have no risk five chips which do speculative execution which is the base for Specter and Meltdown. So currently there is no risk five chip that's vulnerable. Nobody can guarantee that that won't happen in the future when we get chips that do speculative execution. So now we have an ISA but if we want to use an ISA we would like to have hardware or at least otherwise run code. There are multiple options. We can do QM emulation. QM has support for both user space as well as full system emulation. We have CPU designs which can be instantiated in field programmable gate arrays. I'll get to that later on. And we also have real CPU chips. Last year at FOSTA we had the presentation of the SciFi Freedom U540 which is the first Linux capable risk five chip in the world. There is the lowest project which is working on designing a community stock but that's still a lot of work and until we actually have those chips on our desks will probably take three, four, five more years. Doing chip design is hard and well it needs work and needs to be paid. Then there's Shakti. Shakti is a project in India which aims at designing a full family of risk five chips from small IOT style embedded stuff up to super computer hardware and the Shakti team has recently actually taped out the first locally produced Linux capable chip. So what you see here is a picture of actual risk five hardware. The left one is the prototype that had been presented at last FOSTA. The right one is one of the early G-Lipsy development systems. That is the prototype chip. That is an FPGA board which acts as south bridge and provides PCI Express and that's a PCI Express NVMe SSD. So why porting Debian to risk five? From a physical point of view Debian and risk five are perfect match. We have open source hardware, we have open source software and we would like to combine those two. There have been efforts of porting Debian to open risk but those have not been successful because of the GCC problematic because we would have shipped different GCC versions on different platforms which is something that Debian does not do. Debian uses the same versions on all platforms so that was not an option. The risk five ISA is probably the first Open ISA that has a realistic chance of actually gaining mass market traction. There are a lot of companies supporting risk five right now and things in the semiconductor industry are slowly changing. It's become slowly possible to actually have community led chip production. It's still very much expensive but things are changing in the industry and within a few years it might be possible to actually have community led chip designs mass produced. The first work on porting Debian has started in early 2015 and at that time a lot of stuff was still a movement. BinyoTills GCC were changing every day. G-Lipsy was in its early infancy, the Linux kernel as well. Things have been changing about every two days and code generation actually got incompatible from one week to another because of changes in the compiler in the community. Which meant, well, if I build stuff today I probably cannot link it against stuff built into weeks which is kind of sad if you want to do binary distribution. Then there was somewhat of a culture clash between people from the hardware design world and from the software design world that took say half a year to sort all that out. Another problem was at that time we had no QEMO support so there was only Spike. Spike is a CPU architecture emulator which emulates the basic RISC-5 CPU. It only emulates a block device and a dump serial console but no network. So think you want to put some distribution, you build a root file system with something, you want to compile something and find, okay, I need another bit of software. Well, normally you just download it but if you have no network that's kind of difficult. So shut down emulator, unmount block device, mount block device on host, copy files in, unmount block device, start emulator again, start working. If you have done that 20 times you want something else. Yeah, due to the ABI breaks and the incompatibilities in the tool chain all early attempts at actually building packages have not been successful. So both Fedora and Debian developers have chosen instead to work on getting stuff upstream and getting stuff in utility GCC, GLEB C kernel stabilized so that we have a stable IBI and can be sure that stuff that we built today still works tomorrow. That included some modifications to the linker for Debian-style multi-arc support that included getting an agreement about using device tree for hardware description similar to what we use on ARM and on PowerPC and recently also on MIPS. And well, things were looking quite well until early 2016 and we had some form of déjà vu because we wanted to get GCC support upstream and the people who wrote the GCC support were happy to do a copyright assignment. Unfortunately some of them had work contracts with the University of California which gave the UCB the copyright in some of the contributions. And UCB was happy to license the stuff under free license under GPL and the BSD no problem but they were not willing to agree to a copyright assignment. So we were exactly in the same situation that the open-risk people have been facing beforehand and things were looking rather dire. It took nearly a year to get the legal stuff sorted out. So end of 2016 the stuff could actually go upstream and from then on BinyoTiltz and GCC went rather fast. Just a few weeks after the legal stuff had been sorted out BinyoTiltz went upstream three months later GCC was upstream. Then came GILIPSE and kernel. The GILIPSE and the kernel are very much dependent on each other because they use low-level interfaces and getting that specified out so that the GILIPSE people were happy and the kernel people were happy took nearly a further year from there on. So effectively at last forced them exactly one year ago. We were there that we had toolchain, kernel, things were working, things were upstream. We could start with a bootstrap or the distribution. There were some tools that were still missing, GDP Linux support is still missing. We have bare metal support but not for Linux debugging. As you have heard probably in the talk before LLVM and Clang support is still work in progress. We hope to sometime this year have a release that will probably work for distribution users. Java has been a problem. We have Java support now but only interpreter support not just in time compiler support. So Java works but it's dark slow. Getting JIT support is still quite a bit of work. Rust depends on LLVM. Something that to my knowledge nobody is working on. Okay, somebody is working on GOLANG. And then there are of course other languages and other compilers. V8 is the JavaScript engine for Node.js which is also not working yet. So now we have compilers, we have binutils, we can build code, we can build packages. But we are starting from scratch. We have nothing for the RISC-5 architecture. So how do I get a distribution from Thiner? We have nothing. Well I need a cross compiler. So I run a compiler on a PC but generate code for RISC-5 and make use of the WMulti architecture support which allows us to have code for multiple architectures within one root file system. So I can gradually generate packages for new architecture. That of course requires getting RISC-5 support into the true-chain packages that we had in Debian. But as the support had just been released a few weeks ago, the binutils GCC packages in Debian of course did not yet have RISC-5 support. So the first step was actually packaging new versions of all that and getting them into experimental. Then how does one start in bootstrapping a new architecture? I need a base set of packages. So which packages and how many are that? Well Debian has package priorities and the packages with the priority required are the base package set. And while priority required, okay that's easy, just a handful of packages, that's 55 packages, that's no problem. Well actually it is because those packages have dependencies, they want libraries. And those libraries have dependencies themselves and to be able to build those libraries, I needed a lot of other stuff. So I need dependencies of dependencies of dependencies of dependencies of dependencies of dependencies to build stuff, which ends up in several hundred packages I have stopped counting at nearly 400. One of those problems is that, for example, if you have source code that uses mason to build, mason uses python and building python is a problem in so far as python has lots of dependencies because python has modules for a ton of stuff and to build python, the python package, you have to have all that stuff. So that gets a rather large dependency chain. Dependency issues are twofold, one are deep dependency chains, as I've just shown an example. To build one of the command line base packages, we had to cross build some 80 or 90 other packages just to get the build environment set up to be able to compile a single package. Another problem are circular dependency chains, which is where the cat chases its tail. Packages in the base system are, for example, audit. Audit requires open add up for building. Open add up in turn requires sarsl for building. Sarsl requires pan for building and pan, okay, it's audit for building. So the cat has just found its tail. How to resolve that? We have to build packages with smaller feature sets to just remove certain features from the packages to break the cycle. And doing that by hand is rather tedious. So Debin has a mechanism for that that is called build profiles. So you can build a package with different feature profiles and during the bootstrap process we actually have added several build profiles to the number of packages to be able to break those dependency cycles. What you see here is a dependency graph of Firefox just to give you an impression. That on top there is the Firefox source. The boxes that are led to by the brownish lines are direct build dependencies of Firefox. Each of those build dependencies has runtime dependencies which are all those blue lines going to different packages. And that's just the first level of dependencies because all of those blue packages have dependencies on their own. Which have runtime dependencies. So if you look at that graph you can probably imagine that building Firefox comes very, very, very late in the bootstrap process. I've said that we've started cross building because we had no native code. And cross building is not as easy as doing native builds. Several package which built finitely don't cross build properly. There are differences in cross build support in different build systems. People often say GNU Auto Tools, old stuff, ugly stuff and just leave me alone. But GNU Auto Tools has one major advantage. Cross building effectively works out of the box. Effectively everything built with auto tools just cross builds. That's unfortunately something that we cannot say about many CMake and Mason based projects. Both CMake and Mason have a theory support for cross building. But many packages that use Mason and CMake don't make use of the infrastructure that those two provide. And in practice we had to fiddle around with many of the Mason and CMake using packages to actually make them cross build. Pearl is, well, just strange. Pearl claims to be cross buildable. Well, the way pearl cross building works is that the pearl configure script requires an SSH connection to a system already running the architecture I want to build for and then run the configure script natively on the architecture which obviously does not work in a bootstraping scenario. So the only way to build pearl is actually build all the rest. So I have a native compiler and then build pearl natively. Another common problem is generators. Make files sometimes compile code which they then execute to generate further source code. That works on a native build so if the compiler is running on a PC and the binary I'm creating is for a PC, no problem with that. But in the cross build setting I'm running a compiler on a PC but generating code for RISC-5 and the PC cannot just execute the RISC-5 code. So that does not work. Proper build systems should take care of that and in a cross build setting use the proper compiler for the code generators. Another option if one has QMEU support is using QMEU userline emulation that helps but we didn't have that in the beginning. Another thing is that many upstream packages don't properly separate between host arch and build arch tools. So if I for example want to call package config to get the GCC parameters for linking to library, those are at least somewhat architecture dependent so I need the package config for the correct architecture and many make files just don't take that into account and always call the package config for the architecture the compiler runs on which is wrong if I'm cross compiling. And then there are some cases of packages that are not multi arch co-installed with themselves that can happen. I'm using a tool to build a package which has a library dependency and the code I'm trying to compile for RISC-5 also requires the same library in the RISC-5 version. With most libraries in Debian it's possible to co-install both at the same time but there are libraries where that doesn't work or doesn't yet properly work so we had to work around that. Then there's of course general portability stuff. Data type sizes are architecture dependent. How long is an int? Is an int 16 bits, 32 bits, 64 bits that changes from architecture to architecture. There's endiness so the way numbers are represented in memory. A very common occurrence is that upstream ships outdated configs up and configs out of confiles. The FSF recommends that auto confuses should always regenerate configs up and configs up from current upstream so that new architectures automatically get supported. But many upstream authors just put the versions they have used when building the release table which are old and they don't know about RISC-5 so we had to replace those. Another thing that's rather common is atomic support. There is a tiny but important difference how to call, how to link in the pthread. There is the dash pthread flag to the compiler and just dash LPthread which just links the library. Problem with that is on PCs just linking the pthread library is enough that works. That's the case for x86 and amb64. That's not the case for quite a bunch of other architectures. And as most developers probably develop on PC hardware they just don't look at something like that so we had to patch quite a number of packages for that. And then there are packages that actually require hand crafting header files for each new architecture. LibGPG error is one of those examples. Then there's type constraints. We have atomics but on RISC-5 atomics are only supported on native word sizes not on smaller objects. The PC architecture allows using atomics on arbitrary object sizes. That's not the case on RISC-5. We have lipatomic which abstracts that away so if people use lipatomic that's not a problem. But again many abstract projects just assume that atomics work on arbitrary sizes because that's just the case on PCs. But that's not true for all other architectures. And then there is of course stone-etched stuff like looking in the x11 sources which doesn't make decisions based on properties like even in 32-bit then do something. If you look into the x11 sources there's really if architecture is through then list of code. If architecture is bar then list of code. If architecture is bar then list of code. And so we had to write just new code for that. We tried to get it upstream but that didn't work because the x11 developers don't want to add code for new architectures because they say x11 is in maintenance mode and we don't want new architectures upstream. And then of course there's the problem of compiler support. We like Rust. So building for example Firefox and some other stuff currently does not work because we don't have a working Rust compiler yet. Yeah, doing all the package bootstrap, getting the ordering right, patching packages is rather tedious and of course we would like to have that automated. For automating that is way more complicated than one would expect at first sight. A Debian developer has some years ago written his master thesis about bootstrapability issues which has helped a lot and there's a tool by Hamilton Grone which is called Rebootstrap which at least as far as possible automates the early bootstrap. So getting new tools, getting compiler, getting various new tools, getting several basic libraries which we were very happy to have. So now we have packages but we want to have a proper distribution so we need to get those packages into Debian infrastructure. Debian has two major types of architecture. So regular architectures which have regular stable releases, get security support for stable releases and we have ports architectures which is somewhat of the kindergarten of Debian architectures. New architectures usually start in ports because they're incomplete, there might be stability issues at the beginning and bugs in ports architectures don't influence regular architectures. So just unstable testing, stable migrations on regular architectures still runs even if a package is broken on one of the ports architectures. Then for ports architectures we have a bit more freedom. For example the ports architectures have an additional suite in the Debian archive which is called unreleased which is allowed to carry architecture specific patches which are not in the main package source. This is only for temporary stuff so the aim is that having unreleased empty, that's the final aim. But while we're working on that there is some stuff which we currently can only keep in unreleased. So that's where we are right now, we have a bunch of packages. We aim at becoming a regular Debian architectures sometime in the future but that requires being able to build about 95% of the archive and we are not there yet. This is a package build graph, the gray line here has been the percentage of the RISC-5 packages that have been built. This graph is several months old, the spike that you see here has actually been created by porting the Haskell compiler. At that point in time we got Haskell bootstrapped and built a bunch of Haskell packages which gave that RISC in available packages. Unfortunately the number of packages actually has dropped down again in the meantime because we have some packages which we had been able to build in the past but which we cannot build anymore. One of the problems is that several upstream sources that have in the past been using CRC++ are moving to Rust. So we could build the old CRC++ based versions but we can't currently build the new Rust based versions so we had to drop out some packages. Another problem is the QTE ecosystem which in the past has had its own C++ parser which has now moved to using LLVM which brings us to the problem that we don't yet have LLVM. We are currently at 85, 84 or 85% of packages which provides a rather usable system but of course it's not everything yet. To become a release architecture, an officially supported stable release architecture, we need to have the app installer support that's work in progress but not yet finished. We need to have enough buildies with redundancy. Buildies are the package builders they've been using to automatically compile packages for all architectures. We need to have everything in infrastructure managed by the Damian system administrators which have requirements so they want great multiple server-grade hardware, remote management capabilities which is somewhat difficult with small chip prototype development boards. So that's also something we hope to get within the next years but we haven't yet. And of course there need to be people to take care of the architecture. Okay, we have those. The Damian installer support is work in progress. It's possible to build a Damian installer for us five from Damian installer Git but it's not really usable yet. We have two issues that are still being worked on. One is that we have problems with LVM tools. Somebody is working on those. That's the last big blocker to get the Damian installer released. Another thing is that we currently don't yet have bootlidder support. The UBoot port for us five is still rather new. Just yesterday, two days ago, the first OpenSBI code base which we would need for that has been published. So that's something that I will look into into the next weeks. Then there is the topic of 32-bit support. Currently we only support RV64, 64-bit risk five because that's where most of the work has gone in, where we have hardware. 32-bit support is still work in progress because we don't have 32-bit support in Glypsy yet and the kernel support for 32-bit is also not complete because that needs to be coordinated with Glypsy. And we have the problem that you might have heard of the year 2038 problem that we have a time type overflow in a few years. And we want to describe to do that the right way, but that requires infrastructure in the kernel and in Glypsy, which hasn't been there in previous Glypsy series, which is just now getting into Glypsy. And we didn't want to release a 32-bit port that would be binary incompatible in a few years because we would have maybe I break to handle the year 2038 problem. So that takes a bit. Fedora and Rathat probably won't release 32-bit ports. Debian might do it, we'll see, if interesting hardware becomes available for 32-bit platforms. The way such hardware could become available are small FPGA implementations. Designing CPUs on field programmable gate arrays is a common technique in commercial CPU development. But in the open source field, that hasn't been done very much because for all available FPGA types, one had to have proprietary compiler tool chains, FPGA tool chains from the big FPGA vendors, and while open source developers don't want to build this stuff based on proprietary tools. In recent years there has been a lot of effort to reverse engineer the FPGA bit stream configuration format and to implement free tool chains for FPGAs. We actually have one that's fully working, that's Project ISTORM, which is packaged in Debian. So you can actually implement a CPU with tools in Debian and run it on an FPGA. There's Project Trellis, which is currently working in progress. There's a talk tomorrow, just upstairs from here, from the Project Trellis project leader about his support for the ECP5 FPGA series. What's interesting with the ECP5 is that it's about 10 times the size than the small ISTORM that we have supported right now. Problem with the size is I can implement a CPU on a latest ISTORM but that's more microcontroller class, something Linux capable with memory management unit. In that size is very, very difficult. David Shaw has actually implemented an open risk CPU on an ECP5 and is planning also to do a risk 5 implementation on one. Then there's Project X-Ray for even bigger FPGAs from Xilinx that's in rather early stage. Things are moving forward but I wouldn't hope my breath while waiting. That will probably take one or two more years until we have something that finally works there. Well, FPGAs are nice. I can actually in place update my CPU. If I have a better version of my CPU, okay, compile it, place in the new CPU. But FPGAs have disadvantages. The clock rates that I can achieve are rather low. So if you get 200 megahertz that's already rather fast, more realistic on cheap FPGAs is something about 50 megahertz which by today's standards is just slow. Getting fast chips is rather expensive and compared with actual mass manufactured Azix they use a lot of current. Another problem is getting memory. Modern memory interfaces are very complex and attaching modern double-datter rate memory to an FPGA is difficult. That requires a specific file layer that requires an appropriate memory controller that's not easy. So we have currently only the choice either use memory that's easier to address but it's slower and it's more expensive or if somebody manages to reverse engineer the common DDR5 layers in the bigger FPGAs we might be using standard DDR memory but that will take time. Well, we have FPGAs but there are also projects for Azix. I have already mentioned the LowRisk project which is working on an RV64 community sock. The current development version of the LowRisk sock runs on an FPGA and it actually runs Debian. The software development for that chip is actually using Debian. Then of course if I want to mass produce a chip there's not only digital logic in it. The CPU itself is digital logic but I need voltage regulators, I need analog digital converters, I need a random number generator, I need a brownout detection to make sure that the voltage doesn't drop too much. So there's a lot of analog technology which you also need to produce such a chip. There's a spin-off of the Universidad Industrial de Santander in Colombia which is working on providing open source licensed analog components for such CPU. There's also an interesting project. Several people will say that's just insane but nonetheless I find it interesting. The Libre Silicon Alliance is a group of people from the chip design world which are trying to define a standard silicon chip manufacturing process. Currently you have one problem. You want to produce a chip, you go to one chip fab and say okay here's my design, build that for me. You have to use a set of standard cell libraries from your fab. You're not allowed to disclose how those look like. So if you want to build your chip in another fab, you can't just take your design to another fab. You have to redesign your chip with their standard cell library. There is no portability between fabs and the Libre Silicon Alliance is working on defining a standardized process that is actually transferable from one fab to another. They've started very, very small. They currently have done their first prototype chips which are based on one micrometer node size. That's technology from the early 80s. So nothing you could build a modern CPU in but that's a long-term project. They're estimating a time frame of perhaps 10 or 15 years. So nothing for tomorrow but nonetheless interesting. And then there's chips for Makis which is a project to improve the software side for ASIC design which also has a talk tomorrow upstairs. They are aiming to produce a community-funded small CPU. This is 16 bit, 32 bit, 68K, Z80 type stuff and have actually managed to get the design done but in the first round the funding for the actual mass production of the chip didn't work out. They're trying to do another run and we'll see how far they get. So that's my talk so far. Questions? So you said at least twice that in some cases Rust is a problem. And Rust has a back-end of the Rust specific patches of LLVM because even if you have LLVM. It still needs to be ported, yes. It needs to have the Rust specific patches to LLVM because Rust community also has a set of patches which they didn't get upstream to LLVM. So even if you were in a situation where you had LLVM you don't have necessarily Rust on the LLVM. Okay. I try to repeat that because the people of the stream probably haven't heard the comment. So to get Rust one does not only need to have LLVM working but there are also Rust specific patches to LLVM which also need to be ported which would also need to be done. To be upstreamed. Yeah. To be upstreamed. And the question is how is Debian handling those Rust specific patches for LLVM? The question was how is Debian handling those patches currently not at all? We haven't actually looked into that yet. Okay. Further questions? Sorry. I just didn't understand that acoustically. The question was Debian has rather recently bootstrapped AMP64 and how much of the bootstrapping procedure have we been able to reuse for them in a Rust 5 bootstrap? Actually quite a bit during the AMP64 bootstrap several packages have gained build profiles to make dependency cycle resolution easier and that has actually helped a lot. The Rust 5 specific stuff of course can't take anything from AMP64 but the infrastructure has gotten a lot better and there are people like Helmut Grohner who has written the reboot strip tool that I had mentioned are working permanently on making bootstrap ability better by fixing cross architecture bugs by adding more build profiles so that definitely has helped. I actually don't know. That has been handled by lawyers behind closed doors and I have no information about that. Start with Debian. I just repeat that. How was the legal problem with the copyright assignment of the GCC code to the FSF been resolved? I really cannot tell that because that was something that had been handled between the Rust 5 foundation and the University of Berkeley and they haven't told the public in which specific way an agreement was reached so I can't tell anything about that. I totally have sympathy with the work you have been doing. I have just repeat for the stream business. The question was that the base package set appears to be growing compared to past ports when 32-bit ARM had been ported the base package set had been something around 200 something packages. Now we have reached nearly 400 and which problems have been the major pain point in porting. The first major pain point has been Perl, the lack of cross bootstrap ability of Perl because all of the packaging infrastructure in Debian is based on Perl. You need Perl for almost everything. Getting Perl ready has been a real problem. The second one in my view has been Mison but perhaps where is Manuel? Perhaps you can comment on that? Can you talk a bit louder? Just don't hear you. I'm sorry. The other week, one problem was the GNC which was in experiment that was where we initially had problems with the bootstrap. Then the one that I remember Perl was a problem which was one of the biggest problems but the other one was still many packages in the bootstrap in the first example for utilities don't look very properly because they need to help to manage for example to generate demand pages. This has to run natively so there are many small changes that need to be made to get the base set. In the media there were patches for users but they were not accepting the time for the maintainer or they were running behind. There were many problems with the new server bootstrap. I'll just repeat that for the people listening on the stream. One of the pain points in the early bootstrap had been that Gilepse for his craft had only been in experimental because we had to use a newer version than all the other gaming architectures and that caused some compatibility problems in the early bootstrap. Then one problem has indeed been core utilities because core utilities help to man to generate demand pages and help to man does not work in a cross setting. That took quite a bit of work arounds that should be resolved in a newer core utility version than we had at that time but when we did the bootstrap that was indeed a problem. That's of course another problem when one builds an architecture in emulation in QAMU and one has to handle a bug. The problem is the bug in the code I'm trying to debug or is the bug in the emulation I'm using to run the code. We had some cases where the code actually was fine and the bug was in the emulator which of course has needed time and a lot of debugging so having real hardware is of course better but when you start such a port of we only have emulators I suppose the ARM64 port had the same problem you started with the original architecture emulator. So that's something that's nearly unavoidable if you do an early bootstrap. That is easier if you wait with bootstrapping until the architecture has already brought use but of course you want to distribute software early in the release of new architecture to make the architecture actually usable. We have tried to get the cross compilation patches upstream in some cases that has worked and they were accepted in some cases they weren't because some people consider cross build support in maintenance burden because you have to think of things of which you don't have to think when building natively and well some upstream authors don't see bootstrapping in new architecture as a relevant problem for their software. That's unfortunately but that's reality. Yes we carried the patches in the Debian packages but we would have preferred to have them upstream but they weren't accepted just because the upstream developers consider X11 to be in maintenance mode. They don't want feature additions even if it's just a new architecture. Any more questions? We have a CI system running reboot strap, Hamlet grown as base bootstrap tool which works with cross building and we have Jenkins jobs doing that. If you have packages that are part of the base systems it's helpful to look at the Jenkins results and see if your stuff fails. Debian has portal boxes for multiple architectures on which you as a package maintainer can log in on each architecture that Debian supports and try to build it. We have cross compilers in Debian for all architectures that we support in Debian. The Debian packaging tools actually support cross building packages. So we can just say sbuild dash dash host arch is riscribe64 and it runs a cross compiler and tries to cross build your package. So if your package maintainer it's rather easy to check whether your stuff is cross buildable. That's more of a problem. Upstream is more of a problem. We had some discussions yesterday evening about ways to provide risk 5 machine instances to upstream developers to enable them to test build their code and debug issues on native hardware. That's being worked on. I just repeat that for the stream. The common was that we should try to avoid bootstrapping riscribe 32 bit because other 32 bit architectures in Debian are already struggling with keeping up and building large packages. One known problem is building stuff like a debug build of Firefox which is a problem on 32 bit architectures in fact. I would just like to make a bit of a counterpoint to that. I'm working on the FPGA tool stuff and RV64 GC is a pretty big ISA because you basically got to have hardware that is something that can very nicely fit on FPGA and run quite well. Okay I'll just repeat that for the listeners on the stream. Counterpoint to that argument when one is targeting CPU implementations on FPGAs 64 bit architectures are a problem because they use a lot more FPGA resources than 32 bit architectures way more than double of 32 bit architectures and getting a 32 bit riscribe CPU Linux capable on an FPGA is quite doable even on smaller not tiny but smaller scale FPGAs but 64 bit CPUs is a problem in resource usage. Any more questions? Okay thanks.
 So, morning everybody. My name is Kastan Merker. I'm one of the Devian developers who are working  on the Devian Risk 5 port. And today I'm going to tell you the story of how the Devian Risk  5 port came to life. What we have achieved until now, which obstacles we had to tackle  to add a completely new architecture to a binary distribution like Debian. I'll show  you what we have achieved, what we are planning to achieve and give you an outlook about what  we hope to have within the next one and two years. I'll start with a short introduction  of the Risk 5 architecture because I know there are people around here who come from  the Debian side, not from the Risk 5 side and are not familiar with the details of Risk  5, so I keep it short. So, what's Risk 5? Risk 5 is a CPU instruction set architecture  that has been designed at the University of Berkeley originally as a student project,  has grown a bit since then and everybody is free to implement CPUs based on the Risk  5 ISA and the specification that defines the ISA is available under free license under  CCBI and to make sure that implementations actually conform to the specification. The  Risk 5 Foundation has registered trademarks on the name Risk 5 and you are only allowed  to call your implementation Risk 5 if it actually conforms to the spec to make sure that we  don't get incompatible implementations. The Risk 5 ISA exists in three different  variants. It's available in 32-bit, 64-bit and still work in progress 128-bit, so for  practical purposes 32-bit and 64-bit right now. It has been designed to be modular, to  scale from microcontrollers up to supercomputing and the ISA designers are trying to have  only non-patentable technology in the ISA specification so that it is possible to actually  implement the Risk 5 CPU without having to buy patent licenses. There is no formal legal  guarantee for that but designers have put quite a bit of effort to make sure there are  no patent problems. So we know what Risk 5 is. What Risk 5 is not,  Risk 5 is not a specific CPU. It's just an instruction set architecture, the set of commands  and the behavior but not a specific chip. And while the specification is under free  license there is of course the possibility to implement proprietary CPUs based on the  ISA. There are already some. And one thing that's somewhat of a problem for open source  projects is that the stewardship of Risk 5 in the hands of the Risk 5 Foundation is  open in the way the semiconductor industry defines the term open but not exactly in the  way open source projects define the term open. All the specifications once they are released  are available under free licenses so no problem with that. But taking part in the specification  process itself requires a Risk 5 Foundation membership which requires signing a non-disclosure  agreement which is why many open source developers like me are not a member of the foundation.  Most of the software stuff is actually handled outside the foundation but the actual ISA  specification runs inside the foundation and getting access to previous documents actually  requires membership. Everybody can become a member as a personal member but personal  members don't have voting rights so actual decisions get made by corporate entities  in the foundation. So why is it called Risk 5? That's rather easy. It's a classical risk  architecture like there have already been a lot and it's the fifth major risk architecture  designed at Berkeley so the name is rather obvious. There have been other risk architectures  for example MIPS if you have a DSLR router at home chances are about 95% that it's MIPS  based. If you're carrying a smartphone it's about 95% ARM based and there are several  others. Most of them are closed architectures designed by companies. MIPS is just now slowly  changing there is opening up a bit. Sun Microsystems has actually specified SPARC in an IEEE standard  but that standard itself is not freely available so one has to buy the standard which again  is not nice for open source communities. There has been open risk and actually open CPU instruction  set architecture so why yet another one there are already so many to choose from. Risk 5  has been designed at university. One of the targets of the architecture has been teaching  and closed architectures are not suitable for teaching because you're legally not allowed  to just implement an x86 CPU without having a license from Intel and AMD. SPARC has the  problem that it's only halfway open and the SPARC designers have actually made some choices  that well people wouldn't do now today. An open risk is a fully open design but open  risk has a historical problem. Originally when open risk was designed one of the GCC  porters for open risk didn't allow a copyright assignment of his code contributions to the  FSF and the FSF requires a copyright assignment to get code in GCC upstream. Without this  copyright assignment support for open risk could never go upstream which is why all efforts  to broaden the use of open risk have actually failed. Right now this has changed. An open  risk developer is right now working on re-implementing all the open risk GCC support and getting  it upstream but well in the meantime we have several years of risk drive so we'll see.  Risk drive has been designed to avoid some of the decisions that older architectures  have had. It's designed to be easily possible to be easily implementable and to be extendable  at the same time. We'll get to the extensions in a few minutes. One thing that's important  is that risk drive follows a strict upstream policy so all tool chain stuff is handled  in upstream. So we don't want 5000 forks of binutils, compilers, whatever. We want to  have everything standard in upstream. The ISA itself consists of several modules which  are labeled with characters as you can see there. There's the base ISA which is just  the integer operations. There's hardware multiply, automax, signal and double precision floating  point and all those together are called the general purpose set which is what one would  expect for a system to run Linux, PSD, whatever. Then there's the compressed instruction set  which is actually not new instructions but a shorter encoding for existing instructions.  Normal instructions in risk drive are 32 bits long. The compressed instructions provide  a selected set of instruction with a shorter 16-bit encoding which has the advantage of  using having less cache pressure, having less memory bandwidth requirements, better performance.  And if one wants to specify which bits of the ISA CPU supports, you get an ISA specifier  like you can see below. IMAFD is RB64G. When the Linux distributions have started porting  for risk five, we had to decide about whether to assume the compressed extension as available  or not that had some discussions at that time. All the binary distributions that are working  on risk five support right now assume that the C extension is there. There is work on  a platform specification which defines that all risk five Unix style platforms shall have  the C extension. The ISA has three privilege modes. Machine mode is the highest level.  Microcontrollers usually only implement machine mode. If you want to run Linux or PSD, you  need all three modes. The 32, 64 and 128-bit ISAs are actually independent from each other.  That's probably strange to people who are used in inter architecture where every 64-bit  CPU also runs 32-bit code. That's not the case on risk five. We have a similar effect  on ARM64. ARM64 CPUs can optionally support 32-bit code but they don't have to. And actually  there's quite a bit of ARM64 servers which only run 64-bit code and no 32-bit code.  Short side note on Meltdown Inspector. In discussions about risk five, often people claim, yeah,  risk five is the solution to Meltdown Inspector. It's an open architecture. We won't have any  problems with that. It's just nonsense because Meltdown Inspector are implementation bugs.  They are not a bug in the design of the instruction set architecture but in specific chip implementations.  So why currently we have no risk five chips which do speculative execution which is the  base for Specter and Meltdown. So currently there is no risk five chip that's vulnerable.  Nobody can guarantee that that won't happen in the future when we get chips that do speculative  execution. So now we have an ISA but if we want to use an ISA we would like to have hardware  or at least otherwise run code. There are multiple options. We can do QM emulation. QM  has support for both user space as well as full system emulation. We have CPU designs  which can be instantiated in field programmable gate arrays. I'll get to that later on. And  we also have real CPU chips. Last year at FOSTA we had the presentation of the SciFi  Freedom U540 which is the first Linux capable risk five chip in the world. There is the  lowest project which is working on designing a community stock but that's still a lot of  work and until we actually have those chips on our desks will probably take three, four,  five more years. Doing chip design is hard and well it needs work and needs to be paid.  Then there's Shakti. Shakti is a project in India which aims at designing a full family  of risk five chips from small IOT style embedded stuff up to super computer hardware and the  Shakti team has recently actually taped out the first locally produced Linux capable chip.  So what you see here is a picture of actual risk five hardware. The left one is the prototype  that had been presented at last FOSTA. The right one is one of the early G-Lipsy development  systems. That is the prototype chip. That is an FPGA board which acts as south bridge  and provides PCI Express and that's a PCI Express NVMe SSD. So why porting Debian to  risk five? From a physical point of view Debian and risk five are perfect match. We have open  source hardware, we have open source software and we would like to combine those two. There  have been efforts of porting Debian to open risk but those have not been successful because  of the GCC problematic because we would have shipped different GCC versions on different  platforms which is something that Debian does not do. Debian uses the same versions on all  platforms so that was not an option. The risk five ISA is probably the first Open ISA  that has a realistic chance of actually gaining mass market traction. There are a lot of companies  supporting risk five right now and things in the semiconductor industry are slowly changing.  It's become slowly possible to actually have community led chip production. It's still  very much expensive but things are changing in the industry and within a few years it  might be possible to actually have community led chip designs mass produced. The first  work on porting Debian has started in early 2015 and at that time a lot of stuff was still  a movement. BinyoTills GCC were changing every day. G-Lipsy was in its early infancy, the  Linux kernel as well. Things have been changing about every two days and code generation actually  got incompatible from one week to another because of changes in the compiler in the  community. Which meant, well, if I build stuff today I probably cannot link it against stuff  built into weeks which is kind of sad if you want to do binary distribution. Then there  was somewhat of a culture clash between people from the hardware design world and from the  software design world that took say half a year to sort all that out. Another problem  was at that time we had no QEMO support so there was only Spike. Spike is a CPU architecture  emulator which emulates the basic RISC-5 CPU. It only emulates a block device and a dump  serial console but no network. So think you want to put some distribution, you build a  root file system with something, you want to compile something and find, okay, I need  another bit of software. Well, normally you just download it but if you have no network  that's kind of difficult. So shut down emulator, unmount block device, mount block device on  host, copy files in, unmount block device, start emulator again, start working. If you  have done that 20 times you want something else. Yeah, due to the ABI breaks and the  incompatibilities in the tool chain all early attempts at actually building packages have  not been successful. So both Fedora and Debian developers have chosen instead to work on  getting stuff upstream and getting stuff in utility GCC, GLEB C kernel stabilized so that  we have a stable IBI and can be sure that stuff that we built today still works tomorrow.  That included some modifications to the linker for Debian-style multi-arc support that included  getting an agreement about using device tree for hardware description similar to what we  use on ARM and on PowerPC and recently also on MIPS. And well, things were looking quite  well until early 2016 and we had some form of déjà vu because we wanted to get GCC support  upstream and the people who wrote the GCC support were happy to do a copyright assignment.  Unfortunately some of them had work contracts with the University of California which gave  the UCB the copyright in some of the contributions. And UCB was happy to license the stuff under  free license under GPL and the BSD no problem but they were not willing to agree to a copyright  assignment. So we were exactly in the same situation that the open-risk people have been  facing beforehand and things were looking rather dire. It took nearly a year to get  the legal stuff sorted out. So end of 2016 the stuff could actually go upstream and from  then on BinyoTiltz and GCC went rather fast. Just a few weeks after the legal stuff had  been sorted out BinyoTiltz went upstream three months later GCC was upstream. Then came GILIPSE  and kernel. The GILIPSE and the kernel are very much dependent on each other because  they use low-level interfaces and getting that specified out so that the GILIPSE people  were happy and the kernel people were happy took nearly a further year from there on.  So effectively at last forced them exactly one year ago. We were there that we had toolchain,  kernel, things were working, things were upstream. We could start with a bootstrap or the distribution.  There were some tools that were still missing, GDP Linux support is still missing. We have  bare metal support but not for Linux debugging. As you have heard probably in the talk before  LLVM and Clang support is still work in progress. We hope to sometime this year have a release  that will probably work for distribution users. Java has been a problem. We have Java support  now but only interpreter support not just in time compiler support. So Java works but  it's dark slow. Getting JIT support is still quite a bit of work. Rust depends on LLVM.  Something that to my knowledge nobody is working on. Okay, somebody is working on GOLANG. And  then there are of course other languages and other compilers. V8 is the JavaScript engine  for Node.js which is also not working yet. So now we have compilers, we have binutils,  we can build code, we can build packages. But we are starting from scratch. We have nothing  for the RISC-5 architecture. So how do I get a distribution from Thiner? We have nothing.  Well I need a cross compiler. So I run a compiler on a PC but generate code for RISC-5 and make  use of the WMulti architecture support which allows us to have code for multiple architectures  within one root file system. So I can gradually generate packages for new architecture. That  of course requires getting RISC-5 support into the true-chain packages that we had in  Debian. But as the support had just been released a few weeks ago, the binutils GCC packages  in Debian of course did not yet have RISC-5 support. So the first step was actually packaging  new versions of all that and getting them into experimental. Then how does one start  in bootstrapping a new architecture? I need a base set of packages. So which packages  and how many are that? Well Debian has package priorities and the packages with the priority  required are the base package set. And while priority required, okay that's easy, just  a handful of packages, that's 55 packages, that's no problem. Well actually it is because  those packages have dependencies, they want libraries. And those libraries have dependencies  themselves and to be able to build those libraries, I needed a lot of other stuff. So I need dependencies  of dependencies of dependencies of dependencies of dependencies of dependencies to build stuff,  which ends up in several hundred packages I have stopped counting at nearly 400. One  of those problems is that, for example, if you have source code that uses mason to build,  mason uses python and building python is a problem in so far as python has lots of dependencies  because python has modules for a ton of stuff and to build python, the python package, you  have to have all that stuff. So that gets a rather large dependency chain. Dependency  issues are twofold, one are deep dependency chains, as I've just shown an example. To  build one of the command line base packages, we had to cross build some 80 or 90 other  packages just to get the build environment set up to be able to compile a single package.  Another problem are circular dependency chains, which is where the cat chases its tail. Packages  in the base system are, for example, audit. Audit requires open add up for building. Open  add up in turn requires sarsl for building. Sarsl requires pan for building and pan,  okay, it's audit for building. So the cat has just found its tail. How to resolve that?  We have to build packages with smaller feature sets to just remove certain features from  the packages to break the cycle. And doing that by hand is rather tedious. So Debin  has a mechanism for that that is called build profiles. So you can build a package with  different feature profiles and during the bootstrap process we actually have added several  build profiles to the number of packages to be able to break those dependency cycles.  What you see here is a dependency graph of Firefox just to give you an impression. That  on top there is the Firefox source. The boxes that are led to by the brownish lines are  direct build dependencies of Firefox. Each of those build dependencies has runtime dependencies  which are all those blue lines going to different packages. And that's just the first level  of dependencies because all of those blue packages have dependencies on their own.  Which have runtime dependencies. So if you look at that graph you can probably imagine  that building Firefox comes very, very, very late in the bootstrap process.  I've said that we've started cross building because we had no native code. And cross building  is not as easy as doing native builds. Several package which built finitely don't cross  build properly. There are differences in cross build support in different build systems.  People often say GNU Auto Tools, old stuff, ugly stuff and just leave me alone. But GNU  Auto Tools has one major advantage. Cross building effectively works out of the box.  Effectively everything built with auto tools just cross builds. That's unfortunately something  that we cannot say about many CMake and Mason based projects. Both CMake and Mason have  a theory support for cross building. But many packages that use Mason and CMake don't make  use of the infrastructure that those two provide. And in practice we had to fiddle around with  many of the Mason and CMake using packages to actually make them cross build.  Pearl is, well, just strange. Pearl claims to be cross buildable. Well, the way pearl  cross building works is that the pearl configure script requires an SSH connection to a system  already running the architecture I want to build for and then run the configure script  natively on the architecture which obviously does not work in a bootstraping scenario.  So the only way to build pearl is actually build all the rest. So I have a native compiler  and then build pearl natively. Another common problem is generators. Make files sometimes  compile code which they then execute to generate further source code. That works on a native  build so if the compiler is running on a PC and the binary I'm creating is for a PC, no  problem with that. But in the cross build setting I'm running a compiler on a PC but  generating code for RISC-5 and the PC cannot just execute the RISC-5 code. So that does  not work. Proper build systems should take care of that and in a cross build setting  use the proper compiler for the code generators. Another option if one has QMEU support is  using QMEU userline emulation that helps but we didn't have that in the beginning.  Another thing is that many upstream packages don't properly separate between host arch  and build arch tools. So if I for example want to call package config to get the GCC  parameters for linking to library, those are at least somewhat architecture dependent so  I need the package config for the correct architecture and many make files just don't  take that into account and always call the package config for the architecture the compiler  runs on which is wrong if I'm cross compiling. And then there are some cases of packages  that are not multi arch co-installed with themselves that can happen. I'm using a tool  to build a package which has a library dependency and the code I'm trying to compile for RISC-5  also requires the same library in the RISC-5 version. With most libraries in Debian it's  possible to co-install both at the same time but there are libraries where that doesn't  work or doesn't yet properly work so we had to work around that. Then there's of course  general portability stuff. Data type sizes are architecture dependent. How long is an  int? Is an int 16 bits, 32 bits, 64 bits that changes from architecture to architecture.  There's endiness so the way numbers are represented in memory. A very common occurrence is that  upstream ships outdated configs up and configs out of confiles. The FSF recommends that  auto confuses should always regenerate configs up and configs up from current upstream so  that new architectures automatically get supported. But many upstream authors just put the versions  they have used when building the release table which are old and they don't know about RISC-5  so we had to replace those. Another thing that's rather common is atomic support. There is  a tiny but important difference how to call, how to link in the pthread. There is the dash  pthread flag to the compiler and just dash LPthread which just links the library. Problem  with that is on PCs just linking the pthread library is enough that works. That's the case  for x86 and amb64. That's not the case for quite a bunch of other architectures. And as  most developers probably develop on PC hardware they just don't look at something like that  so we had to patch quite a number of packages for that. And then there are packages that  actually require hand crafting header files for each new architecture. LibGPG error is  one of those examples. Then there's type constraints. We have atomics but on RISC-5 atomics are  only supported on native word sizes not on smaller objects. The PC architecture allows  using atomics on arbitrary object sizes. That's not the case on RISC-5. We have lipatomic  which abstracts that away so if people use lipatomic that's not a problem. But again  many abstract projects just assume that atomics work on arbitrary sizes because that's just  the case on PCs. But that's not true for all other architectures. And then there is of  course stone-etched stuff like looking in the x11 sources which doesn't make decisions  based on properties like even in 32-bit then do something. If you look into the x11 sources  there's really if architecture is through then list of code. If architecture is bar  then list of code. If architecture is bar then list of code. And so we had to write  just new code for that. We tried to get it upstream but that didn't work because the  x11 developers don't want to add code for new architectures because they say x11 is  in maintenance mode and we don't want new architectures upstream. And then of course  there's the problem of compiler support. We like Rust. So building for example Firefox  and some other stuff currently does not work because we don't have a working Rust compiler  yet. Yeah, doing all the package bootstrap, getting the ordering right, patching packages  is rather tedious and of course we would like to have that automated. For automating that  is way more complicated than one would expect at first sight. A Debian developer has some  years ago written his master thesis about bootstrapability issues which has helped a  lot and there's a tool by Hamilton Grone which is called Rebootstrap which at least  as far as possible automates the early bootstrap. So getting new tools, getting compiler, getting  various new tools, getting several basic libraries which we were very happy to have.  So now we have packages but we want to have a proper distribution so we need to get those  packages into Debian infrastructure. Debian has two major types of architecture. So regular  architectures which have regular stable releases, get security support for stable releases and  we have ports architectures which is somewhat of the kindergarten of Debian architectures.  New architectures usually start in ports because they're incomplete, there might be stability  issues at the beginning and bugs in ports architectures don't influence regular architectures.  So just unstable testing, stable migrations on regular architectures still runs even if  a package is broken on one of the ports architectures. Then for ports architectures we have a bit  more freedom. For example the ports architectures have an additional suite in the Debian archive  which is called unreleased which is allowed to carry architecture specific patches which  are not in the main package source. This is only for temporary stuff so the aim is that  having unreleased empty, that's the final aim. But while we're working on that there  is some stuff which we currently can only keep in unreleased.  So that's where we are right now, we have a bunch of packages. We aim at becoming a regular  Debian architectures sometime in the future but that requires being able to build about  95% of the archive and we are not there yet. This is a package build graph, the gray line  here has been the percentage of the RISC-5 packages that have been built. This graph  is several months old, the spike that you see here has actually been created by porting  the Haskell compiler. At that point in time we got Haskell bootstrapped and built a bunch  of Haskell packages which gave that RISC in available packages. Unfortunately the number  of packages actually has dropped down again in the meantime because we have some packages  which we had been able to build in the past but which we cannot build anymore. One of  the problems is that several upstream sources that have in the past been using CRC++ are  moving to Rust. So we could build the old CRC++ based versions but we can't currently  build the new Rust based versions so we had to drop out some packages.  Another problem is the QTE ecosystem which in the past has had its own C++ parser which  has now moved to using LLVM which brings us to the problem that we don't yet have LLVM.  We are currently at 85, 84 or 85% of packages which provides a rather usable system but  of course it's not everything yet. To become a release architecture, an officially supported  stable release architecture, we need to have the app installer support that's work in progress  but not yet finished. We need to have enough buildies with redundancy. Buildies are the  package builders they've been using to automatically compile packages for all architectures. We  need to have everything in infrastructure managed by the Damian system administrators  which have requirements so they want great multiple server-grade hardware, remote management  capabilities which is somewhat difficult with small chip prototype development boards.  So that's also something we hope to get within the next years but we haven't yet. And of  course there need to be people to take care of the architecture. Okay, we have those.  The Damian installer support is work in progress. It's possible to build a Damian installer  for us five from Damian installer Git but it's not really usable yet. We have two issues  that are still being worked on. One is that we have problems with LVM tools. Somebody  is working on those. That's the last big blocker to get the Damian installer released.  Another thing is that we currently don't yet have bootlidder support. The UBoot port for  us five is still rather new. Just yesterday, two days ago, the first OpenSBI code base  which we would need for that has been published. So that's something that I will look into  into the next weeks. Then there is the topic of 32-bit support. Currently we only support  RV64, 64-bit risk five because that's where most of the work has gone in, where we have  hardware. 32-bit support is still work in progress because we don't have 32-bit support  in Glypsy yet and the kernel support for 32-bit is also not complete because that needs to  be coordinated with Glypsy. And we have the problem that you might have heard of the year  2038 problem that we have a time type overflow in a few years. And we want to describe to  do that the right way, but that requires infrastructure in the kernel and in Glypsy,  which hasn't been there in previous Glypsy series, which is just now getting into Glypsy.  And we didn't want to release a 32-bit port that would be binary incompatible in a few  years because we would have maybe I break to handle the year 2038 problem. So that takes  a bit. Fedora and Rathat probably won't release 32-bit ports. Debian might do it, we'll see,  if interesting hardware becomes available for 32-bit platforms. The way such hardware  could become available are small FPGA implementations. Designing CPUs on field programmable gate  arrays is a common technique in commercial CPU development. But in the open source field,  that hasn't been done very much because for all available FPGA types, one had to have  proprietary compiler tool chains, FPGA tool chains from the big FPGA vendors, and while  open source developers don't want to build this stuff based on proprietary tools. In recent  years there has been a lot of effort to reverse engineer the FPGA bit stream configuration  format and to implement free tool chains for FPGAs. We actually have one that's fully  working, that's Project ISTORM, which is packaged in Debian. So you can actually implement a  CPU with tools in Debian and run it on an FPGA. There's Project Trellis, which is currently  working in progress. There's a talk tomorrow, just upstairs from here, from the Project  Trellis project leader about his support for the ECP5 FPGA series. What's interesting  with the ECP5 is that it's about 10 times the size than the small ISTORM that we have  supported right now. Problem with the size is I can implement a CPU on a latest ISTORM  but that's more microcontroller class, something Linux capable with memory management unit.  In that size is very, very difficult. David Shaw has actually implemented an open risk  CPU on an ECP5 and is planning also to do a risk 5 implementation on one. Then there's  Project X-Ray for even bigger FPGAs from Xilinx that's in rather early stage. Things  are moving forward but I wouldn't hope my breath while waiting. That will probably take  one or two more years until we have something that finally works there.  Well, FPGAs are nice. I can actually in place update my CPU. If I have a better version  of my CPU, okay, compile it, place in the new CPU. But FPGAs have disadvantages. The  clock rates that I can achieve are rather low. So if you get 200 megahertz that's already  rather fast, more realistic on cheap FPGAs is something about 50 megahertz which by today's  standards is just slow. Getting fast chips is rather expensive and compared with actual  mass manufactured Azix they use a lot of current. Another problem is getting memory. Modern  memory interfaces are very complex and attaching modern double-datter rate memory to an FPGA  is difficult. That requires a specific file layer that requires an appropriate memory controller  that's not easy. So we have currently only the choice either use memory that's easier  to address but it's slower and it's more expensive or if somebody manages to reverse engineer  the common DDR5 layers in the bigger FPGAs we might be using standard DDR memory but  that will take time. Well, we have FPGAs but there are also projects for Azix. I have already  mentioned the LowRisk project which is working on an RV64 community sock. The current development  version of the LowRisk sock runs on an FPGA and it actually runs Debian. The software  development for that chip is actually using Debian. Then of course if I want to mass produce  a chip there's not only digital logic in it. The CPU itself is digital logic but I need  voltage regulators, I need analog digital converters, I need a random number generator, I need a  brownout detection to make sure that the voltage doesn't drop too much. So there's a lot of  analog technology which you also need to produce such a chip. There's a spin-off of the Universidad  Industrial de Santander in Colombia which is working on providing open source licensed  analog components for such CPU. There's also an interesting project. Several people will  say that's just insane but nonetheless I find it interesting. The Libre Silicon Alliance  is a group of people from the chip design world which are trying to define a standard  silicon chip manufacturing process. Currently you have one problem. You want to produce a  chip, you go to one chip fab and say okay here's my design, build that for me. You have  to use a set of standard cell libraries from your fab. You're not allowed to disclose how  those look like. So if you want to build your chip in another fab, you can't just take your  design to another fab. You have to redesign your chip with their standard cell library.  There is no portability between fabs and the Libre Silicon Alliance is working on defining  a standardized process that is actually transferable from one fab to another. They've started  very, very small. They currently have done their first prototype chips which are based  on one micrometer node size. That's technology from the early 80s. So nothing you could build  a modern CPU in but that's a long-term project. They're estimating a time frame of perhaps  10 or 15 years. So nothing for tomorrow but nonetheless interesting. And then there's  chips for Makis which is a project to improve the software side for ASIC design which also  has a talk tomorrow upstairs. They are aiming to produce a community-funded small CPU. This  is 16 bit, 32 bit, 68K, Z80 type stuff and have actually managed to get the design done  but in the first round the funding for the actual mass production of the chip didn't  work out. They're trying to do another run and we'll see how far they get. So that's  my talk so far. Questions?  So you said at least twice that in some cases Rust is a problem. And Rust has a back-end  of the Rust specific patches of LLVM because even if you have LLVM. It still needs to be  ported, yes. It needs to have the Rust specific patches to LLVM because Rust community also  has a set of patches which they didn't get upstream to LLVM. So even if you were in a  situation where you had LLVM you don't have necessarily Rust on the LLVM. Okay. I try  to repeat that because the people of the stream probably haven't heard the comment. So to  get Rust one does not only need to have LLVM working but there are also Rust specific patches  to LLVM which also need to be ported which would also need to be done.  To be upstreamed.  Yeah. To be upstreamed.  And the question is how is Debian handling those Rust specific patches for LLVM?  The question was how is Debian handling those patches currently not at all? We haven't actually  looked into that yet.  Okay.  Further questions?  Sorry. I just didn't understand that acoustically.  The question was Debian has rather recently bootstrapped AMP64 and how much of the bootstrapping  procedure have we been able to reuse for them in a Rust 5 bootstrap? Actually quite a bit  during the AMP64 bootstrap several packages have gained build profiles to make dependency  cycle resolution easier and that has actually helped a lot. The Rust 5 specific stuff of  course can't take anything from AMP64 but the infrastructure has gotten a lot better  and there are people like Helmut Grohner who has written the reboot strip tool that I  had mentioned are working permanently on making bootstrap ability better by fixing cross  architecture bugs by adding more build profiles so that definitely has helped.  I actually don't know. That has been handled by lawyers behind closed doors and I have  no information about that.  Start with Debian. I just repeat that. How was the legal problem with the copyright assignment  of the GCC code to the FSF been resolved? I really cannot tell that because that was  something that had been handled between the Rust 5 foundation and the University of Berkeley  and they haven't told the public in which specific way an agreement was reached so I  can't tell anything about that.  I totally have sympathy with the work you have been doing. I have just repeat for the  stream business. The question was that the base package set appears to be growing compared  to past ports when 32-bit ARM had been ported the base package set had been something around  200 something packages. Now we have reached nearly 400 and which problems have been the  major pain point in porting. The first major pain point has been Perl, the lack of cross  bootstrap ability of Perl because all of the packaging infrastructure in Debian is based  on Perl. You need Perl for almost everything. Getting Perl ready has been a real problem.  The second one in my view has been Mison but perhaps where is Manuel? Perhaps you can  comment on that?  Can you talk a bit louder? Just don't hear you.  I'm sorry. The other week, one problem was the GNC which was in experiment that was where  we initially had problems with the bootstrap. Then the one that I remember Perl was a problem  which was one of the biggest problems but the other one was still many packages in the  bootstrap in the first example for utilities don't look very properly because they need  to help to manage for example to generate demand pages. This has to run natively so there  are many small changes that need to be made to get the base set. In the media there were  patches for users but they were not accepting the time for the maintainer or they were running  behind. There were many problems with the new server bootstrap.  I'll just repeat that for the people listening on the stream. One of the pain points in the  early bootstrap had been that Gilepse for his craft had only been in experimental because  we had to use a newer version than all the other gaming architectures and that caused  some compatibility problems in the early bootstrap. Then one problem has indeed been core utilities  because core utilities help to man to generate demand pages and help to man does not work  in a cross setting. That took quite a bit of work arounds that should be resolved in  a newer core utility version than we had at that time but when we did the bootstrap that  was indeed a problem.  That's of course another problem when one builds an architecture in emulation in QAMU  and one has to handle a bug. The problem is the bug in the code I'm trying to debug or  is the bug in the emulation I'm using to run the code. We had some cases where the code  actually was fine and the bug was in the emulator which of course has needed time and a lot  of debugging so having real hardware is of course better but when you start such a port  of we only have emulators I suppose the ARM64 port had the same problem you started with  the original architecture emulator. So that's something that's nearly unavoidable if you  do an early bootstrap. That is easier if you wait with bootstrapping until the architecture  has already brought use but of course you want to distribute software early in the release  of new architecture to make the architecture actually usable.  We have tried to get the cross compilation patches upstream in some cases that has worked  and they were accepted in some cases they weren't because some people consider cross  build support in maintenance burden because you have to think of things of which you don't  have to think when building natively and well some upstream authors don't see bootstrapping  in new architecture as a relevant problem for their software. That's unfortunately but  that's reality. Yes we carried the patches in the Debian packages but we would have preferred  to have them upstream but they weren't accepted just because the upstream developers consider  X11 to be in maintenance mode. They don't want feature additions even if it's just a new  architecture. Any more questions?  We have a CI system running reboot strap, Hamlet grown as base bootstrap tool which  works with cross building and we have Jenkins jobs doing that. If you have packages that  are part of the base systems it's helpful to look at the Jenkins results and see if  your stuff fails. Debian has portal boxes for multiple architectures on which you as  a package maintainer can log in on each architecture that Debian supports and try to build it.  We have cross compilers in Debian for all architectures that we support in Debian. The  Debian packaging tools actually support cross building packages. So we can just say sbuild  dash dash host arch is riscribe64 and it runs a cross compiler and tries to cross build  your package. So if your package maintainer it's rather easy to check whether your stuff  is cross buildable. That's more of a problem. Upstream is more of a problem. We had some  discussions yesterday evening about ways to provide risk 5 machine instances to upstream  developers to enable them to test build their code and debug issues on native hardware.  That's being worked on. I just repeat that for the stream. The common was that we should  try to avoid bootstrapping riscribe 32 bit because other 32 bit architectures in Debian  are already struggling with keeping up and building large packages. One known problem  is building stuff like a debug build of Firefox which is a problem on 32 bit architectures  in fact. I would just like to make a bit of a counterpoint to that. I'm working on the  FPGA tool stuff and RV64 GC is a pretty big ISA because you basically got to have hardware  that is something that can very nicely fit on FPGA and run quite well. Okay I'll just  repeat that for the listeners on the stream. Counterpoint to that argument when one is  targeting CPU implementations on FPGAs 64 bit architectures are a problem because they  use a lot more FPGA resources than 32 bit architectures way more than double of 32 bit  architectures and getting a 32 bit riscribe CPU Linux capable on an FPGA is quite doable  even on smaller not tiny but smaller scale FPGAs but 64 bit CPUs is a problem in resource  usage. Any more questions? Okay thanks.
Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_0_47.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_48_179.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_180_1331.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_1332_3443.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_3444_5555.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_5556_5891.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_5892_7007.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_7008_9803.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_9804_12131.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_12132_13163.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_13164_14207.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_14208_16163.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_16164_16835.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_16836_18491.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_18492_19775.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_19776_20939.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_20940_22079.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_22080_23183.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_23184_24047.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_24048_25943.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_25944_27347.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_27348_29327.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_29328_31247.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_31248_32327.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_32328_37319.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_37320_39815.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_39816_41987.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_41988_43127.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_43128_45563.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_45564_47663.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_47664_48863.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_48864_51851.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_51852_57155.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_57156_61643.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_61644_61691.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_61692_61787.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_61788_61943.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_61944_62087.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_62088_62687.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_62688_62735.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_62736_62843.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_62844_63743.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_63744_63863.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_63864_64835.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_64836_65039.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_65040_65159.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_65160_65867.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_65868_66059.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_66060_66815.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_66816_67343.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_67344_67403.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_67404_67739.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_67740_67787.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_67788_67919.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_67920_69119.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_69120_69995.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_69996_70043.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_70044_71495.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_71496_72395.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_72396_72467.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_72468_72587.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_72588_73019.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_73020_73487.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_73488_73691.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_73692_73739.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_73740_74291.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_74292_75095.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_75096_75635.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_75636_78419.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_78420_78491.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_78492_79187.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_79188_79235.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_79236_81659.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_81660_82559.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_82560_82739.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_82740_82895.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_82896_82943.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_82944_83087.png Porting_Debian_to_the_RISC-V_architecture_Tales_from_a_long_quest_EjJZb-Ayeys_83088_83229.png