Debian GNU/Linux port for RISC-V 64-bits · 8th RISC-V Workshop Debian GNU/Linux port for RISC-V...

DebianGNU/Linux port for

RISC-V64-bits

DebianGNU/Linux port for

RISC-V64-bits

Manuel A. Fernandez MonteceloManuel A. Fernandez Montecelo < <[email protected]@debian.org>>

8th RISC-V Workshop :: May 7-10, 20188th RISC-V Workshop :: May 7-10, 2018Barcelona Supercomputing Center && Universitat Politècnica de CatalunyaBarcelona Supercomputing Center && Universitat Politècnica de Catalunya

8th RISC-V Workshop Debian GNU/Linux port for RISC-V 64-bit 2/46

OutlineOutline

➢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


Goals of this projectGoals of this project

➢To have Debian ready to install & run on RISC-V based systems

➢Fully integrated with Debian infrastructure➢Not 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


Why a Debian Port for RISC-V? (1)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➢... and had lots of fun!!

➢No 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


Why a Debian Port for RISC-V? (1 bis)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➢... and had lots of fun!!

➢No 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


Why a Debian Port for RISC-V? (2)Why a Debian Port for RISC-V? (2)

➢Technical and philosophical reasons:➢Debian 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


What is Debian? (1)What is Debian? (1)

➢The Project: A community of individuals

➢Mostly volunteers➢No 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)


What is Debian? (2)What is Debian? (2)

➢Mostly known as a GNU/Linux “distribution”

➢Started by Ian Murdock in 1993➢First “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


What is a Debian Port? (1)What is a Debian Port? (1)

➢In short, ABI of the combination of {computer arch + OS kernel + libc}

➢Computer architecture:➢Many, currently and over the years (details in next slides)

➢Kernel + 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)



➢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 / unsupported➢Not in “stable” releases, but hosted in Debian infrastructure

➢Officially supported➢Part of the “stable” releases and fully supported

➢Ports don’t born “fully supported”➢they work their way up to it



➢Criteria for “officially suported” ports:➢Be able to build almost all of the “source” packages➢Have enough people responsible for it

➢addressing issues during full Stable release cycles

➢Have hardware available, redundant, well managed, etc.

➢And 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



➢“Unofficial” or “unsupported” ports:➢When 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



➢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)...



➢What maintainers of packages see:➢e.g. for Firefox: https://buildd.debian.org/status/package.php?p=firefox-esr

https://buildd.debian.org/status/package.php?p=firefox-esr




Port/Arch Name

BuildStatus

Build machines, logs, historic, etc.





Port/Arch Name

BuildStatus

Build machines, logs, historic, etc.

riscv64



The Plan (1)The Plan (1)

➢Broad steps:1)Bootstrap and create viable, basic OS disk images2)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


The Plan: Software decisions (2)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 is basically the same for all Debian ports

➢including those with other kernels


The Plan: Hardware decisions (3)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


The Plan: Not Considered (4)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 built

➢e.g. Firefox or Chromium, LibreOffice, KDE Desktop➢This problem will only become worse with time

➢Embedded / IoT / etc. likely not interested➢Neither Debian nor other “full”, general purpose OSs


The Plan: Where we are now (5)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 ✓

➢Prepare 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

➢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


History: First Bootstrap (1)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


History: First Bootstrap (2)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)


HistoryHistory: First Bootstrap (3): 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 ceased to a halt

➢In April 2017, published the packages built by then➢http://riscv.mit.edu/➢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

http://riscv.mit.edu/


History: Second Bootstrap (1)History: Second Bootstrap (1)

➢Started when GNU libc was upstreamed➢~25 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


History: Second Bootstrap (2)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


Current status in a single graphCurrent status in a single graph

➢https://buildd.debian.org/stats/graph-ports-quarter-big.png (May 1st 2018)

https://buildd.debian.org/stats/graph-ports-quarter-big.png


Status in detail (1)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



➢Packages available include:➢Most of server-side packages

➢e.g. Apache and Nginx, mail servers, VoIP, etc.

➢Complex 3D graphics games and engines➢e.g. OpenSceneGraph

➢Media players➢e.g. mplayer/mpv, gstreamer, VLC being built as I write

➢Desktops➢virtually all of XFCE, LXDE/LXQt, most of GNOME and KDE

➢Complex desktop programs➢e.g. Gimp, Inkscape, 3D design and CAD, some Office suites

➢Many Science applications and related software➢incl. e.g. OpenMPI



➢Notable exceptions:➢Complex browsers

➢ Firefox, Chromium – the latter only available in x86+arm

➢OpenJDK with Hotspot (major project)➢only the slower Zero available

➢Other 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 :-)



➢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. libseccomp not available in some ports

➢For those which need modif, usually minimal➢disable deps much higher in the stack, not yet available

➢e.g. disable Java in gettext or libdb; disable Qt GUI in cmake

➢Some need support specific to RISC-V➢e.g. word sizes, alignment, interpreters, memory allocators...



➢... 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 emulation being too slow for some tests’ defaults

➢Problems due to implementation of emulators or OS support➢e.g. failures with network or missing features

➢... all that is expected in a new arch, some of those still happen in mature arches also


Status: Pics or It Didn’t Happen (6)Status: Pics or It Didn’t Happen (6)


How the RISC-V community can helpHow 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:➢https://wiki.debian.org/RISC-V

➢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.

https://wiki.debian.org/RISC-V


... and what are the benefits (1)... 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



➢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 ;-)



➢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 \

http://ftp.ports.debian.org/debian-ports/

➢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

http://ftp.ports.debian.org/debian-ports/


WhoWho

➢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: http://rv128.mit.edu/

http://rv128.mit.edu/


Special thanksSpecial thanks

➢Steven J. Wallach (Micron)➢Sponsoring attendance to this workshop➢Otherwise this talk might not happen!!

➢(Please, let contributors attend workshops for free! For non-professionals it’s very taxing to reserve holidays, already arrange travel, etc.)

➢SiFive, Palmer Dabbelt in particular➢The HiFive Unleashed and other hardware

➢Bytemark (Hosting provider)➢For sponsoring hardware (this project and Debian)

➢Christian Svensson➢For starting the OpenRISC or1k port, being a pleasure to work with and getting me hooked!


Also thanksAlso 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


Questions / comments?Questions / comments?

Manuel A. Fernandez MonteceloManuel A. Fernandez Montecelo < <[email protected]@debian.org>>https://people.debian.org/~mafm/https://people.debian.org/~mafm/

https://wiki.debian.org/RISC-Vhttps://wiki.debian.org/RISC-V

Artwork based on “Green_Debian_2”Artwork based on “Green_Debian_2”http://collab.debian.net/si0ux/gallery/green-debian-2si?view=truehttp://collab.debian.net/si0ux/gallery/green-debian-2si?view=true

http://www.linuks.mine.nu/volkany/http://www.linuks.mine.nu/volkany/

Manuel from Barcelona(Fawlty Towers)

.

.

.

.(Sorry, could not resist,

Huge Fan! :-) )

Manuel in Barcelona(first time!)

Debian GNU/Linux port for RISC-V 64-bits · 8th RISC-V Workshop Debian GNU/Linux port for RISC-V...

Documents

Transcript of Debian GNU/Linux port for RISC-V 64-bits · 8th RISC-V Workshop Debian GNU/Linux port for RISC-V...