News China: Chipindustrie setzt mehr auf lizenzfreies RISC-V statt Arm

[TomH22]

Es gibt bei RISC-V einen Basisbefehlssatz, den müssen alle CPU-Architekturen verarbeiten können, ansonsten sind das keine RISC-V CPUs, ganz einfach.

Da hast Du grundsätzlich recht. Mir ist jetzt auch kein RISC-V Design bekannt, das z.B. einen inkompatiblen Basis Befehlssatz (RV32I bzw. RV64I) hat.
Für den Mainline-Linux Support wird mittlerweile RV64G (G ist eine Abkürzung für IMFDAC = Integer, Multiply Divide, Float, Double-Float, Atomic, Compression) vorausgesetzt. Das ist übrigens ein bisschen ärgerlich, es gibt viele FPGA CPU Implementierungen die maximal RV32IMAC unterstützen, und da muss man einen "handgebastelten" Linux Kernel verwenden. Das allein reicht aber nicht um damit z.B. eine Standard Linux Distribution zu bauen, die dann auf jedem RISC-V Computer bootet, wie es etwa heute bei X86_64 PCs möglich ist.

Um das zu erreichen, gibt es "RISC-V Platform Spezifikation" (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc), die ist aber noch in Bau.
Man sieht in der Spezifikation recht viele "DEPRECATED" Markierungen, obwohl sie noch nicht mal die Version 1.0 erreicht hat. Das sind die ganzen individuellen Ansätze aus der Anfangszeit von RISC-V, wo sich die Leute in Ermangelung eines Standards halt etwas ausgedacht haben.

Anfangs gab es für den Linux Boot nur das SBI (Supervisor Binary Interface), das reicht nur bei weitem nicht aus, um z.B. dem Linux Kernel eine Beschreibung der Hardwareeigenschaften (z.B. Memory Layout) zu liefern.
Die Platform Spezifikation sieht aus der x86 Welt bewährte Mechanismen wie ACPI und UEFI vor, um die Hardware Enumeration zu ermöglichen.

Wie kompatibel ist RISC-V denn zueinander? Letztlich kann hier ja jeder Hersteller seine eigenen Closed Source Chips entwickeln. Läuft die Software dann aber trotzdem auf allen oder gibts da dann Inkompatibilitäten?

Die Chinesen gehen schon teilweise mal Sonderwege, z.B. hatte der Kendryte K210 den Supervisor Mode implementiert, aber keine MMU, sowas ist eigentlich nicht vorgesehen. Oder die MCUs von GigaDevice implementieren einen proprietären Interrupt Controller, weil die MCUs eigentlich ein STM32 Klon sind, wo man den ARM Cortex-M Kern durch RISC-V ersetzt hat. Da aber das Interrupt Modell von RISC-V und ARM sehr unterschiedlich ist, haben sie sich halt was "gebastelt".

Man muss aber auch da eben sagen, das der RISC-V PLIC (Platform Interrupt Controller) sich eher für "Application Class" CPUs, die Linux booten, eignet, daher gibt es einen alternativen Entwurf für einen MCU tauglichen Interrupt Controller (https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc).

Die meisten Sonderlocken entstanden also, da es zum entsprechenden Zeitpunkt noch keine passenden Standards gab. Insofern bestehen gute Chancen, das diese im Laufe der Zeit zugunsten der Standards verschwinden.

 

[ModellbahnerTT]

Das allein reicht aber nicht um damit z.B. eine Standard Linux Distribution zu bauen, die dann auf jedem RISC-V Computer bootet, wie es etwa heute bei X86_64 PCs möglich ist.

Dazu sollte es aber kommen damit sich RISC-V nahe überall durchsetzt.