Debian GNU/Linux port for RISC-V 64-bits

Transcription

1 Debian GNU/Linux port for RISC-V 64-bits Manuel A. Fernandez Montecelo > :: May 7-10, 2018 Barcelona Supercomputing Center && Universitat Politècnica de Catalunya

2 Outline Goals of this project Why a Debian Port for RISC-V? What is Debian? What is a Debian Port? The Plan History / Making Of (1st and 2nd bootstrap) Current Status How the RISC-V community can help... and what are the benefits Thanks Questions / comments 2/46

3 Goals of this project To have Debian ready to install & run on RISC-V based systems Fully Not integrated with Debian infrastructure a one shot, but continously updated With time, to make it as well supported as the big ones i386, x86_64 ( amd64 in Debian), arm64, ppc64el 3/46

4 Why a Debian Port for RISC-V? (1) Personal reasons: Interested in both Debian and RISC-V I m already a Debian Developer I like RISC-V design and goals, started following in 2014 They are a good fit, philosophically and technically And I would like to improve and help to grow both projects I worked previously in the OpenRISC or1k port... No and had lots of fun!! other major GNU/Linux distributions in sight (... by the time that I started, 2014~2015) And ultimately, I would like to run Free Software and Debian when I get my own RISC-V based hardware 4/46

5 Why a Debian Port for RISC-V? (1 bis) Personal reasons: Interested in both Debian and RISC-V I m already a Debian Developer I like RISC-V design and goals, started following in 2014 They are a good fit, philosophically and technically And I would like to improve and help to grow both projects I worked previously in the OpenRISC or1k port... No and had lots of fun!! other major GNU/Linux distributions in sight (... by the time that I started, 2014~2015) And ultimately, I would like to run Free Software and Debian when I get my own on the now-existing RISC-V based hardware 5/46

6 Why a Debian Port for RISC-V? (2) Technical Debian and philosophical reasons: welcomes and already supports many ports Including similar architectures, active now or in the recent past, some listed from RISC-V Genealogy : MIPS (mips, mipsel) Hitachi SuperH (sh4) IBM PowerPC (powerpc, ppc64, ppc64el)... and DEC Alpha, SPARC (32 and 64), older ARMs, PA-RISC Similar or compatible goals, and methods, e.g.: Aiming for openness, freedom Both based, built upon same tools GNU toolchain among others, Linux, FOSS ecosystem Striving for good technical solutions over other considerations 6/46

7 What is Debian? (1) The Project: A community of individuals Mostly No... volunteers overall or significant control by companies who care about Free, Open-Source Software Goal: to create a full, comprehensive Operating System Large set of software packages, coherent and well integrated stable releases every ~2 years (also used as rolling release ) Keeping Software Freedom as a core goal Manifesto:... developed openly in the spirit of Linux and GNU... Social Contract Debian Free Software Guidelines (DSFG) 7/46

8 What is Debian? (2) Mostly known as a GNU/Linux distribution Started First by Ian Murdock in 1993 stable release in 1996 One of the major flavours (.deb packages) More than 27k source packages in 2018 Basis of many derivatives ( downstreams ) Ubuntu, Raspbian, SteamOS, Knoppix, gnewsense, Linux Mint Debian Edition, Tails......which also supports other kernels Currently: FreeBSD and GNU Hurd 8/46

9 What is a Debian Port? (1) In short, ABI of the combination of {computer arch + OS kernel + libc} Computer Many, Kernel architecture: currently and over the years (details in next slides) + C library: Mostly Linux + GNU libc (if not mentioned explicitly) But also: kfreebsd, FreeBSD kernel + GNU libc (amd64 and i386) GNU Hurd + GNU libc (i386) C library: GNU libc in all existing ports within the Debian infrastructure But some people are interested in experiments e.g. Linux + musl (libc) 9/46

10 What is a Debian Port? (2) Three kinds of ports: Outside of Debian infrastructure Some derivatives are arguably an external port e.g. Raspbian, mostly recompilation / optimisation for Raspberry Pi Anybody can start one of these without official help or coordination with Debian But often there s collaboration in one way or another Unofficial Not in stable releases, but hosted in Debian infrastructure Officially Part Ports they / unsupported supported of the stable releases and fully supported don t born fully supported work their way up to it 10/46

11 What is a Debian Port? (3) Criteria for officially suported ports: Be able to build almost all of the source packages Have enough people responsible for it addressing Have etc. And issues during full Stable release cycles hardware available, redundant, well managed, in return: Become part of the stable releases and have full support for all packages (all ports) For 3-5 years ( stable release lifetime) Including security support for all, not only a core set of packages 11/46

12 What is a Debian Port? (4) Unofficial When or unsupported ports: they don t qualify as official for some reason Hardware not available Not enough people behind Many packages fail to compile e.g. missing Java or Haskell ecosystem (no working compiler), no GUIs, but are hosted in the infrastructure: Can be downloaded / upgraded from *.debian.org Secure, cryptographically signed Get continous updates of software packages When contributors upload new versions to the archive, they are compiled automatically for all ports, within minutes/hours 12/46

13 What is a Debian Port? (5) Currently active: Fully supported ports, officially suported : amd64 (x86_64), i386 (targetting i686 nowadays) arm64/armel/armhf, mips/mipsel/mips64el, ppc64el, s390x Not well supported: Old ones with decreasing interest or available hardware: alpha, ia64, hppa, m68k, powerpc/powerpcpse/ppc64, sh4, sparc64, x32 (x86_64 with ilp32) and new ones Retired: Supported once, but not in the infrastructure anymore: arm/armeb (old 32 bits ABIs, LE/BE), sparc (32 bits), parisc, s390 (32 bits BE)... 13/46

14 What is a Debian Port? (6) What e.g. maintainers of packages see: for Firefox: 14/46

15 What is a Debian Port? (6) What e.g. maintainers of packages see: for Firefox: Port/Arch Name Build Status Build machines, logs, historic, etc. 15/46

16 What is a Debian Port? (6) What e.g. maintainers of packages see: for Firefox: Port/Arch Name Build Status Build machines, logs, historic, etc. riscv64 16/46

17 The Plan (1) Broad steps: 1)Bootstrap and create viable, basic OS disk images 2)Get it to the state of unofficial / unsupported, until all criteria for stable are met Prepare infrastructure (e.g. auto-builders), wiki, doc, etc. Import bootstrapped set in the infrastructure Fully rebootstrap Build as many packages as possible And make sure that they work Keep the port running, in good state 3)In the future, when feasible, official as well supported as main ports 17/46

18 The Plan: Software decisions (2) Software-wise, the target is to have a port with: Linux kernel GNU libc GCC-based toolchain LLVM available (when ready), but not the main toolchain Rationale: all current and well supported Debian ports target these Userland ports including is basically the same for all Debian those with other kernels 18/46

19 The Plan: Hardware decisions (3) Hardware-wise, the target is 64-bit little-endian Both 64-bit and LE have been the focus for general purpose computing for years Debian (Linux/Unix)-capable RISC-V hardware implement this Simply, it was announced (and then became true) the most popular target capable of running general purpose OS Dev boards or servers that might become available in the next few years for end-users, likely 64-bit LE too RV64GC As it s the default flavour recommended by the people most involved could be reverted if needed (e.g. popular hardware without it)...or have both flavours 19/46

20 The Plan: Not Considered (4) Why not 32-bit or 128-bit variants: RISC-V side: Design, toolchain and simulator support have not been explored as deeply for 32-bit, support lacking in some areas RV32 hardware that appeared over time not ready for general purpose OSs...and 128 is simply not realistic at this time But maybe in the future? :-) Debian side: 32-bit ports already struggle to get large packages e.g. Firefox or Chromium, LibreOffice, KDE Desktop This problem will only become worse with time Embedded Neither built / IoT / etc. likely not interested Debian nor other full, general purpose OSs 20/46

21 The Plan: Where we are now (5) Steps: 1)Bootstrap and create viable, basic OS disk images 2)Get it to the state of unofficial / unsupported, until all criteria for stable are met infrastructure (e.g. auto-builders), wiki, doc, etc. Import bootstrapped set in the infrastructure Fully rebootstrap Build as many packages as possible at this point now Prepare And make sure that they work Keep the port running, in good state 3)In the future, when feasible, official as well supported as main ports 21/46

22 History: First Bootstrap (1) Started on Nov 2014 Frequent pauses in 2014~2016: Waiting for Specs ready Waiting for Upstreaming of toolchain, Linux, etc. not impossible to progress, but very inconvenient to manage with frequent changes Waiting for availabity of: Emulators / simulators (mainly, Qemu), matching specs Toolchain implementation, matching specs Different components of the toolchain to work well with each other 22/46

23 History: First Bootstrap (2) In mid 2016, achieved a functional base Debian system By the 4th Workshop at MIT, 300~400 essential packages built: GNU coreutils, make, gawk, bash, tar, gzip, bzip2, xz-utils, flex, bison, wget, curl, less,... media codecs (png, jpeg, flac, ogg, opus, xvid,...) dpkg, apt, gnupg, openssl, nano, text-mode web browsers some X-Windows packages many libraries / supporting packages not all of them interesting per se, but needed by others (e.g. XML libraries, ncurses) Stable enough to build successfully and cleanly hundreds of packages in native mode (qemu-system) 23/46

24 History: First Bootstrap (3) In late 2016 the userland ABI changed with major breakage Both Debian and Fedora (which started a few months before) stopped bootstrapping activity In April ceased to a halt 2017, published the packages built by then About 1k in total They were not usable with the toolchain after the change, so only for historic interest or private tests Hiatus until late 2017/early 2018 Waiting for upstreaming of the support for Linux and GNU libc and final freeze of ABI 24/46

25 History: Second Bootstrap (1) Started ~25 when GNU libc was upstreamed Feb~5 March: Cross-build base set of packages packages included in Debian only not taken from github.com/riscv create system to run under qemu-system ~5~13 March: First native build Use cross-built system to build packages again natively (under qemu-system) incl. running tests when available and fixing some problems early on ~13~23 March: Second native build in clean env. Isolated environment similar to production auto-builders starting from minimal chroot, installing deps as necessary, etc Also, set auto-builders to use permanently for the port 25/46

26 History: Second Bootstrap (2) (cont.): 23~25 March: import this 2nd decantation into the debian-ports infrastructure This is the seed for a basic Debian system capable to build the rest of Debian Caveats: Building other packages need that they support the arch if necessary, not always the case There are many dependency cycles that have to be broken ~25 March onwards (still at it): attempt to build the whole archive Add support when necessary/missing, break dep. cycles Fix packages with tests failing Report bugs to Debian maintainers and upstream, etc 26/46

27 Current status in a single graph (May 1st 2018) 27/46

28 Status in detail (1) In number of packages, ~75% there More than 9k of ~13k arch-dependent packages built Also available 10~15k packages which are independent of architecture These are e.g. scripts, many modules from Python, Perl, definitions of documentation (e.g. Docbook), etc. Some of these don t work if they need arch-dependent packages along their long dep chains, and are unavailable As time goes on, progress slows down: Often bigger packages are left, take hours/days to build, have more complex dep chains to untangle... The more % built, the more has to be rebuilt when new versions are uploaded by maintainers e.g. several versions of GCC per week 28/46

29 Status in detail (2) Packages Most available include: of server-side packages e.g. Apache Complex e.g. 3D graphics games and engines OpenSceneGraph Media e.g. and Nginx, mail servers, VoIP, etc. players mplayer/mpv, gstreamer, VLC being built as I write Desktops virtually all of XFCE, LXDE/LXQt, most of GNOME and KDE Complex e.g. Gimp, Inkscape, 3D design and CAD, some Office suites Many incl. desktop programs Science applications and related software e.g. OpenMPI 29/46

30 Status in detail (3) Notable exceptions: Complex browsers Firefox, Chromium the latter only available in x86+arm OpenJDK only Other with Hotspot (major project) the slower Zero available notable languages/ecosystems missing Haskell NodeJS Golang support not very good yet Toolchain LLVM (support upstream too recent) GDB and Valgrind (need porting upstream too) This is the Future Work slide :-) 30/46

31 Status in detail (4) In general, most packages built without modif. Some would need, but they already benefit from previous ports patches for other arches that can be repurposed changes to build systems, conditional support for some deps e.g. For libseccomp not available in some ports those which need modif, usually minimal disable available e.g. Some deps much higher in the stack, not yet disable Java in gettext or libdb; disable Qt GUI in cmake need support specific to RISC-V e.g. word sizes, alignment, interpreters, memory allocators... 31/46

32 Status in detail (5)... so they are built, but do they work? Basically... YES! Stable enough to build thousands of packages Most of those with testsuites, passing fully or >99.5% of cases Tested by using the system everyday Some tested on hardware (HiFive Unleashed, thanks to SiFive!) Problems found: Bugs unconvered and reported in the toolchain, miscompiling Qemu crashes, bugs in FP unit, and system locks Problems with timeouts qemu-system Problems e.g. emulation being too slow for some tests defaults due to implementation of emulators or OS support failures with network or missing features... all that is expected in a new arch, some of those still happen in mature arches also 32/46

33 Status: Pics or It Didn t Happen (6) 33/46

34 Status: Pics or It Didn t Happen (7) 34/46

35 Status: Pics or It Didn t Happen (8) 35/46

36 Status: Pics or It Didn t Happen (9) 36/46

37 Status: Pics or It Didn t Happen (10) 37/46

38 Status: Pics or It Didn t Happen (11) 38/46

39 How the RISC-V community can help Upstream remaining toolchain support Some pieces missing, like full Linux support, GDB, Valgrind... Test and report problems Many packages don t have test suites, or have subtle problems See wiki page with centralised information: Guides for how to install a Debian system for RISC-V See progress of auto-builders and packages being stuck Packages with bugs, needing work, etc. 39/46

40 ... and what are the benefits (1) Just by the Debian, Fedora and other ports being started: Problems... in the software stack were found and hopefully are or will be fixed Packages needing support or fixes upstream that we patch will benefit all RISC-V community People that learn about RISC-V through non RISC-V channels can still end up contributing to RISC-V 40/46

41 ... and what are the benefits (2) Large collection of software, useful for many reasons: People more likely to pay attention to the hardware Large software ecosystem is key to the success of the Raspberry Pi and similar devices Easy to test hardware, base ISA, new extensions ARM (the company) uses Debian as testbed for changes or fixes in the architecture/abi, prototypes of arm64_ilp32 Easy to take base OS software and optimise specific packages for specific extensions (e.g. media codecs) Easy to benchmark with software in common use and avoid problems of synthetic benchmarks, as Computer Architecture: A Quantitative Approach would have it ;-) 41/46

42 ... and what are the benefits (3) By using the Debian port directly on your RISC-V system Debian is easy to install and keep up-to-date At the moment not well documented/advertised, but basically: Unpack.tarball in the root filesystem; or Near future: debootstrap --arch=riscv64 unstable /path/chroot \ Install software, keep system up to date easily and securely apt-get install awesome-package apt-get upgrade Easy development for the RISC-V ecosystem e.g. cross-build: $ apt-get install gcc-riscv64-linux-gnu $ riscv64-linux-gnu-gcc -o test test.c 42/46

43 Who From the Debian side: 3 people invested a lot of time for months/years now, bootstrapping and building the whole archive: Karsten Merker, also active in RISC-V lists Aurélien Jarno, GNU libc maintainer in Debian and responsible for debian-ports infrastructure, lots of work debugging problems in the toolchain Yours truly :-) Many other people (long list!) got involved and offered help along the way, thanks! Many Debian contributors investigate problems, apply patches proactively/quickly on a daily basis Kurt Keville, from the MIT RV128 team Help with infrastructure and logistics for a long time lately with auto-builders Website: 43/46

44 Special thanks Steven J. Wallach (Micron) Sponsoring attendance to this workshop Otherwise this talk might not happen!! (Please, let contributors attend workshops for free! For nonprofessionals it s very taxing to reserve holidays, already arrange travel, etc.) SiFive, The Palmer Dabbelt in particular HiFive Unleashed and other hardware Bytemark For (Hosting provider) sponsoring hardware (this project and Debian) Christian Svensson For starting the OpenRISC or1k port, being a pleasure to work with and getting me hooked! 44/46

45 Also thanks Debian contributors / community For creating an amazingly useful and fun project Well adapted to add new ports Multi-arch, cross-compilation support Helmut Grohne s rebootstrap project RISC-V contributors / community For the patience of the people from the community in dealing with my requests for help, comments and patches in the early times For creating another amazingly useful and fun project And for the courage of starting from scratch 45/46

46 Questions / comments? Manuel from Barcelona (Fawlty Towers).... (Sorry, could not resist, Huge Fan! :-) ) Manuel in Barcelona (first time!) Manuel A. Fernandez Montecelo <mafm@debian.org > <mafm@debian.org> Artwork based on Green_Debian_ /46