10 ms·
Debian riscv64
- seeknotfind 3y agoI applaud another step towards competition and commoditization of hardware.
- LatticeAnimal 3y agoI don't fully understand riscv, but shouldn't this be something like `RV64GC`? Are they building for the base riscv with no isa extensions? This might be addressed somewhere in the debian docs but I didn't see it.
- CUViper 3y agoRV64GC is mentioned here: https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...
- LatticeAnimal 3y agoAh, thanks for that! I wonder how they plan to support future extensions like RV64GCV which seems to be gaining traction…
- jrockway 3y agoWould it be much different than armhf vs. armel?
- sanxiyn 3y agoNote that NEON is optional for armhf, mainly to support Tegra 2. This was a big deal at the time. See https://wiki.debian.org/ArmHardFloatPort https://wiki.debian.org/ArmHardFloatPort.
- viraptor 3y agoWould anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).
- cmeacham98 3y agoDebian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).
- sanxiyn 3y agoDebian does distribute SSE-using binaries (with fallback) on i386 which detects presence of SSE at runtime using CPUID.
- IntelMiner 3y agoYou're thinking of optimizing the code for a specific processor. Run-time codepaths that detect CPU features have existed since MMX and SSE
- pabs3 3y agoThere are options for runtime instruction selection: https://wiki.debian.org/InstructionSelection https://wiki.debian.org/InstructionSelection
- sanxiyn 3y ago> Check for feature presence That is the hard part. On Intel you can use CPUID, but it is ARM policy to not expose such instructions. You can read /proc/cpuinfo, but that is Linux-specific. Edit: there is a reason for ARM policy: CPUID is a well known virtualization hazard. In fact, KVM immediately traps if you execute CPUID on guest. ARM made a good decision here. Still, it means things can't work exactly like it worked on Intel.
- erik_seaberg 3y agohttps://news.ycombinator.com/item?id=18542040 https://news.ycombinator.com/item?id=18542040 talks about registers with a similar purpose.
- waaveshine 3y agoI’ve noticed a lot of projects use riscv64 as shorthand for the rv64gc ISA, especially when it’s understood that there is an MMU, maybe an FPU, privilege levels, and any other extensions that a modern OS requires. Anyway, I did find this on the Debian website[1]. So it seems they mean rv64gc. [1] https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_choice https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...
- photonbeam 3y agoPresumably Android will also chose a base minimum ISA spec for riscv software at some point. It would be tidy if they match the regular linux ecosystem
- snvzz 3y agoAndroid (and most Linux distributions) is likely to settle for RVA22+V or RVA23 as minimum requirement. There's a lot in there which RV64GC (ratified in 2019, I understand unchanged since 2017) lacks. Some of the new extensions e.g. vector and bit manipulation do have a significant effect in performance.
- panick21_ 3y agoIt has not been decided. There was a talk about the details just 2 weeks ago on the RISC-V International Youtube channel. Very interesting and recommended.
- ur-whale 3y agoIf there is a downfall of RISCV, it's going to be the myriad of sub-architectures and their weird naming schemes, with an added layer of marketing drones muddying up the waters even further. This is going to confuse the hell out of the potential customer base and it would be a crying shame, wasting a golden opportunity to get out of the oxygen-choking clutches of proprietary ISA vendors (who at this point are purely rent-seeking and add exactly zero actual economic value to the ecosystem).
- 15155 3y agoI don't think so, in practice since atomics (on single-core systems especially) and floats can easily be emulated. If larger, more-incompatible extensions become commonplace, possibly.
- bee_rider 3y agoI mean, in the very least the proprietary ISA vendors provide the service of selecting what extensions are added. If you think too many extensions will take down RISC-V, that seems to have value.
- panick21_ 3y agoRISC-V will do the same thing. That's what profiles and even further platforms will provide. Most software (the large investment) will target these profiles. Not following the profiles will be possible but will cause issues.
- snvzz 3y agoNot since RISC-V Profiles[0]. 0. https://github.com/riscv/riscv-profiles/releases https://github.com/riscv/riscv-profiles/releases
- AndyKelley 3y agoGreat work Debian! We already have riscv64-linux builds of Zig enabled with every CI run[1]. Happy to see that they might finally be utilized by more users soon. [1]: https://ziglang.org/download/ https://ziglang.org/download/
- Uehreka 3y agoI may not work with Zig (yet) but it’s cool to see y’all representing yourselves like this, keep up the good work!
- deleted 3y ago[deleted]
- djha-skin 3y agoAny promising riscv64 computers on the market I should know about? Raspberry pi level or otherwise? What computers could I use this distro on?
- snvzz 3y agoI would look at JH7110, released earlier this year, used in VisionFive 2, Star64, as well as PineTab-V, and with an excellent official effort towards upstreaming software support[0]. I own a VisionFive 2 and can recommend it. There's also the TH1520, a newer chip that's a bit faster and has pre-spec V extension. This is available in the Sipeed Lichee Pi4A, but the support for this chip is very green still. CPU-wise, JH7110 performs between rpi3 and rpi4. TH1520 is faster than rpi4. Else (GPU, I/O, cryptographic acceleration, hardware video codec acceleration and other peripherals), they are both significantly faster than rpi4. 0. https://rvspace.org/en/project/JH7110_Upstream_Plan https://rvspace.org/en/project/JH7110_Upstream_Plan
- FullyFunctional 3y agoTH1520 is definitely not faster than a RPi4, not for normal programs compiled with normal compilers or binaries that will come from your distribution. And no, Bruce, vendor benchmarkering doesn't count. ADD: TH1520 is about twice as fast as JH7110, but as best I can tell, StarFive (JH7110) is more proactive about upstreaming support.
- snvzz 3y agoA quick search in Linux git head for "th1520" returned some results. It must mean there is ongoing work. I hope they set up a webpage to track what's going on with upstreaming efforts, similar to JH7110 has. Notably, boards with TH1520 are just starting to ship, whereas boards with JH7110 were shipping in volume in February.
- ekianjo 3y ago> CPU-wise, JH7110 performs between rpi3 and rpi4. TH1520 is faster than rpi4. In reality closer to a rpi3 > Else (GPU, I/O, cryptographic acceleration, hardware video codec acceleration and other peripherals), they are both significantly faster than rpi4. if you can the GPU working, right now on Vision2 it's only usable in very few applications
- sohrob 3y agoWhen Debian is ported to a new architecture does that mean something special needs to happen to all of the packages in the repository for them to work on that new architecture?
- jffry 3y agoSounds like they need to cross-compile enough stuff to get a bootable system in the new architecture: https://wiki.debian.org/DebianBootstrap#Cross-building https://wiki.debian.org/DebianBootstrap#Cross-building
- pabs3 3y agoRelated link: https://wiki.debian.org/PortsDocs/New#Bootstrap https://wiki.debian.org/PortsDocs/New#Bootstrap
- lmm 3y agoWell-written applications will just work. Badly-written applications may require patches or be impractical to build at all, and some system software may not make sense on the architecture at all. There's a whole lot of build infrastructure for Debian; by default the package maintainer doesn't need to do anything specific, building for all architectures will happen by default.
- KingLancelot 3y ago[dead]
- totetsu 3y agoWhat kind of assumptions would badly-written applications make to make themselves impractical to cross-build?
- ilyt 3y agoAssembler optimizations without fallback to pure C for other architectures for example.
- asicsp 3y agoSee also: "riscv64 is now an official Debian architecture (rebootstrap in progress)" https://news.ycombinator.com/item?id=36834701 https://news.ycombinator.com/item?id=36834701
- snvzz 3y agoLooking forward to seeing this reflected in build statistics. 0. https://buildd.debian.org/stats/ https://buildd.debian.org/stats/
- creatonez 3y agoi386 below arm64 is an interesting surprise. Seen some Debian developers mention struggles keeping 32-bit x86 going but didn't think it would have dropped that much.
- arookery 3y ago[flagged]
- photochemsyn 3y ago[flagged]
- tw1984 3y agoa true milestone! hope it is also the beginning of the end - ISA shouldn't be some tightly controlled assets managed by some lawyers and CXOs, companies shouldn't be sued for just trying to invest into certain ecosystems.
- snvzz 3y agoThe proprietary ISA ship has long sailed[0]. RISC-V is inevitable[1]. 0. https://riscv.org/members/ https://riscv.org/members/ 1. https://www.youtube.com/watch?v=ktjSvlelKPk https://www.youtube.com/watch?v=ktjSvlelKPk
- KingLancelot 3y agoMicrosoft, Intel, AMD, NVIDIA. Only one I didn’t see was Apple, hell even Raspberry Pi is there.
- Tepix 3y agoApple is also interested, they were hiring a RISC-V engineer back in 2021 already.
- cmrdporcupine 3y agoI can't a realistic scenario see Apple moves off Aarch64 at this point for their MPU. They're having boatloads of success with what they've done there. But I can imagine there's interest on their part in using something like RISC-V in supporting chipsets; modems, power mgmt, disk controllers, etc. That and having something in their backpocket "just in case."
- ComputerGuru 3y agoApple is the only company with a special licensing deal with ARM that lets them do whatever they want and develop their own ARM cores without relying on ARM IP or premade designs like everyone else. They've also sorted it out financially where they're probably not incurring incremental costs, though I think the details are secret.
- deleted 3y ago[deleted]
- retrocryptid 3y agoHopefully this means I don't have to build emacs-nox from scratch anymore.
- OhMeadhbh 3y agoAhem... I think I was the one compiling emacs-nox from scratch: https://youtu.be/WQR6vgdLQI8 https://youtu.be/WQR6vgdLQI8
- superdug 3y agoI wanted to check first, and I wasn't saddened when I found netbsd was also available for riscv64. That being said, having a full debian suite to nicely land on is what will gain it adoption. It's a chicken and egg problem where one side is vigorously designing and publishing a hardware spec in search of an operating system and at the same time an entire eco-system of open source development is in search of open hardware to run on. Fully open systems are an entirely ideological win at this point with a now sub-$50 entry point setups available today. Please also do not get me wrong, working around copy protection and binary blobs serve as amazing learning tools for tinkerers, but not for true beginners. Some people learn from hands on breaking it and putting it back together, but others learn by knowing that there is a fully documented dearth of information within a mere quandary of any part of the system. These two worlds are not antagonistic, but in fact entirely complementary to each other. To fully understand and master a system, you have to break it and know how to fix it. While on the same hand knowing how to see what part broke and see an exact way to fix it in the completely free entirety of information available until time itself forgets it, gives you the confidence that there isn't anything you don't know or knowing instantly where to find it if you don't. That free and open standard will lend itself to future chip designs, broader software options for those designs, and start to make computers adopt there new role as segregated fully autonomous systems loosely networked together into the same status that all 99th percentile that all previous technology has adopted throughout history. The nerds won, we made computers into a skilled labor. You're welcome.
- ur-whale 3y agoNo snarkiness intended, but I just read your post for the 3rd time and although I understand each sentence individually, I'm still not sure what point you're trying to make.
- superdug 3y agoIt's an amazing accomplishment that we'll see the benefits of for centuries. The culmination of a free operating system on free hardware that is.
- deleted 3y ago[deleted]
- mise_en_place 3y agoThis is great news. Is there a special BSP that needs to be flashed first for risc-v boards? Or will it work out of the box with OpenSBI?
- JNRowe 3y agoLike always, it depends. The hardware section on the wiki lists some device specifics¹, and if you follow the OnDebian² links there are a couple that look like they might work-ish out of the box. Presumably -- or perhaps hopefully -- things will improve quicker with mainline Debian as an option and hardware becoming more available. In the context of Debian, let us hope people aren't flashing a BSP³ in the hope of improved board support ;) ¹ https://wiki.debian.org/RISC-V#Hardware https://wiki.debian.org/RISC-V#Hardware ² https://wiki.debian.org/InstallingDebianOn https://wiki.debian.org/InstallingDebianOn ³ https://wiki.debian.org/BSP https://wiki.debian.org/BSP
- sylware 3y agoThis is the mechanical progression for risc-v: legacy support. The real future is riscv64 assembly written software with a very conservative usage of a preprocessor (or we will end up with c++ syntax grade preprocessing), and software written with very high level languages which interpreters are written in riscv64 assembly with a very conservative usage of a preprocessor (python? javascript? etc). That because risc-v is meant to be the CPU ISA standard. I really hope risc-v will be a success.
- lasermike026 3y agoVery exciting! I'm looking for opportunities to use a riscv cpu.
- MR4D 3y agoWe’re one step closer to running TrueNAS on riscV. Wow!