Live data from Hacker News

Debian riscv64

blog.aurel32.net

11–20 of 155 posts

Re: Debian riscv64

#12

Any promising riscv64 computers on the market I should know about? Raspberry pi level or otherwise? What computers could I use this distro on?

I 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

Re: Debian riscv64

#13
post #4

Earlier quoted context omitted.

RV64GC is mentioned here: https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...

Ah, thanks for that! I wonder how they plan to support future extensions like RV64GCV which seems to be gaining traction…

Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).

Re: Debian riscv64

#14

Earlier quoted context omitted.

I’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_cho...

Presumably 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

Android (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.

Re: Debian riscv64

#15

Earlier quoted context omitted.

Ah, thanks for that! I wonder how they plan to support future extensions like RV64GCV which seems to be gaining traction…

Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).

Debian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).

Re: Debian riscv64

#16
When 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?

Re: Debian riscv64

#17

Earlier quoted context omitted.

Ah, thanks for that! I wonder how they plan to support future extensions like RV64GCV which seems to be gaining traction…

Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).

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

Re: Debian riscv64

#18

Earlier quoted context omitted.

Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).

Debian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).

Debian does distribute SSE-using binaries (with fallback) on i386 which detects presence of SSE at runtime using CPUID.

Re: Debian riscv64

#19
post #16

When 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?

Sounds like they need to cross-compile enough stuff to get a bootable system in the new architecture: https://wiki.debian.org/DebianBootstrap#Cross-building
Post reply on HN