11 ms·
Porting Alpine Linux to RISC-V
- bogomipz 8y agoThe author states: >"I’m working on making this hardware available to builds.sr.ht users in the next few months, where I intend to use it to automate the remainder of the Alpine Linux port and make it available to any other operating systems (including non-Linux) and userspace software which are interested in working on a RISC-V port." Is this author also the designer of the board? Or do they made they're working on making the software available? This looks really exciting, looking forward to following the progress.
- SpaceManiac 8y agoThe author means making compute time on the hardware available to run CI builds on their service. If you care about porting your software to RISC-V enough to want to test that software there, hardware is probably a more accurate harness than qemu.
- qlk1123 8y agoJust a note here, actually Fedora/RISC-V are hosting their release builds on qemu.
- rwmj 8y agoI'm not sure what this means, but we have 3 of these SiFive boards doing builds[1], as well as dozens of qemu instances running on Intel hardware supplied by Facebook. We use the SiFive boards for the largest builds however, things like GCC and the kernel, because they're still much better than qemu. [1] Or we were up to yesterday when we had a hardware failure (on an Intel machine) so our build system is currently down. Four days before Christmas, so the worst possible time ...
- IntelMiner 8y agoI'd love to see time being given to Gentoo. They're basically up there with Debian in terms of supporting "alternative" architectures According to the Handbook. They currently support Alpha, AMD64, ARM, ARM64 HPPA/PA-RISC, IA64, MIPS, PPC, PPC64, SPARC and x86 (i486 and i686)
- als0 8y agoBeyond even. A while ago Debian dropped support for Alpha, IA64 and PA-RISC. Even SPARC isn't supported anymore. https://www.debian.org/releases/stable/i386/ch02s01.html.en https://www.debian.org/releases/stable/i386/ch02s01.html.en
- mehrdadn 8y agoI tried Alpine and immediately stopped when I saw how old the packages were. How do people use it...?
- axaxs 8y agoWhich packages in particular? I've always found most things to be rather recent...
- mehrdadn 8y agoI seem to recall seeing an old GCC (6? 5? I forget) when GCC 8 had already come out.
- xaduha 8y agohttps://pkgs.alpinelinux.org/packages?name=gcc&branch=edge https://pkgs.alpinelinux.org/packages?name=gcc&branch=edge
- ploxiln 8y agoalpine 3.8 (and 3.7) branch have gcc-6.4 which was released in July 2017. For a C compiler, that is absolutely sufficient. You'll find many other packages in the 3.8 release branch are more up-to-date, this is a bit of an exception. This isn't Rust. GCC-6.4 will compile literally any C or C++ project you find (that works with any recent version of GCC), including stuff requiring C++-14 and _most_ of C++-17. Hell, GCC-4.9 (from 2014) is sufficient to compile the latest linux kernel, the latest sqlite3, the latest nginx, the latest of any real significant package.
- chli 8y agoI would be very interested on some background on how the musl bugs were discovered and debugged !
- Sir_Cmpwn 8y agostrace, mainly, and the help of the experts in #riscv on freenode.
- amelius 8y agoA few questions: - In which fab is the CPU manufactured? - How much slower does it compile stuff than a mainstream CPU? (Author only says "somewhat slower", but could have been more precise) - Is the RISC-V architecture free from Spectre-like bugs? - What does the memory hierarchy look like?
- rwmj 8y agoIt's built on TSMC's 28nm process. It's an in-order 64 bit 4 core processor (actually 5 cores, because there's a small 32 bit core which does nothing normally). Think Cortex A53. It's very usable for development (I have two of them), and we even have people using them for desktop running GNOME. But it's not a Xeon. The main issue is the cost and lack of SATA on the development board (there's a daughter board providing that, at extra cost). Everything is open source. This chip is free of speculation bugs because it doesn't do speculation. However the architecture itself is not in any way better or worse than others, and a RISC-V core with a different microarchitecture might well be vulnerable, although since these attacks are now well-known steps should be taken by designers to avoid them. Memory architecture is very simple, it has small L1 and L2 caches and main memory. There's also a chiplink connection which takes the memory bus off-chip. You can read more here: https://www.sifive.com/chip-designer#fu540 https://www.sifive.com/chip-designer#fu540
- mntmn 8y agoThanks for the explanations. Do you know if people have attempted interfacing with Chiplink using homebrew FPGA solutions?
- rwmj 8y agoThe daughterboard is relevant here: https://www.crowdsupply.com/microsemi/hifive-unleashed-expansion-board https://www.crowdsupply.com/microsemi/hifive-unleashed-expan... It takes the Chiplink connection and routes it to a PCIe bridge. There's also a large FPGA on there, but I'm not quite clear how it's all connected up. I don't know much about what people are using this for. Also the whole setup costs like $4000 so I guess it's not quite ready for casual home users just yet. If you want to go the FPGA route, then it might be better looking at a Virtex-7 and putting the RISC-V rocketchip core on there, along with whatever local customizations you want to try out.
- Perseids 8y agoSomething that has been bugging me for a while: Why is cross compiling so hard? After all, compilers are just C programs (or C++/Go/Rust/… programs). It's not like a target implementation is using some magic instructions from the host to generate the assembly, or that it is harder to calculate some 32bit offsets for the compiled program, when the compiler is running on a 64bit host environment. Or is it about the helper programs / scripts around the core compilation process that are too often hard coded to read out the configuration from the host system? So basically there is no technical hurdle, just the social norm that target arch == host arch, and thus make procedures aren't sufficiently tested for cross compilation from the get go?
- marmaduke 8y agothe ease of using golang's cross compilation suggests it is historically the norm that target == host
- ceidsness 8y agoYes, that's exactly it. A lot of source packages expect to be build on the same system they will run on.
- TickleSteve 8y agothe compilers themselves (e.g gcc) aren't the problem typically. It tends to be the dependencies (of the compiler and the libraries) that assume target==host.
- IshKebab 8y agoErm, GCC is a huge problem for cross-compiling, because it's compilation target is determined at compile time. I mean at GCC compile time. You have to recompile GCC to target a different machine. Clang isn't broken like that, and for clang you are right that the issue is normally dependencies. Again GNU's libc is kind of broken. Cross compiling with Clang and Musl is not too bad.
- phkahler 8y ago
- Annatar 8y ago"This board is cool." What exactly is cool about this board?
- rwmj 8y agoIt's all open source.
- ddevault 8y agoIt's also surprisingly nice. 8G of DDR4 EEC RAM, 4 surprisingly fast CPU cores, and a gigabit ethernet port - it all adds up to a really pleasant board to work with.
- tyingq 8y agoThat is nice, though at $999, expectations would be pretty high.
- Sir_Cmpwn 8y agoWell, it's the also first RISC-V CPU available to the general public. I expect prices to come down in the future, but I was definitely surprised with the quality of the "first" CPU.
- Annatar 8y agoThat CPU has one of the worst instruction sets ever: the mnemonics are even worse than intel, which was hereto considered the stupidest up until this point. That's an achievement. They will have to be hidden by compilers because they're otherwise complicated and a pain in the ass to program.
- zmix 8y agoThat's because it's brand new tech. I assume, that the Chinese, who came up with Arduino boards, that cost USD1.99 will also create knock-offs of these and prices will fall extremley.
- eatonphil 8y agoThanks for the post and nice work, Drew! I look forward to Linux/BSD-capable non-x86 boards becoming easier to find and cheaper to buy over time. This one is not the cheapest board but since I'm indefinitely in line for a Pine64 (and can't find much else) I may take a look at this.
- jamesaross 8y agoI wrote a short paper for HPEC that included some power and performance benchmarks and analysis on the HiFive Unleashed U540 SoC [0]. The SoC isn't open source as some suggest although I believe the core is based on the open source Rocket Chip Generator [1]. It seems the greatest weakness was in the slow memory interface. The details of memory controller and configuration were proprietary when I tried to find out why it wasn't performing well. [0] http://www.ieee-hpec.org/2018/2018program/index_htm_files/150.pdf http://www.ieee-hpec.org/2018/2018program/index_htm_files/15... [1] https://github.com/freechipsproject/rocket-chip https://github.com/freechipsproject/rocket-chip
- drewg123 8y agoFrom [0] above: The STREAM benchmark [6] was also compiled and executed, confirming that DRAM performance is limited to less than 1.6 GB/s on this platform. It’s unclear if this is a problem with the cache hierarchy, memory controller, or the configuration of the DDR Controller Control Registers Wow, that's unspeakably terrible. That's about 10-20% of the b/w one should get from 2400 mem (depending on how many channels the mem controller uses). I hope this is some simple misconfiguration that can be fixed in firmware or in the kernel.
- nickik 8y agoThe Freedom platform is open and lots of the tilelink interconnect. The xore is based on rocket but they have some internal changes that is not open source jet. The generated RTL is open but that is of course limited.