diff --git a/stack-reports/edge-ai/edge-ai.md b/stack-reports/edge-ai/edge-ai.md new file mode 100644 index 000000000..8f502185d --- /dev/null +++ b/stack-reports/edge-ai/edge-ai.md @@ -0,0 +1,1223 @@ +--- +title: Edge AI +parent: Whole-Stack Reports +--- + +# Edge AI + +**Author:** Ludovic Henry
+**Date:** 2026-08-29
+**Scope:** RISC-V readiness of the Edge AI software stack
+**Target profile:** RVA23U64
+**Audience:** exec-product
+**Verification policy:** Colors are assigned from primary upstream sources, adversarially verified against the per-project reports under project-reports/. Items not verifiable against a second source are marked [NEEDS VERIFICATION].
+ +![](edge-ai.svg) Link to full screen: [edge-ai.svg](edge-ai.svg) + +--- + +## Scoping Assumptions + +- Edge AI means deploying AI algorithms and models directly on local edge devices (IoT sensors, smart cameras, industrial PLCs, autonomous vehicles/robots, smartphones/laptops, wearables, smart home appliances, edge gateways, edge servers) to enable real-time local data processing without constant cloud dependency. +- Target profile RVA23U64: RVV 1.0, Zba/Zbb/Zbc, FP16 treated as mandatory baseline. +- Hardware tiers covered: microcontroller (MCU, <1 MB RAM), constrained SBC (1-512 MB), capable SBC / edge gateway (512 MB-8 GB), edge server (>8 GB). + +--- + +## Out of Scope (deliberately dropped, not classified) + +- On-device model training (full backprop, not fine-tuning) +- Federated learning server-side aggregation +- NVIDIA DeepStream (GPU-only pipeline) +- Model visualization tools (Netron, etc.) +- Cloud IoT brokers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) + +--- + +## Artifact 1 -- Stack Outline with Pipeline Chains + +### Pipeline Chains + +**TFLite vision inference pipeline (SBC):** +V4L2 (camera) -> OpenCV (preprocess) -> TFLite / LiteRT (inference) -> XNNPACK (acceleration) -> FlatBuffers (model load) + +**LLM inference pipeline (edge server):** +llama.cpp -> ggml (quantized kernels) -> OpenBLAS (GEMM) -> SLEEF (math) -> OpenSSL (model download TLS) + +**ONNX Runtime inference pipeline (edge server):** +ONNX Runtime CPU EP -> OpenBLAS -> SLEEF -> Protobuf (ONNX model parse) -> FlatBuffers + +**Edge AI container workload deployment:** +KubeEdge (orchestration) -> containerd (runtime) -> k3s (Kubernetes) -> Mender / SWUpdate (OTA) -> WireGuard (secure tunnel) + +**GStreamer camera AI pipeline:** +V4L2 (camera) -> GStreamer (pipeline) -> OpenCV (frame preprocess) -> TFLite / ONNX Runtime (inference) -> MQTT / Mosquitto (result publish) + +**Industrial IoT AI pipeline:** +open62541 (OPC UA sensor data) -> Mosquitto (MQTT bus) -> Node-RED (data routing) -> ONNX Runtime (anomaly detection) -> InfluxDB (time-series store) -> Prometheus + Grafana (monitoring) + +**Robotics perception pipeline (ROS 2):** +V4L2 / sensor drivers -> ROS 2 (pub/sub) -> FastDDS (transport) -> OpenCV / TFLite (perception) -> Nav2 (navigation) + +**Secure edge device boot chain:** +U-Boot (verified boot) -> Trusted Firmware-A (secure boot) -> OP-TEE (TEE) -> AppArmor (container isolation) -> WireGuard (network security) + +**Edge observability pipeline:** +edge AI service (Prometheus metrics) -> Prometheus node_exporter -> Fluent Bit (log ship) -> Grafana (dashboard) -> OpenTelemetry Collector (traces) + +**MCU TinyML pipeline (Zephyr):** +Zephyr RTOS -> TFLite Micro (TFLM) -> microTVM (optional compiler) -> MQTT / OpenThread (connectivity) -> micro-ROS (optional robot integration) + +**Federated learning edge round:** +Flower client -> TFLite / ONNX Runtime (local inference) -> local fine-tune step -> Mosquitto / gRPC (gradient upload) -> KubeEdge (workload management) + +### Layer Index + +| Layer | Title | +|---|---| +| 1 | ML Inference Runtimes | +| 2 | Model Optimization & Conversion | +| 3 | Kernel Libraries & Compute Primitives | +| 4 | Data Pipeline & Local Processing | +| 5 | Fleet Management, Orchestration, Observability, Debugging | +| 6 | Embedded OS & RTOS | +| 7 | Security | +| 8 | Domain-Specific (Robotics) | +| 9 | Domain-Specific (Industrial IoT) | +| 10 | Domain-Specific (Automotive) | +| 11 | Domain-Specific (Smart Home) | +| 12 | Federated Learning | +| 13 | Supporting Infrastructure | +| 14 | Excluded (proprietary / vendor-only) | + +--- + +## Artifact 2 -- Layer-by-Layer Node Classification + +### Color Key + +| Color | Meaning | +|---|---| +| Green | Fully supported: noarch / pure-language package, or upstream CI builds, tests, and releases for riscv64 with complete optimization coverage | +| Blue | Upstream CI builds and tests on riscv64; partial optimization gaps remain, or optimization coverage is mostly complete | +| Yellow | No upstream riscv64 test CI gate; distro or upstream ships riscv64 binary (build-only CI or clean-distro-build) | +| Orange | No upstream CI, no upstream release binary, and/or optimization is absent (downstream-only, community builds only) | +| Red | Broken: upstream CI fails on riscv64 | +| Grey | Not applicable: proprietary / vendor-only / architecture-locked | + +--- + +## Layer 1 -- ML Inference Runtimes + +### llama.cpp -- BLUE (critical) + +Native riscv64 CI on RISE-provided [ubuntu-24.04-riscv runners](https://github.com/ggerganov/llama.cpp/blob/master/.github/workflows/build-riscv.yml) builds with native gcc-14 and executes `ctest -L main` plus an end-to-end llama2c inference test on every push to master. Upstream publishes no riscv64 release binaries (PR [#20991](https://github.com/ggerganov/llama.cpp/pull/20991) remains open; issue [#20988](https://github.com/ggerganov/llama.cpp/issues/20988) was closed as not-planned); Debian 13 Trixie ships riscv64 packages `libllama0` and `libllama-dev`. Release provider: debian. + +**Gap:** quants.c has full RVV vec_dot coverage across all major formats (Q2_K through Q6_K, IQ1_S through IQ4_XS), but repack.cpp GEMM/GEMV tiled paths cover only Q4_0, Q4_K, Q2_K, Q8_0, and IQ4_NL -- Q3_K, Q5_K, and Q6_K tiled GEMM/GEMV paths are absent, leaving those formats at the vec_dot scalar-tiling fallback for batched matrix operations. + +--- + +### ONNX Runtime (edge / mobile EP) -- YELLOW (critical) + +No riscv64 CI exists in microsoft/onnxruntime: a live check on 2026-08-29 scanned all 51 [GitHub Actions workflow files](https://github.com/microsoft/onnxruntime/actions) and found zero riscv64 hits. Debian sid ships a riscv64 binary (v1.23.2+dfsg) built from unpatched upstream source -- the `+dfsg` suffix denotes DFSG source stripping only, not riscv64-specific patches -- which lifts the floor to yellow (clean-distro-build). Release provider: debian. + +**Gap:** The MLAS CPU EP has 11 RVV intrinsics files covering SGEMM, INT8/FP16 GEMM, convolution, pooling, LayerNorm, RMSNorm, RoPE, and activations; BF16 GEMM and FP16 RoPE are stubs. No riscv64 CI test gate. Blocking the TFLite vision pipeline and the ONNX Runtime inference pipeline at the test-validated level. + +--- + +### TensorFlow Lite / LiteRT -- ORANGE (critical) + +All 16 [GitHub Actions workflow files](https://github.com/google-ai-edge/LiteRT/tree/main/.github/workflows) (confirmed live 2026-08-29; 3 new files added since June 2026 report, all zero riscv64 references) contain no riscv64 jobs, no riscv64 wheel has ever appeared on PyPI, and LiteRT is absent from all Linux distro riscv64 repositories. As an optimization-purpose inference runtime whose primary value is accelerated CPU inference via XNNPACK, the optimization modifier caps at orange: 0 RVV files vs 4 NEON and 4 SSE files, with all RISC-V execution falling to scalar portable C. Release provider: none. + +**Blocking chain:** [cpuinfo #124](https://github.com/pytorch/cpuinfo/issues/124) (still open, Zvfh detection missing) and [XNNPACK #9886](https://github.com/google/XNNPACK/issues/9886) (still open, 100+ RVV FP16 CI failures). + +**Impact:** The TFLite vision pipeline (SBC) runs entirely at scalar C performance. The GStreamer camera AI pipeline is similarly degraded when using TFLite as the inference backend. + +--- + +### TensorFlow Lite Micro (TFLM) -- ORANGE (optional) + +Upstream CI in [suite_riscv.yml](https://github.com/tensorflow/tflite-micro/blob/main/.github/workflows/suite_riscv.yml) targets riscv32 MCU only (TARGET=riscv32_generic, arch rv32imc, QEMU riscv32); there is no riscv64 build target, no riscv64 CI, and no riscv64 release artifacts. The project provides architecture-specific optimized kernels for Cortex-M/CMSIS-NN, Hexagon, and Xtensa but has zero riscv64-specific kernel code, leaving all riscv64 paths as scalar C fallback. Release provider: none. + +**Gap:** The MCU TinyML pipeline (Zephyr) -- TFLM -> microTVM -- depends on riscv32 exclusively within TFLM upstream. RVA23U64 (riscv64 Linux) is untested and unoptimized. On MCU-class RISC-V hardware (rv32imc), riscv32 CI exists but Zephyr integration with RVV is not validated. + +--- + +### ExecuTorch -- YELLOW (critical) + +A riscv64 CI job exists in [executorch/.github/workflows/pull.yml](https://github.com/pytorch/executorch/blob/main/.github/workflows/pull.yml) that builds and runs under QEMU. The QEMU environment runs build validation but the riscv64-specific test suite execution is not gated as a blocking test pass requirement. RISE provides a riscv64 release binary/wheel as the release provider. + +**Gap:** QEMU-based build-only CI; riscv64 is not in the full test execution gate. Confidence: medium (upstream classification confirmed, no live adversarial change detected since 2026-06-17). + +--- + +### ncnn -- BLUE (critical) + +ncnn's upstream CI ([linux.yml](https://github.com/Tencent/ncnn/blob/master/.github/workflows/linux.yml)) includes a dedicated riscv64 cross-compile and QEMU test job that runs the full test suite (test-riscv64 via QEMU user-mode emulation, gcc-riscv64-linux-gnu toolchain). Upstream publishes no prebuilt riscv64 release binaries (source-only). Release provider: none. + +**Gap:** Upstream releases are source-only; no prebuilt binary for riscv64 deployment. RVV intrinsics in src/layer/riscv/ cover convolution, depthwise, innerproduct, pooling, upsampling, activations, and elementwise ops -- primary hot paths covered, partial coverage of the full operator set. + +--- + +### MNN (Alibaba) -- ORANGE (optional) + +No riscv64 CI job (confirmed live 2026-08-29: only arm64, armv7, x86 jobs present). No riscv64 release binaries. MNN has architecture-specific SIMD code for ARM (NEON/SVE2) in source/backend/cpu/arm/ but contains zero riscv64 RVV intrinsic files. Release provider: none. + +--- + +### PaddlePaddle Lite -- ORANGE (optional) + +No riscv64 CI (only ARM, x86, OpenCL targets in [.github/workflows/](https://github.com/PaddlePaddle/Paddle-Lite/tree/develop/.github/workflows)). No riscv64 release binary. All architecture-specific SIMD code is ARM NEON in lite/backends/arm/math/; zero RVV riscv64 files exist. Note: limited RISC-V MCU work exists in embedded contexts but is out of scope for this RVA23U64-targeted report. Release provider: none. + +--- + +### MindSpore Lite (Huawei) -- ORANGE (optional) + +No riscv64 CI job and no riscv64 release artifact (PyPI has no riscv64 wheel; GitHub Releases have ARM64, x86_64, and Windows assets only). All architecture-specific kernel code targets ARM (aarch64/armv7) and x86 (SSE/AVX). Huawei's primary focus is Ascend NPU and Kirin devices; RISC-V is not a stated target. Release provider: none. + +--- + +### OpenVINO Runtime -- YELLOW (critical) + +No upstream riscv64 CI (all [workflow files](https://github.com/openssl/openssl/blob/master/.github/workflows/os-zoo.yml) target x86_64, aarch64, and ARM only). Intel provides no upstream riscv64 release artifacts. Debian sid ships openvino-dev (v2024.4.0) and related packages for riscv64 from [unpatched upstream source](https://packages.debian.org/sid/openvino-dev). Release provider: debian. + +**Gap:** As an optimization-purpose runtime (Intel AVX-512/VNNI backends are its primary value), the optimization-absent modifier applies. The distro floor provides a scalar-only riscv64 build. No Intel-backed RISC-V optimization investment observed. + +--- + +### Apache TVM / microTVM -- YELLOW (optional) + +Apache TVM has a riscv64 cross-compile CI job in [main.yml](https://github.com/apache/tvm/blob/main/.github/workflows/main.yml) that builds TVM for riscv64 but does not execute the test suite natively (no QEMU full test execution). No riscv64 release binaries (PyPI wheels for x86_64, aarch64 only). microTVM explicitly targets RISC-V MCUs and has active RISC-V code generation. Release provider: none. + +--- + +### whisper.cpp -- BLUE (optional) + +[build-riscv.yml](https://github.com/ggerganov/whisper.cpp/blob/master/.github/workflows/build-riscv.yml) builds with native gcc-14 on the RISE ubuntu-24.04-riscv runner and executes `ctest`. No upstream riscv64 release binary; Debian ships whisper.cpp packages. Release provider: debian. + +**Gap:** Shares the ggml RVV kernel coverage with llama.cpp: vec_dot paths covered across all major formats; Q3_K, Q5_K, Q6_K tiled GEMM/GEMV paths absent, capping at blue. + +--- + +### Layer 1 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| llama.cpp | BLUE | critical | debian | +| ONNX Runtime (edge / mobile EP) | YELLOW | critical | debian | +| TensorFlow Lite / LiteRT | ORANGE | critical | none | +| TensorFlow Lite Micro (TFLM) | ORANGE | optional | none | +| ExecuTorch | YELLOW | critical | RISE | +| ncnn | BLUE | critical | none | +| MNN (Alibaba) | ORANGE | optional | none | +| PaddlePaddle Lite | ORANGE | optional | none | +| MindSpore Lite (Huawei) | ORANGE | optional | none | +| OpenVINO Runtime | YELLOW | critical | debian | +| Apache TVM / microTVM | YELLOW | optional | none | +| whisper.cpp | BLUE | optional | debian | + +**Critical-path risk:** TFLite / LiteRT is ORANGE on both the TFLite vision inference pipeline (SBC) and the GStreamer camera AI pipeline. These are the two highest-volume edge vision deployment patterns. The blocking dependency runs through XNNPACK (YELLOW, open FP16 failures) and cpuinfo (missing Zvfh detection). + +--- + +## Layer 2 -- Model Optimization & Conversion + +### ONNX (format + tooling) -- YELLOW (critical) + +ONNX is not pure Python: it includes a C++ protobuf extension and generates binary wheels with C extensions. The PyPI riscv64 wheel (v1.22.0) is provided by RISE, not upstream -- upstream [onnx_main.yml](https://github.com/onnx/onnx/blob/main/.github/workflows/main.yml) builds and tests on Linux x86_64 and macOS only, with no riscv64 job. Release provider: RISE. + +**Note:** Previously classified green (pure Python noarch) in project report 2026-05-06; downgraded to yellow after live adversarial check confirmed C extension wheels and RISE-only riscv64 wheel. + +--- + +### Intel Neural Compressor (INC) -- GREEN (optional) + +Pure-Python package (no C extensions, no compiled wheels). PyPI `neural-compressor` ships sdist + noarch wheel only. Installs on riscv64 from the same noarch wheel without modification. Release provider: upstream. + +--- + +### NNCF (Neural Network Compression Framework, Intel) -- GREEN (optional) + +Pure-Python package. PyPI `nncf` ships sdist and py3-none-any wheel only. Upstream CI tests on x86_64 Linux but the noarch wheel installs on riscv64 without modification. Release provider: upstream. + +--- + +### HuggingFace Optimum -- GREEN (optional) + +Pure-Python package. PyPI `optimum` ships a py3-none-any wheel only. Release provider: upstream. + +--- + +### Layer 2 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| ONNX (format + tooling) | YELLOW | critical | RISE | +| Intel Neural Compressor (INC) | GREEN | optional | upstream | +| NNCF (Intel) | GREEN | optional | upstream | +| HuggingFace Optimum | GREEN | optional | upstream | + +**Note:** Layer 2 is in good shape for pure-Python optimization tooling. The only critical-path item (ONNX format) is YELLOW because of C extension wheels; RISE fills the gap. + +--- + +## Layer 3 -- Kernel Libraries & Compute Primitives + +### XNNPACK -- YELLOW (critical) + +[cmake-linux-riscv.yml](https://github.com/google/XNNPACK/blob/master/.github/workflows/cmake-linux-riscv.yml) runs a riscv64 QEMU build-and-run job, but [GitHub issue #9886](https://github.com/google/XNNPACK/issues/9886) (still open) confirms 100+ RVV FP16 CI failures. Optimization coverage: substantial RVV 1.0 kernels for FP32 and INT8 paths (GEMM, convolution, depthwise); the FP16 (Zvfh) path is incomplete/failing. No upstream release binary. Release provider: none. + +**Impact:** XNNPACK is the sole acceleration backend for TFLite / LiteRT on RISC-V. Its FP16 failures propagate to TFLite, blocking FP16 inference on all hardware tiers that depend on the TFLite vision pipeline. + +--- + +### OpenBLAS -- BLUE (critical) + +[test_riscv.yml](https://github.com/OpenMathLib/OpenBLAS/blob/develop/.github/workflows/test_riscv.yml) runs the full BLAS test suite on QEMU riscv64 on every PR. GEMM for most dtypes has RVV 1.0 kernels. TRSM PR #5830 (merged 2026-08-16) completed the triangular-solve RVV 1.0 path. Debian ships the riscv64 binary. Release provider: debian. + +**Delta since last report (2026-08-16):** TRSM PR #5830 merged, completing the triangular-solve path. The stored report's "TRSM partially covered" note is now resolved. Blue confirmed with no remaining known optimization gaps. + +--- + +### SLEEF -- BLUE (critical) + +Full RVV v1.0 backend covering single- and double-precision transcendentals. [CI](https://github.com/shibatch/sleef/blob/master/.github/workflows/build_and_test.yml) runs both a native riscv64 hardware Jenkins job (SLEEF-maintained board) and a QEMU-based GitHub Actions job -- both pass. Debian ships `libsleef-dev` for riscv64. Release provider: debian (upstream ships source only). + +--- + +### ARM Compute Library (ACL) -- GREY / N/A (optional) + +ARM-only (Cortex-A NEON/SVE and Mali GPU via OpenCL). No RISC-V port exists and none is planned. Proprietary ARM-architecture kernel library not applicable to RISC-V. Classified under Layer 14 for exclusion tracking. + +--- + +### RUY (Google matrix multiply) -- ORANGE (optional) + +[build.yml](https://github.com/google/ruy/blob/master/.github/workflows/build.yml) contains no riscv64 job (only x86_64 and aarch64). No riscv64 release artifact. Zero riscv64-specific SIMD kernels in ruy/kernel_* (only arm, x86, avx, avx512 files). All RISC-V execution falls through to the generic scalar C path (ruy/kernel_default.h). Release provider: none. + +**Impact:** RUY is the INT8 GEMM backend used by TFLite for quantized inference on non-XNNPACK paths. Its scalar-only posture compounds the TFLite orange classification. + +--- + +### FlatBuffers -- YELLOW (critical) + +[build.yml](https://github.com/google/flatbuffers/blob/master/.github/workflows/build.yml) has no riscv64 job (only x86_64 and macOS). No upstream riscv64 release binary. Debian sid ships `libflatbuffers-dev` for riscv64 from unpatched upstream source. Not optimization-purpose (serialization library). Release provider: debian. + +--- + +### Layer 3 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| XNNPACK | YELLOW | critical | none | +| OpenBLAS | BLUE | critical | debian | +| SLEEF | BLUE | critical | debian | +| ARM Compute Library (ACL) | GREY/N/A | optional | none | +| RUY | ORANGE | optional | none | +| FlatBuffers | YELLOW | critical | debian | + +**Key finding:** The GEMM/math foundation (OpenBLAS + SLEEF) is solid at BLUE. The TFLite acceleration path (XNNPACK + RUY) remains the primary gap. The LLM inference pipeline and ONNX Runtime inference pipeline have a healthy kernel layer. The TFLite vision pipeline kernel layer is the weak point. + +--- + +## Layer 4 -- Data Pipeline & Local Processing + +### OpenCV -- BLUE (critical) + +[linux.yml](https://github.com/opencv/opencv/blob/4.x/.github/workflows/linux.yml) includes the riscv64 cross-compile + QEMU test step. Ubuntu 26.04 Resolute ships libopencv-* for riscv64. Active RVV 1.0 HAL in modules/core/src/hal/ with RVV kernels for core image operations. Partial: core/imgproc covered; calib3d, features2d less so. Release provider: ubuntu. + +--- + +### GStreamer -- YELLOW (critical) + +[ci.yml](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/.gitlab-ci.yml) has no riscv64 job. Debian sid ships gstreamer1.0-* for riscv64. GStreamer is a framework, not a SIMD compute library; no optimization modifier. Release provider: debian. + +--- + +### MediaPipe -- ORANGE (optional) + +All [workflow files](https://github.com/google/mediapipe/tree/master/.github/workflows) target Linux x86_64, macOS, Android, iOS only. No riscv64 release binary on PyPI or GitHub Releases. Optimization-purpose framework (CPU path uses XNNPACK + platform SIMD); zero RISC-V RVV kernels in the codebase, ARM-primary SIMD dispatch. Release provider: none. + +--- + +### Mosquitto (Eclipse) -- YELLOW (critical) + +[build.yml](https://github.com/eclipse/mosquitto/blob/master/.github/workflows/build.yml) targets Linux x86_64, macOS, Windows only. Debian ships `libmosquitto1`, `libmosquittopp1`, `mosquitto`, and `mosquitto-clients` for riscv64 from unpatched upstream source. Networking daemon, not optimization-purpose. Release provider: debian. + +--- + +### Node-RED -- GREEN (optional) + +Pure-JavaScript / Node.js package with no native C extensions. The `@node-red/node-red` npm package is arch-independent. Runs on any Node.js platform including riscv64. Release provider: upstream. + +--- + +### InfluxDB (edge / v1.x) -- YELLOW (optional) + +Written in Go. Upstream CI does not include a riscv64 build/test job. Debian ships `influxdb` 1.6.7 for riscv64. Go binaries cross-compile cleanly for riscv64. Release provider: debian. + +--- + +### SQLite -- YELLOW (critical) + +Pure C with no architecture-specific assembly (all platforms use the portable C amalgamation). Upstream CI tests only on x86_64/macOS. Debian ships `libsqlite3-0` for riscv64 from unpatched upstream. No optimization modifier (not optimization-purpose). Release provider: debian. + +--- + +### V4L2 (Video4Linux2) -- YELLOW (critical) + +V4L2 is a Linux kernel subsystem; RISC-V is a primary kernel target since Linux 5.4, with full V4L2 framework support. Upstream Linux kernel CI does not run V4L2 userspace API tests on riscv64 specifically, but the kernel itself builds on riscv64 as part of standard kernel CI. Userspace tooling (`v4l2-utils`, `libv4l-dev`) ships in Debian riscv64 from unpatched upstream. Release provider: upstream (Linux kernel, Debian v4l-utils). + +--- + +### Layer 4 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| OpenCV | BLUE | critical | ubuntu | +| GStreamer | YELLOW | critical | debian | +| MediaPipe | ORANGE | optional | none | +| Mosquitto (Eclipse) | YELLOW | critical | debian | +| Node-RED | GREEN | optional | upstream | +| InfluxDB (edge / v1.x) | YELLOW | optional | debian | +| SQLite | YELLOW | critical | debian | +| V4L2 (Video4Linux2) | YELLOW | critical | upstream | + +**Note:** The data pipeline layer is in a reasonable state for the non-AI-acceleration components. OpenCV at BLUE provides solid frame preprocessing. The critical camera capture path (V4L2) works. The weak spot is MediaPipe (ORANGE), but it is classified optional. + +--- + +## Layer 5 -- Fleet Management, Orchestration, Observability, Debugging + +### k3s (Rancher) -- ORANGE (critical) + +[Releases page](https://github.com/k3s-io/k3s/releases) lists linux-amd64, linux-arm64, linux-arm, linux-s390x only; no riscv64. [ci.yml](https://github.com/k3s-io/k3s/blob/master/.github/workflows/ci.yml) runs integration tests on amd64 only. Community builds exist (via Go cross-compilation) but are unofficial and unsupported. Note: k0s merged riscv64 nightly CI in June 2026 on RISE hardware; k3s has not followed suit. Release provider: none. + +**Impact:** k3s is the most widely deployed lightweight Kubernetes distribution for edge. Its absence at riscv64 forces edge AI container workload deployment to either k0s (BLUE) or community-build approaches. This blocks the Edge AI container workload deployment pipeline at the orchestration layer. + +--- + +### k0s -- BLUE (optional) + +[nightly.yml](https://github.com/k0sproject/k0s/blob/main/.github/workflows/nightly.yml) shows riscv64 job running on RISE-provided runners with full e2e test execution (merged June 2026). k0s v1.30+ ships official riscv64 binaries on its [releases page](https://github.com/k0sproject/k0s/releases). Release provider: upstream. + +**Note:** k0s is the viable alternative to k3s for riscv64 Kubernetes edge deployments. + +--- + +### KubeEdge -- ORANGE (critical) + +[main.yaml](https://github.com/kubeedge/kubeedge/blob/master/.github/workflows/main.yaml) runs on amd64 only. [GitHub Releases](https://github.com/kubeedge/kubeedge/releases) provide linux-amd64, linux-arm64, linux-arm only; no riscv64 binary. Community riscv64 build success via Go cross-compilation reported but no upstream support. Release provider: none. + +**Impact:** KubeEdge is the critical orchestration layer in both the Edge AI container workload deployment pipeline and the federated learning edge round pipeline. Both pipelines are at risk. + +--- + +### containerd -- YELLOW (critical) + +[ci.yml](https://github.com/containerd/containerd/blob/main/.github/workflows/ci.yml) cross-compiles for riscv64 but the integration test matrix excludes riscv64. Upstream GitHub Releases include linux/riscv64 binaries starting from v1.7.x. Debian ships the riscv64 binary from unpatched source. Release provider: debian (upstream also ships riscv64 binaries; classification follows stored report posture of yellow pending riscv64 test CI). + +--- + +### crun -- YELLOW (optional) + +[ci.yml](https://github.com/containers/crun/blob/main/.github/workflows/ci.yml) tests on x86_64 and aarch64 only. Debian ships `crun` for riscv64 from unpatched upstream C source. Release provider: debian. + +--- + +### WasmEdge -- ORANGE (optional) + +[build.yml](https://github.com/WasmEdge/WasmEdge/blob/master/.github/workflows/build.yml) targets Linux x86_64, Linux aarch64, macOS, Android only. GitHub Releases provide riscv64 builds as a community/downstream contribution (not official upstream release assets). WASI-NN plugin for ML inference is not included in the community riscv64 builds. Release provider: none. + +--- + +### Mender.io -- YELLOW (critical) + +[ci.yml](https://github.com/mendersoftware/mender/blob/master/.github/workflows/ci.yml) runs on x86_64 only. Debian ships `mender-client4`, `mender-artifact`, `mender-connect` for riscv64 from unpatched upstream Go source. Release provider: debian. + +--- + +### SWUpdate -- YELLOW (critical) + +[build.yml](https://github.com/sbabic/swupdate/blob/master/.github/workflows/build.yml) targets Linux x86_64 only. Debian ships `swupdate` and `libswupdate-dev` for riscv64 from unpatched upstream C source. Release provider: debian. + +--- + +### RAUC (Robust Auto-Update Controller) -- YELLOW (optional) + +[build.yml](https://github.com/rauc/rauc/blob/master/.github/workflows/build.yml) targets Linux x86_64 only with QEMU for ARM. Debian ships `rauc` for riscv64 from unpatched upstream C source. Release provider: debian. + +--- + +### Eclipse hawkBit -- GREEN (optional) + +Java-based Spring Boot application. JVM applications are architecture-independent (the JAR runs on any JVM, including OpenJDK for riscv64). Release provider: upstream. + +--- + +### balenaCloud / balenaOS -- ORANGE (optional) + +The [balena-io/balena-os device list](https://www.balena.io/docs/reference/hardware/devices/) contains no RISC-V entries; all supported devices are ARM or x86. balena-engine compiles for riscv64 in principle but upstream balena provides no riscv64 images or packages. Release provider: none. + +--- + +### AWS IoT Greengrass v2 -- ORANGE (optional) + +The [supported platforms list](https://docs.aws.amazon.com/greengrass/v2/developerguide/operating-system-feature-support-matrix.html) covers Linux x86_64, Linux aarch64, Linux armv7l, and Windows x86_64 only. No riscv64 nucleus binary available from AWS. Release provider: none. + +--- + +### Azure IoT Edge -- ORANGE (optional) + +The [supported platforms page](https://docs.microsoft.com/en-us/azure/iot-edge/support) lists Linux x86_64, Linux aarch64, Linux armv7l only. No riscv64 package available in the Azure IoT Edge apt repository. Release provider: none. + +--- + +### Red Hat Device Edge (MicroShift) -- ORANGE (optional) + +MicroShift targets RHEL for Edge which runs on x86_64 and aarch64. No riscv64 RPM package in any Red Hat repository. [ci.yaml](https://github.com/openshift/microshift/blob/main/.github/workflows/ci.yaml) runs exclusively on x86_64. Release provider: none. + +--- + +### Akri (Kubernetes device plugin) -- ORANGE (optional) + +[build-release.yml](https://github.com/project-akri/akri/blob/main/.github/workflows/build-release.yml) targets linux/amd64, linux/arm64, linux/arm/v7 only; no riscv64 Docker image tag on ghcr.io/project-akri. Release provider: none. + +--- + +### OSTree / rpm-ostree -- YELLOW (optional) + +[tests.yml](https://github.com/ostreedev/ostree/blob/main/.github/workflows/tests.yml) tests on Fedora/Ubuntu x86_64 only. Debian ships `ostree`, `libostree-1-1`, `libostree-dev` for riscv64 from unpatched upstream C source. Release provider: debian. + +--- + +### Uptane (automotive OTA standard) -- GREEN (optional) + +Specification standard; the Python reference implementation (`tuf` and `uptane` packages) are pure Python. Architecture-independent standard + pure-Python reference implementation. Release provider: upstream. + +--- + +### Prometheus -- YELLOW (critical) + +[build.yml](https://github.com/prometheus/prometheus/blob/main/.github/workflows/build.yml) includes a `GOARCH=riscv64` cross-compile step but no `go test` for riscv64. Upstream [GitHub Releases](https://github.com/prometheus/prometheus/releases) include `prometheus-*.linux-riscv64.tar.gz` on every release. Release provider: upstream. + +--- + +### Grafana -- YELLOW (critical) + +Go + React application. Upstream CI cross-compiles for riscv64 but does not run integration tests on riscv64. [GitHub Releases](https://github.com/grafana/grafana/releases) include `grafana-*.linux-riscv64.tar.gz` binaries on every release. Release provider: upstream. + +--- + +### Fluent Bit -- BLUE (critical) + +[ci.yml](https://github.com/fluent/fluent-bit/blob/master/.github/workflows/) includes riscv64 in its platform matrix with test execution using QEMU. The test step executes the Fluent Bit unit test suite on QEMU riscv64. Upstream provides no prebuilt riscv64 release binary; users must build from source or use Debian packages. Not optimization-purpose. Release provider: none. + +--- + +### Telegraf -- YELLOW (optional) + +[build.yml](https://github.com/influxdata/telegraf/blob/master/.github/workflows/build.yml) includes GOARCH=riscv64 cross-compile; no riscv64 test step. [GitHub Releases](https://github.com/influxdata/telegraf/releases) include `telegraf_*_linux_riscv64.tar.gz` on every release. Release provider: upstream. + +--- + +### OpenTelemetry Collector (edge) -- YELLOW (optional) + +[build-and-test.yml](https://github.com/open-telemetry/opentelemetry-collector/blob/main/.github/workflows/build-and-test.yml) includes GOARCH=riscv64 cross-compile; no riscv64 test execution. [GitHub Releases](https://github.com/open-telemetry/opentelemetry-collector/releases) include otelcol-contrib_*_linux_riscv64.tar.gz. Release provider: upstream. + +--- + +### GDB / gdbserver -- YELLOW (critical) + +GDB has extensive RISC-V target support (riscv-tdep.c, riscv-linux-nat.c). [Sourceware upstream CI](https://sourceware.org/git/binutils-gdb.git) does not include a riscv64 native host CI job. Debian ships `gdb`, `gdb-multiarch`, `gdbserver` for riscv64 from unpatched upstream source. Not optimization-purpose. Release provider: debian. + +--- + +### OpenOCD -- YELLOW (optional) + +[build.yml](https://github.com/openocd-org/openocd/blob/master/.github/workflows/build.yml) targets Linux x86_64, macOS, and Windows only. Debian ships `openocd` for riscv64 from unpatched upstream C source. OpenOCD includes RISC-V JTAG debug transport support (riscv/ directory in src/target/). Release provider: debian. + +--- + +### perf (Linux perf tools) -- YELLOW (optional) + +Linux perf is part of the kernel tree and builds for riscv64 as part of standard kernel CI. The riscv64 PMU infrastructure is upstream in arch/riscv/kernel/perf_event.c and perf_regs.c. Debian ships `linux-perf` for riscv64. No dedicated perf tool test gate for riscv64. Release provider: upstream. + +--- + +### Layer 5 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| k3s (Rancher) | ORANGE | critical | none | +| k0s | BLUE | optional | upstream | +| KubeEdge | ORANGE | critical | none | +| containerd | YELLOW | critical | debian | +| crun | YELLOW | optional | debian | +| WasmEdge | ORANGE | optional | none | +| Mender.io | YELLOW | critical | debian | +| SWUpdate | YELLOW | critical | debian | +| RAUC | YELLOW | optional | debian | +| Eclipse hawkBit | GREEN | optional | upstream | +| balenaCloud / balenaOS | ORANGE | optional | none | +| AWS IoT Greengrass v2 | ORANGE | optional | none | +| Azure IoT Edge | ORANGE | optional | none | +| Red Hat Device Edge (MicroShift) | ORANGE | optional | none | +| Akri | ORANGE | optional | none | +| OSTree / rpm-ostree | YELLOW | optional | debian | +| Uptane | GREEN | optional | upstream | +| Prometheus | YELLOW | critical | upstream | +| Grafana | YELLOW | critical | upstream | +| Fluent Bit | BLUE | critical | none | +| Telegraf | YELLOW | optional | upstream | +| OpenTelemetry Collector (edge) | YELLOW | optional | upstream | +| GDB / gdbserver | YELLOW | critical | debian | +| OpenOCD | YELLOW | optional | debian | +| perf (Linux perf tools) | YELLOW | optional | upstream | + +**Key finding:** Two critical-path components -- k3s and KubeEdge -- are ORANGE. The predominant edge AI container workload deployment pattern breaks at the orchestration layer. k0s (BLUE) is a viable riscv64 alternative to k3s. The observability stack (Prometheus, Grafana, Fluent Bit) is in adequate shape: two YELLOW and one BLUE. + +--- + +## Layer 6 -- Embedded OS & RTOS + +### Zephyr RTOS -- GREEN (critical) + +RISC-V is a first-class Zephyr target with upstream CI building and running tests on multiple RISC-V boards (QEMU virt, SiFive HiFive1 Rev B, ESP32-C3, and others). RISC-V is listed as a supported architecture in the official [Zephyr documentation](https://docs.zephyrproject.org/latest/boards/riscv/index.html). Upstream ships the Zephyr SDK including riscv64-zephyr-elf toolchain. Release provider: upstream. + +**Note:** Zephyr's green classification anchors the MCU TinyML pipeline (Zephyr) at a solid foundation, even as TFLM (ORANGE) and micro-ROS (ORANGE) are weak above it. + +--- + +### FreeRTOS -- ORANGE (critical) + +FreeRTOS has a RISC-V port in [FreeRTOS-Kernel/portable/GCC/RISC-V/](https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/main/portable/GCC/RISC-V) but upstream [ci.yml](https://github.com/FreeRTOS/FreeRTOS/blob/main/.github/workflows/ci.yml) tests on Linux x86_64 host only; the RISC-V portable layer is not in the CI matrix. No upstream release binary for riscv64 Linux (source-only RTOS). The RISC-V portable layer is maintained by community contributors. Release provider: none. + +--- + +### RT-Thread -- YELLOW (optional) + +[scons.yml](https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/scons.yml) builds multiple RISC-V BSPs (K210, GD32VF103, D1) as part of the matrix build. No test execution CI for riscv64 Linux host (RT-Thread is an RTOS; CI builds firmware images). Upstream SDK and releases include RISC-V BSP downloads. Release provider: upstream. + +--- + +### Yocto Project -- YELLOW (critical) + +Yocto Project CI ([autobuilder.yoctoproject.org](https://autobuilder.yoctoproject.org)) builds RISC-V images (qemuriscv64 target) as part of its release CI. The [meta-riscv](https://github.com/riscv/meta-riscv) BSP layer is maintained upstream. No riscv64 runtime test gate in the Autobuilder (build completion only). Release provider: upstream. + +--- + +### Buildroot -- YELLOW (critical) + +[Buildroot CI](https://gitlab.com/buildroot.org/buildroot/-/pipelines) includes a riscv64 defconfig build (qemu_riscv64_virt_defconfig) as a runtime test target (boots in QEMU and runs a basic test). The QEMU boot test confirms a functional rootfs. No full test suite execution. Release provider: upstream. + +--- + +### Ubuntu Core -- ORANGE (optional) + +The [Ubuntu Core download page](https://ubuntu.com/download/iot) lists arm64, armhf, x86_64, and some SBC-specific images; no riscv64. snapd itself builds for riscv64 (Debian ships it) but the full Ubuntu Core image pipeline does not produce riscv64. Release provider: none. + +--- + +### Flatcar Container Linux -- ORANGE (optional) + +[Supported platforms](https://www.flatcar.org/docs/latest/installing/) are amd64 and arm64 only. No community RISC-V image exists. Release provider: none. + +--- + +### OpenWRT -- YELLOW (optional) + +Upstream CI at [buildbot.openwrt.org](https://buildbot.openwrt.org/) includes experimental riscv64 targets (qemu-riscv32 and qemu-riscv64) that build successfully; marked experimental and do not undergo full hardware test matrix. Upstream [ships riscv64 image downloads](https://downloads.openwrt.org/releases/). Release provider: upstream. + +--- + +### micro-ROS (RTOS layer for ROS 2) -- ORANGE (optional) + +micro-ROS targets MCU-class hardware (FreeRTOS, Zephyr, NuttX). Zephyr integration supports RISC-V MCU targets, but upstream micro-ROS CI ([build.yml](https://github.com/micro-ROS/micro_ros_arduino/blob/main/.github/workflows/build.yml)) does not include a RISC-V target in its Arduino or RTOS CI matrix. No upstream riscv64 release. RISC-V board support flows through Zephyr integration but has no upstream micro-ROS CI or release. Release provider: none. + +--- + +### Layer 6 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| Zephyr RTOS | GREEN | critical | upstream | +| FreeRTOS | ORANGE | critical | none | +| RT-Thread | YELLOW | optional | upstream | +| Yocto Project | YELLOW | critical | upstream | +| Buildroot | YELLOW | critical | upstream | +| Ubuntu Core | ORANGE | optional | none | +| Flatcar Container Linux | ORANGE | optional | none | +| OpenWRT | YELLOW | optional | upstream | +| micro-ROS | ORANGE | optional | none | + +**Key finding:** The two dominant embedded build systems for edge AI devices (Yocto, Buildroot) are both YELLOW -- functional but without a test gate. Zephyr (GREEN) is the strongest riscv64 RTOS. FreeRTOS (ORANGE, critical) is a gap: it is the most widely used MCU RTOS globally and its riscv64 portable layer has no upstream CI test. + +--- + +## Layer 7 -- Security + +### OP-TEE (Open Portable Trusted Execution Environment) -- ORANGE (optional) + +OP-TEE is ARM TrustZone-first. [ci.yml](https://github.com/OP-TEE/optee_os/blob/master/.github/workflows/ci.yml) builds and tests for ARM Cortex-A targets only. The RISC-V TEE path (Keystone Enclave) is a separate project with a different codebase, not a port of OP-TEE. No upstream riscv64 OP-TEE CI or release. Release provider: none. + +**Note:** This is a meaningful gap in the Secure edge device boot chain pipeline. The chain U-Boot -> Trusted Firmware-A -> OP-TEE -> AppArmor -> WireGuard has OP-TEE as ORANGE. The RISC-V TEE alternative (Keystone) is not classified in this report as it falls outside the scope of direct OP-TEE assessment. + +--- + +### AppArmor -- YELLOW (critical) + +[gitlab-ci.yml](https://gitlab.com/apparmor/apparmor/-/blob/master/.gitlab-ci.yml) does not include a riscv64 CI job. Debian ships `apparmor`, `libapparmor1`, `libapparmor-dev` for riscv64 from unpatched upstream source. Not optimization-purpose. Release provider: debian. + +--- + +### WireGuard -- YELLOW (critical) + +WireGuard is in-kernel since Linux 5.6. Debian ships `wireguard-tools` and `wireguard-go` for riscv64. No dedicated riscv64 CI beyond standard kernel CI. The WireGuard-specific cryptography paths are generic C without RISC-V hardware acceleration (Zvkned/Zvkg extensions unused). Release provider: debian. + +**Note:** The Zvkned/Zvkg extensions for WireGuard cryptography (ChaCha20-Poly1305) are not yet wired up in the upstream kernel implementation for RISC-V, leaving WireGuard at scalar C for Curve25519 and ChaCha20 on riscv64. + +--- + +### SPIFFE / SPIRE -- YELLOW (optional) + +[build_and_release.yml](https://github.com/spiffe/spire/blob/main/.github/workflows/build_and_release.yml) cross-compiles for linux/riscv64 but does not run integration tests. [GitHub Releases](https://github.com/spiffe/spire/releases) include linux-riscv64 binaries (spire-agent, spire-server). Release provider: upstream. + +--- + +### Falco -- ORANGE (optional) + +[ci.yml](https://github.com/falcosecurity/falco/blob/master/.github/workflows/ci.yml) targets Linux x86_64 only; [GitHub Releases](https://github.com/falcosecurity/falco/releases) provide x86_64 and aarch64 packages only. The eBPF probe requires kernel 5.8+ (available on riscv64) and the kernel module would require a riscv64 build. No community riscv64 port exists. Release provider: none. + +--- + +### OpenSSL -- BLUE (critical) + +[os-zoo.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/os-zoo.yml) now includes a native riscv64 self-hosted runner with FIPS testing (added 2026-08-07, upgraded from QEMU-based testing). Ubuntu 26.04 Resolute ships libssl3 for riscv64. Release provider: ubuntu. + +**Delta since last report (2026-08-07):** Native RISC-V self-hosted runner with FIPS testing added, replacing QEMU-based CI. Strengthens the blue classification. + +**Gap:** AES constant-time optimization via Zvkned extension (openssl/crypto/aes/asm/aes-riscv64-zvkned.pl) requires Zvkned, which is not mandatory in RVA23U64. AES on RVA23U64 baseline falls back to the portable C implementation. + +--- + +### U-Boot (secure boot) -- BLUE (critical) + +[ci.yml](https://github.com/u-boot/u-boot/blob/master/.github/workflows/ci.yml) includes QEMU riscv64 boot targets (qemu_riscv64_smode, qemu_riscv64_smode_spl) that boot to U-Boot prompt and run basic tests. Ubuntu 26.04 Resolute ships `u-boot-qemu` and related packages for riscv64. Release provider: ubuntu. + +--- + +### Layer 7 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| OP-TEE | ORANGE | optional | none | +| AppArmor | YELLOW | critical | debian | +| WireGuard | YELLOW | critical | debian | +| SPIFFE / SPIRE | YELLOW | optional | upstream | +| Falco | ORANGE | optional | none | +| OpenSSL | BLUE | critical | ubuntu | +| U-Boot (secure boot) | BLUE | critical | ubuntu | + +**Key finding:** The boot security foundation (U-Boot + OpenSSL) is solid at BLUE. The runtime security layer has gaps: OP-TEE (the TEE layer) is ORANGE; Falco (runtime threat detection) is ORANGE. WireGuard is YELLOW and missing Zvkned/Zvkg acceleration. The Secure edge device boot chain pipeline has one orange node (OP-TEE) in the middle, which must be substituted with a RISC-V-native TEE solution (Keystone or equivalent). + +--- + +## Layer 8 -- Domain-Specific (Robotics) + +### ROS 2 (Robot Operating System 2) -- YELLOW (critical) + +Upstream [nightly.yml](https://github.com/ros2/ros2/blob/rolling/.github/workflows/nightly.yml) builds and tests on Ubuntu amd64 and aarch64 only. A riscv64 cross-compile is possible via colcon and the standard ROS 2 build process. No official riscv64 package release from OSRF or Debian/Ubuntu ROS repos. Community builds exist (individual contributor efforts, not RISE-provided). Release provider: none. + +**Note:** Confidence is medium due to the community-build classification. The core stack cross-compiles, but the absence of an official release and a test gate means riscv64 reliability is unverified at the framework level. + +--- + +### Nav2 (Navigation 2) -- YELLOW (optional) + +Follows ROS 2 build infrastructure. [ci.yaml](https://github.com/ros-navigation/navigation2/blob/main/.github/workflows/ci.yaml) has no dedicated riscv64 CI or release binary. riscv64 build feasibility follows the same community cross-build path as ROS 2. Release provider: none. + +--- + +### MoveIt 2 -- YELLOW (optional) + +Depends on ROS 2; follows the same riscv64 build path: cross-compilation is possible but no upstream riscv64 CI or official release. [ci.yaml](https://github.com/moveit/moveit2/blob/main/.github/workflows/ci.yaml) has no riscv64 job. Release provider: none. + +--- + +### FastDDS (eProsima) -- YELLOW (critical) + +[reusable-ci.yml](https://github.com/eProsima/Fast-DDS/blob/master/.github/workflows/reusable-ci.yml) targets Linux x86_64, macOS, Windows only. Debian ships `libfastdds3.1` for riscv64 from unpatched upstream C++ source. Release provider: debian. + +--- + +### CycloneDDS (Eclipse) -- YELLOW (optional) + +[build-test.yml](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/.github/workflows/build-test.yml) targets Linux x86_64, macOS, Windows. Debian ships `libcyclonedds-dev` for riscv64 from unpatched upstream C source. Release provider: debian. + +--- + +### Iceoryx (Eclipse) -- YELLOW (optional) + +[build-test.yml](https://github.com/eclipse-iceoryx/iceoryx/blob/main/.github/workflows/build-test.yml) targets Linux x86_64, macOS, Windows. Debian ships `iceoryx-dev` for riscv64. Release provider: debian. + +--- + +### Layer 8 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| ROS 2 | YELLOW | critical | none | +| Nav2 | YELLOW | optional | none | +| MoveIt 2 | YELLOW | optional | none | +| FastDDS | YELLOW | critical | debian | +| CycloneDDS | YELLOW | optional | debian | +| Iceoryx | YELLOW | optional | debian | + +**Key finding:** The entire robotics layer is YELLOW. No project has a riscv64 test CI gate with release. The Robotics perception pipeline (ROS 2) is deployable in principle through community builds, but there is no upstream-validated riscv64 binary for ROS 2 itself. The communication middleware (FastDDS, CycloneDDS, Iceoryx) is available via Debian but untested upstream for riscv64. + +--- + +## Layer 9 -- Domain-Specific (Industrial IoT) + +### open62541 (OPC UA) -- YELLOW (critical) + +[build_and_run_tests.yml](https://github.com/open62541/open62541/blob/master/.github/workflows/build_and_run_tests.yml) targets Linux x86_64, macOS, Windows. Debian ships `libopen62541-1-dev` for riscv64 from unpatched C99 upstream source. Release provider: debian. + +--- + +### Eclipse Ditto -- GREEN (optional) + +Java/Scala Spring Boot application. JVM applications are architecture-independent; the JAR runs on any platform with OpenJDK (including riscv64). Release provider: upstream. + +--- + +### FIWARE Orion Context Broker -- ORANGE (optional) + +[ci.yml](https://github.com/telefonicaid/fiware-orion/blob/master/.github/workflows/ci.yml) builds on Linux x86_64 only. No riscv64 Docker image on Docker Hub (telefonicaid/fiware-orion images are x86_64-only). No Debian package for riscv64. C++ with MongoDB dependency; no community riscv64 port confirmed. Release provider: none. + +--- + +### EMQX -- YELLOW (optional) + +Erlang-based. EMQX upstream CI ([build_and_test.yml](https://github.com/emqx/emqx/blob/master/.github/workflows/build_and_test.yml)) includes cross-compilation for multiple platforms; no dedicated riscv64 test execution. [GitHub Releases](https://github.com/emqx/emqx/releases) include linux-riscv64 packages (emqx_*-linux-riscv64.tar.gz) starting from EMQX v5.x. Release provider: upstream. Confidence: medium. + +--- + +### Layer 9 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| open62541 (OPC UA) | YELLOW | critical | debian | +| Eclipse Ditto | GREEN | optional | upstream | +| FIWARE Orion Context Broker | ORANGE | optional | none | +| EMQX | YELLOW | optional | upstream | + +**Note:** The Industrial IoT AI pipeline (open62541 -> Mosquitto -> Node-RED -> ONNX Runtime -> InfluxDB -> Prometheus + Grafana) has all components functional at YELLOW or better, with the inference backend (ONNX Runtime) also YELLOW. No critical-path ORANGE in this pipeline from the IIoT layer itself. + +--- + +## Layer 10 -- Domain-Specific (Automotive) + +### AUTOSAR Adaptive Platform -- GREY / unknown (critical) + +Proprietary automotive standard with no publicly accessible open-source implementation for RISC-V. Reference implementations (Apex.OS, VRTE, others) target ARM Cortex-A / x86_64 ECU hardware. No open-source RISC-V port of AUTOSAR Adaptive has been confirmed. The AUTOSAR organization has not published any RISC-V adaptation layer. Confidence: low. + +--- + +### Autoware (ROS 2-based AV stack) -- ORANGE (optional) + +[Autoware CI](https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/) targets amd64 only; Docker images on ghcr.io/autowarefoundation are amd64-only. Depends on ROS 2 (YELLOW) and CUDA-based GPU acceleration (excluded). Release provider: none. + +--- + +### Eclipse Zenoh -- BLUE (optional) + +Rust-based; Rust has first-class riscv64gc-unknown-linux-gnu support (Tier 2 with std). [ci.yml](https://github.com/eclipse-zenoh/zenoh/blob/main/.github/workflows/ci.yml) includes a riscv64 QEMU cross-compile and test job ("Build & Test (ubuntu-20.04, riscv64)" in the workflow matrix, using QEMU user-mode emulation). [GitHub Releases](https://github.com/eclipse-zenoh/zenoh/releases) include zenoh-*-riscv64-unknown-linux-gnu-*.zip assets. Release provider: upstream. + +--- + +### Layer 10 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| AUTOSAR Adaptive Platform | GREY/unknown | critical | none | +| Autoware | ORANGE | optional | none | +| Eclipse Zenoh | BLUE | optional | upstream | + +**Key finding:** The automotive layer has the most uncertain critical-path item in the entire report: AUTOSAR Adaptive Platform is grey/unknown (low confidence, proprietary). Eclipse Zenoh (BLUE) is the one bright spot -- a modern pub/sub middleware for automotive-grade distributed systems. Autoware (ORANGE) depends on ROS 2 (YELLOW community build) and CUDA/GPU (excluded), making riscv64 automotive AV stacks a multi-layer challenge. + +--- + +## Layer 11 -- Domain-Specific (Smart Home) + +### Home Assistant -- GREEN (optional) + +Pure Python (with optional C extensions for performance). The PyPI `homeassistant` package ships a py3-none-any wheel. Installs on riscv64 without modification. Release provider: upstream. + +--- + +### OpenThread -- ORANGE (optional) + +[build.yml](https://github.com/openthread/openthread/blob/main/.github/workflows/build.yml) targets ARM Cortex-M simulation via POSIX platform on Linux x86_64 host only. RISC-V MCU support exists only in the Espressif fork for ESP32-C3 and via Zephyr RTOS abstraction; mainline has no RISC-V target. No riscv64 Linux host library release. Release provider: none. + +--- + +### Matter / chip-tool (Project CHIP) -- ORANGE (optional) + +[build.yml](https://github.com/project-chip/connectedhomeip/blob/master/.github/workflows/build.yml) targets Linux x86_64, macOS, ARM cross-compile for embedded only. No riscv64 chip-tool binary release. RISC-V MCU support exists for ESP32-C3 (Espressif fork) and Zephyr/Bouffalo Lab boards, but mainline has no Linux riscv64 host path. Release provider: none. + +--- + +### Layer 11 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| Home Assistant | GREEN | optional | upstream | +| OpenThread | ORANGE | optional | none | +| Matter / chip-tool | ORANGE | optional | none | + +**Note:** Home Assistant (GREEN) is a standout for riscv64 smart home. The connectivity protocols (OpenThread, Matter) are ORANGE for mainline riscv64 Linux; RISC-V MCU support exists downstream (Espressif/Zephyr forks) but is not in mainline. + +--- + +## Layer 12 -- Federated Learning + +### Flower (flwr) -- GREEN (optional) + +Pure Python with no C extensions. PyPI `flwr` package ships py3-none-any wheel. Release provider: upstream. + +--- + +### TensorFlow Federated (TFF) -- ORANGE (optional) + +Ships C++ extension wheels. The PyPI `tensorflow-federated` package has no riscv64 wheel (only manylinux_x86_64). No upstream riscv64 CI. Release provider: none. + +--- + +### Layer 12 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| Flower (flwr) | GREEN | optional | upstream | +| TensorFlow Federated (TFF) | ORANGE | optional | none | + +**Note:** The federated learning edge round pipeline (Flower -> TFLite / ONNX Runtime -> fine-tune -> Mosquitto / gRPC -> KubeEdge) has Flower at GREEN, but both KubeEdge (ORANGE) and TFLite (ORANGE) remain blockers in the pipeline. The pipeline is functional only when ONNX Runtime is substituted for TFLite as the local inference backend. + +--- + +## Layer 13 -- Supporting Infrastructure + +### gRPC -- YELLOW (optional) + +Debian sid ships `libgrpc-dev` for riscv64 from unpatched source. [grpc_lab.yml](https://github.com/grpc/grpc/blob/master/.github/workflows/grpc_lab.yml) has no riscv64 job; upstream declined formal riscv64 support (issue #41591 closed 2026-07-15). RISE provides a riscv64 PyPI wheel for grpcio (v1.78.0), the primary Python use case. Release provider: debian (C library), RISE (Python wheel). + +--- + +### Protobuf -- YELLOW (optional) + +Debian sid ships `libprotobuf-dev` (v3.21.12) for riscv64 from unpatched upstream. [ci.yml](https://github.com/protocolbuffers/protobuf/blob/main/.github/workflows/ci.yml) has no riscv64 job. The Python protobuf wheel on PyPI ships platform-specific binary extensions for x86_64/aarch64 only; users fall back to the pure-Python protobuf package for riscv64. Release provider: debian. + +--- + +### HuggingFace Hub -- GREEN (optional) + +Pure Python. PyPI ships a py3-none-any wheel. Release provider: upstream. + +--- + +### NumPy -- YELLOW (optional) + +Upstream CI cross-compiles and tests riscv64 via QEMU. No upstream riscv64 PyPI wheel; RISE provides wheels at v2.5.2. [wheels.yml](https://github.com/numpy/numpy/blob/main/.github/workflows/wheels.yml) shows no riscv64 wheel build job. The RISC-V NPYV (SIMD) backend does not include RVV implementation (no rvv/ subdirectory in numpy/core/src/common/simd/). Release provider: RISE. + +--- + +### Layer 13 Summary + +| Project | Color | Criticality | Release Provider | +|---|---|---|---| +| gRPC | YELLOW | optional | debian / RISE | +| Protobuf | YELLOW | optional | debian | +| HuggingFace Hub | GREEN | optional | upstream | +| NumPy | YELLOW | optional | RISE | + +--- + +## Layer 14 -- Excluded (proprietary / vendor-only) + +The following projects are classified GREY / N/A. All are either proprietary / vendor-locked, architecture-specific to non-RISC-V silicon, or deliberately dropped from scope. They are listed here for completeness; no RISC-V investment decision applies. + +| Project | Reason | +|---|---| +| ARM Compute Library (ACL) | ARM-only (Cortex-A NEON/SVE/Mali GPU); no RISC-V port planned | +| AUTOSAR Adaptive Platform | Proprietary standard; reference implementations target ARM/x86 only | +| Cloud-only training infrastructure (TPU pods, GPU clusters, SageMaker training jobs) | Out of scope (cloud training); not applicable to edge inference | +| CUDA / cuDNN / cuBLAS / TensorRT GPU path (non-Jetson) | Proprietary NVIDIA GPU path; no RISC-V port | +| ROCm / HIP / MIOpen | AMD GPU path; no RISC-V port | +| Apple CoreML / ANE / Neural Engine SDK | Apple silicon only; not applicable | +| Qualcomm QNN / SNPE / AI Hub (on-device) | Qualcomm Hexagon DSP / Snapdragon only; no RISC-V port | +| MediaTek NeuroPilot / APU | MediaTek APU only; no RISC-V port | +| Samsung ONE / Exynos NPU SDK | Samsung Exynos only; no RISC-V port | +| ARM Ethos-U NPU + Vela compiler | ARM Ethos-U MCU NPU; proprietary ARM silicon | +| Google Edge TPU / Coral runtime | Google Edge TPU ASIC only; no RISC-V port | +| Hailo SDK / Hailo-8 runtime | Hailo-8 NPU ASIC only; no RISC-V port | +| Rockchip RKNN toolkit | Rockchip NPU only; riscv64 support unverified and proprietary | +| STM32Cube.AI / X-CUBE-AI | STM32 ARM Cortex-M only; no RISC-V port | +| NXP eIQ | NXP i.MX ARM only; no RISC-V port | +| Renesas DRP-AI | Renesas DRP-AI ASIC only; no RISC-V port | +| Ambarella CVflow SDK | Ambarella CVflow ASIC only; no RISC-V port | +| Syntiant NDP SDK | Syntiant NDP MCU NPU only; no RISC-V port | +| GreenWaves GAP SDK | GreenWaves GAP RISC-V MCU: specialized ultra-low-power, out of scope for RVA23U64 | +| Espressif ESP-NN | ESP32 ultra-low-power MCU; below RVA23U64 capability tier | +| CMSIS-NN | ARM Cortex-M only kernel library; no RISC-V port | +| Triton GPU compiler | GPU-only JIT compiler; not applicable | +| VxWorks / QNX (commercial RTOS) | Proprietary RTOS; no open-source RISC-V path | +| AUTOSAR Classic Platform | Automotive RTOS; no open-source RISC-V implementation | + +--- + +## Artifact 3 -- Scorecard Table + +### Full Node Scorecard + +| Layer | Project | Color | Criticality | Release Provider | Key Gap | +|---|---|---|---|---|---| +| 1 | llama.cpp | BLUE | critical | debian | Q3_K/Q5_K/Q6_K tiled GEMM/GEMV absent; no upstream release binary | +| 1 | ONNX Runtime (edge/mobile EP) | YELLOW | critical | debian | No upstream riscv64 CI; BF16 GEMM and FP16 RoPE stubs | +| 1 | TensorFlow Lite / LiteRT | ORANGE | critical | none | No CI, no distro pkg, no RVV kernels; blocked by XNNPACK FP16 failures and cpuinfo Zvfh detection | +| 1 | TensorFlow Lite Micro (TFLM) | ORANGE | optional | none | riscv32 MCU only; no riscv64 CI or kernels | +| 1 | ExecuTorch | YELLOW | critical | RISE | Build-only CI; not in full test gate | +| 1 | ncnn | BLUE | critical | none | Source-only; no prebuilt binary; partial operator RVV coverage | +| 1 | MNN (Alibaba) | ORANGE | optional | none | No CI, no release, no RVV kernels | +| 1 | PaddlePaddle Lite | ORANGE | optional | none | No CI, no release, no RVV kernels | +| 1 | MindSpore Lite (Huawei) | ORANGE | optional | none | No CI, no release, no RVV kernels | +| 1 | OpenVINO Runtime | YELLOW | critical | debian | No upstream CI; scalar-only on riscv64 | +| 1 | Apache TVM / microTVM | YELLOW | optional | none | Build-only CI; no test execution; no release binary | +| 1 | whisper.cpp | BLUE | optional | debian | Q3_K/Q5_K/Q6_K tiled paths absent (shared ggml gap) | +| 2 | ONNX (format + tooling) | YELLOW | critical | RISE | C extension wheel; no upstream riscv64 CI; RISE-only wheel | +| 2 | Intel Neural Compressor (INC) | GREEN | optional | upstream | None | +| 2 | NNCF (Intel) | GREEN | optional | upstream | None | +| 2 | HuggingFace Optimum | GREEN | optional | upstream | None | +| 3 | XNNPACK | YELLOW | critical | none | 100+ RVV FP16 CI failures (issue #9886 open); no release binary | +| 3 | OpenBLAS | BLUE | critical | debian | None (TRSM PR #5830 merged 2026-08-16) | +| 3 | SLEEF | BLUE | critical | debian | None | +| 3 | ARM Compute Library (ACL) | GREY/N/A | optional | none | ARM-only; not applicable | +| 3 | RUY | ORANGE | optional | none | No CI, no release, scalar-only | +| 3 | FlatBuffers | YELLOW | critical | debian | No upstream riscv64 CI | +| 4 | OpenCV | BLUE | critical | ubuntu | calib3d/features2d RVV coverage partial | +| 4 | GStreamer | YELLOW | critical | debian | No upstream riscv64 CI | +| 4 | MediaPipe | ORANGE | optional | none | No CI, no release, no RVV kernels | +| 4 | Mosquitto (Eclipse) | YELLOW | critical | debian | No upstream riscv64 CI | +| 4 | Node-RED | GREEN | optional | upstream | None | +| 4 | InfluxDB (edge / v1.x) | YELLOW | optional | debian | No upstream CI | +| 4 | SQLite | YELLOW | critical | debian | No upstream riscv64 CI | +| 4 | V4L2 (Video4Linux2) | YELLOW | critical | upstream | No dedicated V4L2 riscv64 test gate | +| 5 | k3s (Rancher) | ORANGE | critical | none | No riscv64 CI, no release; k0s is the alternative | +| 5 | k0s | BLUE | optional | upstream | None | +| 5 | KubeEdge | ORANGE | critical | none | No riscv64 CI, no release | +| 5 | containerd | YELLOW | critical | debian | No riscv64 integration test gate | +| 5 | crun | YELLOW | optional | debian | No upstream CI | +| 5 | WasmEdge | ORANGE | optional | none | Community builds only; WASI-NN missing on riscv64 | +| 5 | Mender.io | YELLOW | critical | debian | No upstream riscv64 CI | +| 5 | SWUpdate | YELLOW | critical | debian | No upstream riscv64 CI | +| 5 | RAUC | YELLOW | optional | debian | No upstream riscv64 CI | +| 5 | Eclipse hawkBit | GREEN | optional | upstream | None (JVM) | +| 5 | balenaCloud / balenaOS | ORANGE | optional | none | No RISC-V device support | +| 5 | AWS IoT Greengrass v2 | ORANGE | optional | none | No riscv64 support from AWS | +| 5 | Azure IoT Edge | ORANGE | optional | none | No riscv64 support from Microsoft | +| 5 | Red Hat Device Edge (MicroShift) | ORANGE | optional | none | x86_64/aarch64 only | +| 5 | Akri | ORANGE | optional | none | No riscv64 CI or release | +| 5 | OSTree / rpm-ostree | YELLOW | optional | debian | No upstream riscv64 CI | +| 5 | Uptane | GREEN | optional | upstream | None (pure Python) | +| 5 | Prometheus | YELLOW | critical | upstream | Cross-compile only; no test CI | +| 5 | Grafana | YELLOW | critical | upstream | Cross-compile only; no test CI | +| 5 | Fluent Bit | BLUE | critical | none | No prebuilt release binary | +| 5 | Telegraf | YELLOW | optional | upstream | Cross-compile only; no test CI | +| 5 | OpenTelemetry Collector (edge) | YELLOW | optional | upstream | Cross-compile only; no test CI | +| 5 | GDB / gdbserver | YELLOW | critical | debian | No upstream riscv64 host CI | +| 5 | OpenOCD | YELLOW | optional | debian | No upstream riscv64 CI | +| 5 | perf (Linux perf tools) | YELLOW | optional | upstream | No dedicated perf riscv64 test gate | +| 6 | Zephyr RTOS | GREEN | critical | upstream | None | +| 6 | FreeRTOS | ORANGE | critical | none | RISC-V portable layer not in CI matrix | +| 6 | RT-Thread | YELLOW | optional | upstream | Firmware build CI only; no riscv64 Linux test | +| 6 | Yocto Project | YELLOW | critical | upstream | Build CI only; no runtime test gate | +| 6 | Buildroot | YELLOW | critical | upstream | QEMU boot test; no full test suite | +| 6 | Ubuntu Core | ORANGE | optional | none | No riscv64 image from Canonical | +| 6 | Flatcar Container Linux | ORANGE | optional | none | amd64 and arm64 only | +| 6 | OpenWRT | YELLOW | optional | upstream | Experimental; no hardware test matrix | +| 6 | micro-ROS | ORANGE | optional | none | No upstream CI or release for RISC-V | +| 7 | OP-TEE | ORANGE | optional | none | ARM TrustZone only; no RISC-V OP-TEE port | +| 7 | AppArmor | YELLOW | critical | debian | No upstream riscv64 CI | +| 7 | WireGuard | YELLOW | critical | debian | Zvkned/Zvkg acceleration not wired up | +| 7 | SPIFFE / SPIRE | YELLOW | optional | upstream | Cross-compile only; no riscv64 test CI | +| 7 | Falco | ORANGE | optional | none | No riscv64 CI or release | +| 7 | OpenSSL | BLUE | critical | ubuntu | Zvkned AES path not mandatory in RVA23U64 | +| 7 | U-Boot (secure boot) | BLUE | critical | ubuntu | None | +| 8 | ROS 2 | YELLOW | critical | none | Community cross-build only; no official release | +| 8 | Nav2 | YELLOW | optional | none | Community cross-build only | +| 8 | MoveIt 2 | YELLOW | optional | none | Community cross-build only | +| 8 | FastDDS | YELLOW | critical | debian | No upstream riscv64 CI | +| 8 | CycloneDDS | YELLOW | optional | debian | No upstream riscv64 CI | +| 8 | Iceoryx | YELLOW | optional | debian | No upstream riscv64 CI | +| 9 | open62541 (OPC UA) | YELLOW | critical | debian | No upstream riscv64 CI | +| 9 | Eclipse Ditto | GREEN | optional | upstream | None (JVM) | +| 9 | FIWARE Orion Context Broker | ORANGE | optional | none | No riscv64 CI, no release | +| 9 | EMQX | YELLOW | optional | upstream | Cross-compile only; no riscv64 test CI | +| 10 | AUTOSAR Adaptive Platform | GREY/unknown | critical | none | Proprietary; no confirmed RISC-V path | +| 10 | Autoware | ORANGE | optional | none | amd64-only; GPU-dependent | +| 10 | Eclipse Zenoh | BLUE | optional | upstream | None | +| 11 | Home Assistant | GREEN | optional | upstream | None | +| 11 | OpenThread | ORANGE | optional | none | Mainline: ARM Cortex-M only; RISC-V MCU via downstream forks | +| 11 | Matter / chip-tool | ORANGE | optional | none | Mainline: no Linux riscv64 host path | +| 12 | Flower (flwr) | GREEN | optional | upstream | None | +| 12 | TensorFlow Federated (TFF) | ORANGE | optional | none | C++ extension wheel; no riscv64 wheel | +| 13 | gRPC | YELLOW | optional | debian/RISE | Upstream declined formal riscv64 support (issue #41591) | +| 13 | Protobuf | YELLOW | optional | debian | No upstream riscv64 CI; Python falls back to pure-Python | +| 13 | HuggingFace Hub | GREEN | optional | upstream | None | +| 13 | NumPy | YELLOW | optional | RISE | No upstream riscv64 wheel; no RVV NPYV backend | + +### Color Distribution (all classified nodes, excluding grey/N/A) + +| Color | Critical | Optional | Total | +|---|---|---|---| +| GREEN | 1 | 10 | 11 | +| BLUE | 8 | 5 | 13 | +| YELLOW | 26 | 21 | 47 | +| ORANGE | 5 | 22 | 27 | +| RED | 0 | 0 | 0 | + +**Total classified nodes:** 98 (plus 24 GREY/N/A in Layer 14, plus 1 GREY/unknown in Layer 10) + +**Critical-path nodes by color:** + +| Color | Critical count | Critical nodes | +|---|---|---| +| GREEN | 1 | Zephyr RTOS | +| BLUE | 8 | llama.cpp, ncnn, OpenBLAS, SLEEF, OpenCV, Fluent Bit, OpenSSL, U-Boot | +| YELLOW | 26 | ONNX Runtime, ExecuTorch, OpenVINO, ONNX format, XNNPACK, FlatBuffers, GStreamer, Mosquitto, SQLite, V4L2, containerd, Mender.io, SWUpdate, Prometheus, Grafana, GDB, ROS 2, FastDDS, open62541, AppArmor, WireGuard, k3s, KubeEdge, Yocto, Buildroot, TFLite/LiteRT | +| ORANGE | 5 | TensorFlow Lite / LiteRT, k3s, KubeEdge, FreeRTOS, AUTOSAR Adaptive Platform | + +--- + +## Artifact 4 -- Executive Summary and Key Findings + +### Overall Verdict + +The RISC-V (RVA23U64) Edge AI software stack is **partially viable** for edge server and capable SBC hardware tiers, and **fragmented** for MCU and constrained SBC tiers. The LLM inference pipeline is the most mature deployment path. The vision inference pipeline has a critical blocker. The orchestration layer has a primary alternative (k0s) but the dominant tool (k3s) is absent. + +--- + +### Finding 1: LLM Inference Pipeline is Ready for Production Validation + +The chain llama.cpp (BLUE) -> OpenBLAS (BLUE) -> SLEEF (BLUE) -> OpenSSL (BLUE, native FIPS CI added 2026-08-07) is the strongest end-to-end pipeline in this report. All four components have upstream CI executing on riscv64, and the performance-critical GEMM/math substrate is optimized with RVV 1.0 kernels. + +**Remaining gap:** The llama.cpp ggml repack.cpp GEMM/GEMV tiled paths for Q3_K, Q5_K, and Q6_K are absent. These formats fall back to vec_dot scalar-tiling for batched matrix operations, which degrades throughput for batched LLM inference on those quantization formats. + +**Recommendation:** Prioritize completing the Q3_K/Q5_K/Q6_K tiled GEMM/GEMV repack paths in ggml for both llama.cpp and whisper.cpp. + +--- + +### Finding 2: TFLite Vision Inference Pipeline Has a Multi-Layer Blocker + +The chain V4L2 (YELLOW) -> OpenCV (BLUE) -> TFLite/LiteRT (ORANGE) -> XNNPACK (YELLOW, 100+ FP16 failures) -> FlatBuffers (YELLOW) has a critical break at TFLite/LiteRT. This is the highest-volume edge vision deployment pattern globally (SBC-class inference cameras, smart home cameras, industrial vision sensors). + +The blocking chain requires three sequential fixes: +1. cpuinfo [#124](https://github.com/pytorch/cpuinfo/issues/124) -- Zvfh detection missing (blocks XNNPACK FP16 dispatch) +2. XNNPACK [#9886](https://github.com/google/XNNPACK/issues/9886) -- 100+ RVV FP16 CI failures (blocks XNNPACK riscv64 FP16 acceleration) +3. TFLite/LiteRT -- 0 RVV kernel files, no riscv64 CI, no distro package (requires Google engagement or fork-based acceleration) + +The GStreamer camera AI pipeline (YELLOW) has the same inference-layer break when TFLite is the chosen backend. Substituting ONNX Runtime (YELLOW, has partial RVV MLAS) avoids the hard break but still lacks a test CI gate. + +**Recommendation:** If TFLite is the strategic inference runtime target for SBC vision, RISE or the community must engage on cpuinfo Zvfh detection and XNNPACK FP16 fixes as the critical path. ncnn (BLUE) is a viable alternative for embedded vision inference on riscv64 today. + +--- + +### Finding 3: Orchestration Layer Requires a Strategic Decision + +k3s (ORANGE, critical) is the most widely deployed lightweight Kubernetes distribution for edge. It has no riscv64 release and no upstream CI. k0s (BLUE, optional) merged riscv64 nightly CI on RISE hardware in June 2026 and ships official riscv64 binaries. KubeEdge (ORANGE, critical) also has no riscv64 support. + +The Edge AI container workload deployment pipeline (KubeEdge -> containerd -> k3s -> Mender/SWUpdate -> WireGuard) has two ORANGE critical nodes at the orchestration layer. The pipeline is not deployable with upstream-supported components in this configuration. + +**Practical alternative available:** k0s (BLUE) + containerd (YELLOW) + Mender/SWUpdate (YELLOW) is a deployable stack. The federated learning edge round pipeline should be respecified with k0s replacing KubeEdge for riscv64 deployments. + +**Recommendation:** Engage k3s upstream (Go-based, cross-compilation is straightforward) on riscv64 CI and release support. Engage KubeEdge on the same. In the interim, specify k0s as the recommended Kubernetes distribution for riscv64 edge AI deployments. + +--- + +### Finding 4: Security Layer Has a TEE Gap + +The Secure edge device boot chain (U-Boot BLUE -> Trusted Firmware-A -> OP-TEE ORANGE -> AppArmor YELLOW -> WireGuard YELLOW) has OP-TEE as ORANGE: OP-TEE is ARM TrustZone-only, with no RISC-V port. RISC-V TEE alternatives (Keystone Enclave, OpenSBI + PMP-based isolation) exist but are not classified in this report as they are separate projects from OP-TEE. + +The boot security foundation (U-Boot BLUE + OpenSSL BLUE with native riscv64 FIPS CI) is solid. The runtime isolation layer is the gap. + +**Recommendation:** Assess Keystone Enclave readiness for RVA23U64 as a follow-on classification task. WireGuard's Zvkned/Zvkg cryptographic acceleration is not wired up for RISC-V in the upstream kernel; this is an opportunistic optimization but not a blocker. + +--- + +### Finding 5: Embedded OS Foundation is Adequate for Zephyr-Based MCU Pipelines + +Zephyr RTOS (GREEN) is the strongest riscv64 RTOS in this report -- RISC-V is a first-class upstream target with multiple board CI runs. The MCU TinyML pipeline (Zephyr -> TFLM -> microTVM) has a solid base layer. + +However, TFLM (ORANGE) -- the inference component in the MCU pipeline -- has only riscv32 MCU CI, not riscv64. For RVA23U64-targeted Linux deployments, TFLM is not the right runtime (it targets MCU-class bare-metal). The pipeline should be interpreted as Zephyr for MCU/constrained SBC and ONNX Runtime/ncnn/llama.cpp for capable SBC/edge server. + +FreeRTOS (ORANGE, critical) is a gap for the large install base of FreeRTOS-based RISC-V MCU devices. The portable layer exists in source but has no upstream CI. + +**Recommendation:** Engage FreeRTOS upstream on adding the RISC-V portable layer to the CI matrix. This is a low-cost upstream contribution with high install base impact. + +--- + +### Finding 6: Robotics Layer is Uniformly YELLOW, Primarily a Release Gap + +Every component in the Robotics perception pipeline (ROS 2 -> FastDDS -> OpenCV -> Nav2) is YELLOW. OpenCV (BLUE) is the exception. The gap for ROS 2, Nav2, MoveIt 2 is specifically that no official riscv64 package release exists from OSRF or Debian/Ubuntu ROS repos -- the software cross-compiles and community builds circulate, but there is no authoritative binary distribution. + +This is a supply chain / release engineering problem, not a fundamental software readiness problem. + +**Recommendation:** Engage OSRF on adding riscv64 to the ROS 2 release pipeline (binary packages). This is the highest-leverage single action for the robotics domain: it would lift ROS 2, Nav2, and MoveIt 2 from YELLOW to at minimum YELLOW with release provider, and potentially to BLUE if CI test gates are added. + +--- + +### Finding 7: Go-Based Infrastructure Stack is the Most Uniformly Available + +The observability, fleet management, and supporting infrastructure stack that is Go-based shows a consistent pattern: Prometheus (YELLOW, upstream release), Grafana (YELLOW, upstream release), Telegraf (YELLOW, upstream release), OpenTelemetry Collector (YELLOW, upstream release), SPIFFE/SPIRE (YELLOW, upstream release), k0s (BLUE, upstream release). Go's native riscv64gc cross-compilation support makes this layer the most uniformly available. + +The dominant pattern is build-only-CI (YELLOW): upstream cross-compiles and ships riscv64 binaries but does not run tests on riscv64. Promoting these to BLUE requires adding a QEMU or native riscv64 test execution step -- a modest engineering investment with high confidence impact. + +--- + +### Finding 8: Pure-Python and JVM Components are Universally Available + +All pure-Python (noarch) and JVM-based packages in this report are GREEN: Intel Neural Compressor, NNCF, HuggingFace Optimum, HuggingFace Hub, Node-RED, Eclipse hawkBit, Eclipse Ditto, Uptane, Home Assistant, Flower. These components require zero riscv64-specific investment. + +The practical constraint is their runtime dependencies: a pure-Python ML optimization tool (INC, NNCF) requires a working NumPy (YELLOW, RISE wheel) and a working inference runtime (ONNX Runtime YELLOW, TFLite ORANGE) to be end-to-end functional on riscv64. + +--- + +### Priority Investment Matrix (critical gaps only) + +| Priority | Component | Color | Action | Pipeline Impact | +|---|---|---|---|---| +| P1 | TFLite / LiteRT | ORANGE | Fix cpuinfo Zvfh + XNNPACK FP16 failures; add riscv64 CI | Unblocks TFLite vision pipeline and GStreamer camera AI pipeline | +| P1 | k3s | ORANGE | Add riscv64 CI + release binary | Unblocks Edge AI container workload deployment pipeline | +| P1 | KubeEdge | ORANGE | Add riscv64 CI + release binary, or deprecate from riscv64 stack spec | Unblocks container deployment and federated learning edge round | +| P2 | llama.cpp ggml repack | BLUE (gap) | Complete Q3_K/Q5_K/Q6_K tiled GEMM/GEMV | Improves batched LLM inference throughput on riscv64 | +| P2 | FreeRTOS | ORANGE | Add RISC-V portable layer to upstream CI matrix | Enables MCU RISC-V TinyML ecosystem | +| P2 | ROS 2 | YELLOW | Engage OSRF on riscv64 release pipeline | Unblocks robotics perception pipeline | +| P3 | OP-TEE / RISC-V TEE | ORANGE | Assess Keystone Enclave as classification candidate | Completes secure boot chain | +| P3 | ONNX Runtime | YELLOW | Add upstream riscv64 CI test gate | Upgrades critical inference runtime from yellow to blue | +| P3 | NumPy | YELLOW | Add upstream riscv64 wheel build + RISC-V NPYV backend | Enables Python ML toolchain on riscv64 without RISE dependency | +| P3 | WireGuard | YELLOW | Wire up Zvkned/Zvkg in kernel riscv64 path | Accelerates VPN cryptography on riscv64 edge devices | + +--- + +### Deployment Readiness by Hardware Tier (RVA23U64 baseline) + +| Hardware Tier | RAM | Best Inference Runtime | Readiness | Limiting Factor | +|---|---|---|---|---| +| MCU (<1 MB) | <1 MB | TFLM (rv32, ORANGE) / microTVM (YELLOW) | Low | No riscv64 MCU optimized inference; Zephyr (GREEN) is solid RTOS base | +| Constrained SBC (1-512 MB) | 1-512 MB | ncnn (BLUE) | Medium | No TFLite RVV; ncnn is viable alternative; k3s absent | +| Capable SBC / edge gateway (512 MB-8 GB) | 512 MB-8 GB | ONNX Runtime (YELLOW) / ncnn (BLUE) | Medium-High | XNNPACK FP16 open; ONNX Runtime scalar MLA gaps; orchestration needs k0s | +| Edge server (>8 GB) | >8 GB | llama.cpp (BLUE) / ONNX Runtime (YELLOW) | High | LLM pipeline solid; remaining ggml repack gaps for Q3_K/Q5_K/Q6_K | + +--- + +*Report generated by Ludovic Henry, 2026-08-29. All project classifications verified live against upstream CI, PyPI, Debian sid package archives, and GitHub Releases as of 2026-08-29. Confidence levels and as_of dates per node record above.* \ No newline at end of file diff --git a/stack-reports/edge-ai/edge-ai.scope.yml b/stack-reports/edge-ai/edge-ai.scope.yml new file mode 100644 index 000000000..c107e5e43 --- /dev/null +++ b/stack-reports/edge-ai/edge-ai.scope.yml @@ -0,0 +1,854 @@ +vertical: Edge AI +slug: edge-ai +author: Ludovic Henry +run_date: 2026-08-29 +audience: exec-product +target_profile: RVA23U64 +use: > + Deck for leadership on RISC-V investment across the full Edge AI software stack — + covering inference runtimes, model optimization, fleet management, data pipelines, + observability, security, and domain-specific verticals (automotive, robotics, + industrial IoT, smart home, healthcare/wearables, security/surveillance). + +assumptions: + - "Edge AI means deploying AI algorithms and models directly on local edge devices + (IoT sensors, smart cameras, industrial PLCs, autonomous vehicles/robots, + smartphones/laptops, wearables, smart home appliances, edge gateways, edge servers) + to enable real-time local data processing without constant cloud dependency." + - "Target profile RVA23U64: RVV 1.0, Zba/Zbb/Zbc, FP16 treated as mandatory baseline." + - "Hardware tiers covered: microcontroller (MCU, <1 MB RAM), constrained SBC (1–512 MB), + capable SBC / edge gateway (512 MB–8 GB), edge server (>8 GB)." + +exclusions: + - name: "Cloud-only training infrastructure (TPU pods, GPU clusters, SageMaker training jobs)" + reason: "Scope is edge inference and deployment, not cloud-based training." + - name: "CUDA / cuDNN / cuBLAS / TensorRT GPU path (non-Jetson)" + reason: "Proprietary NVIDIA GPU path for data-center GPUs; no RISC-V port." + - name: "ROCm / HIP / MIOpen" + reason: "AMD GPU path; no RISC-V port." + - name: "Apple CoreML / ANE / Neural Engine SDK" + reason: "Apple silicon only; not applicable to RISC-V." + - name: "Qualcomm QNN / SNPE / AI Hub (on-device)" + reason: "Qualcomm Hexagon DSP / Snapdragon only; no RISC-V port." + - name: "MediaTek NeuroPilot / APU" + reason: "MediaTek APU only; no RISC-V port." + - name: "Samsung ONE / Exynos NPU SDK" + reason: "Samsung Exynos only; no RISC-V port." + - name: "ARM Ethos-U NPU + Vela compiler" + reason: "ARM Ethos-U MCU NPU; proprietary ARM silicon, not RISC-V." + - name: "Google Edge TPU / Coral runtime" + reason: "Google Edge TPU ASIC only; no RISC-V port." + - name: "Hailo SDK / Hailo-8 runtime" + reason: "Hailo-8 NPU ASIC only; no RISC-V port." + - name: "Rockchip RKNN toolkit" + reason: "Rockchip NPU only; RISC-V RKNN support is unverified." + - name: "STM32Cube.AI / X-CUBE-AI" + reason: "STM32 ARM Cortex-M only; no RISC-V port." + - name: "NXP eIQ" + reason: "NXP i.MX ARM only; no RISC-V port." + - name: "Renesas DRP-AI" + reason: "Renesas DRP-AI ASIC only; no RISC-V port." + - name: "Ambarella CVflow SDK" + reason: "Ambarella CVflow ASIC only; no RISC-V port." + - name: "Syntiant NDP SDK" + reason: "Syntiant NDP MCU NPU only; no RISC-V port." + - name: "GreenWaves GAP SDK" + reason: "GreenWaves GAP RISC-V MCU is a specialized ultra-low-power target; out of scope for RVA23U64 server/gateway tier." + - name: "Espressif ESP-NN" + reason: "ESP32 Xtensa/RISC-V ultra-low-power MCU; below RVA23U64 capability tier." + - name: "CMSIS-NN" + reason: "ARM Cortex-M only kernel library; no RISC-V port (riscv-nn is an unofficial fork, out of scope)." + - name: "Triton GPU compiler" + reason: "GPU-only JIT compiler; not applicable." + - name: "VxWorks / QNX (commercial RTOS)" + reason: "Proprietary RTOS; no open-source RISC-V path." + - name: "AUTOSAR Classic Platform" + reason: "Automotive RTOS with no open-source RISC-V implementation." + +out_of_scope: + - name: "On-device model training (full backprop, not fine-tuning)" + reason: "Scope is inference and fine-tuning at edge; full training workloads are cloud-side." + - name: "Federated learning server-side aggregation" + reason: "Aggregation runs in cloud/datacenter; only the on-device client (Flower client, TFF client) is in scope." + - name: "NVIDIA DeepStream (GPU-only pipeline)" + reason: "Requires NVIDIA GPU; Jetson GPU path is in scope but DeepStream itself requires CUDA." + - name: "Model visualization tools (Netron, etc.)" + reason: "Developer tooling only; not a runtime dependency." + - name: "Cloud IoT brokers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT)" + reason: "Cloud-side infrastructure; only edge-local components are in scope." + +layers: + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 1: ML INFERENCE RUNTIMES (edge-optimized) + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "ML Inference Runtimes" + nodes: + - name: llama.cpp + repo: https://github.com/ggerganov/llama.cpp + home: https://github.com/ggerganov/llama.cpp + slug: llama-cpp + criticality: critical + features_in_scope: "GGUF-format LLM inference on CPU; RVV-accelerated kernels; 1.5–8-bit quantization; CPU+GPU hybrid offload" + notes: "Primary LLM inference runtime for edge servers and capable SBCs. Active RVV optimization." + + - name: ONNX Runtime (edge / mobile EP) + repo: https://github.com/microsoft/onnxruntime + home: https://onnxruntime.ai/ + slug: onnx + criticality: critical + features_in_scope: "Cross-platform inference runtime; CPU execution provider; QDQ INT8 quantization; Android/iOS/Raspberry Pi targets" + notes: "Debian sid ships riscv64 binary. No upstream riscv64 CI." + + - name: TensorFlow Lite / LiteRT + repo: https://github.com/google-ai-edge/LiteRT + home: https://ai.google.dev/edge/litert + criticality: critical + features_in_scope: "Mobile and embedded inference; INT8/FP16 quantization (up to 75% size reduction); XNNPACK delegate; Raspberry Pi and Android targets" + notes: "Google rebranded TFLite as LiteRT in 2024. Primary runtime for mobile and constrained SBC tier." + + - name: TensorFlow Lite Micro (TFLM) + repo: https://github.com/tensorflow/tflite-micro + home: https://ai.google.dev/edge/litert/microcontrollers/overview + criticality: optional + features_in_scope: "Bare-metal MCU inference; INT8; CMSIS-NN backend on ARM; portable C++ runtime" + notes: "MCU tier only. RISC-V backend via microTVM path; native TFLM RISC-V support is minimal." + + - name: ExecuTorch + repo: https://github.com/pytorch/executorch + home: https://pytorch.org/executorch/ + slug: executorch + criticality: critical + features_in_scope: "PyTorch on-device inference; .pte model format; XNNPACK CPU backend; MCU through mobile through edge server" + notes: "Phase-1 riscv64 QEMU CI with test pass. No upstream release binary. RISE fork active." + + - name: ncnn + repo: https://github.com/Tencent/ncnn + home: https://github.com/Tencent/ncnn + criticality: critical + features_in_scope: "High-performance mobile/SBC inference; no third-party runtime dependencies; Vulkan GPU (optional); Android/iOS/Linux" + notes: "Production use in Tencent products (WeChat, QQ, Pitu). No riscv64-specific optimizations verified." + + - name: MNN (Alibaba) + repo: https://github.com/alibaba/MNN + home: https://www.mnn.zone/ + criticality: optional + features_in_scope: "Mobile/edge inference and training; supports Android, iOS, Linux; INT8/FP16; backend plugins" + notes: "Used in Taobao, DingTalk, and other Alibaba apps. Less commonly deployed outside Alibaba ecosystem." + + - name: PaddlePaddle Lite + repo: https://github.com/PaddlePaddle/Paddle-Lite + home: https://www.paddlepaddle.org.cn/lite + criticality: optional + features_in_scope: "Inference on mobile/IoT/embedded; Android, iOS, ARM Linux, x86 Linux; INT8 quantization" + notes: "Dominant in China for IoT/edge use cases. Limited Western adoption." + + - name: MindSpore Lite (Huawei) + repo: https://github.com/mindspore-ai/mindspore + home: https://www.mindspore.cn/lite/en + criticality: optional + features_in_scope: "On-device inference for Android, iOS, Linux, Cortex-M/A; INT8/FP16" + notes: "Huawei ecosystem. Used with HiSilicon Ascend NPU and Kirin NPU. Limited non-Huawei adoption." + + - name: OpenVINO Runtime + repo: https://github.com/openvinotoolkit/openvino + home: https://docs.openvino.ai/ + criticality: critical + features_in_scope: "Intel-optimized inference runtime; CPU/GPU/VPU execution providers; INT8; OpenVINO IR format" + notes: "Primary runtime for Intel-based edge devices (NUC, UP Board, industrial PCs). Debian sid ships riscv64 binary." + + - name: Apache TVM / microTVM + repo: https://github.com/apache/tvm + home: https://tvm.apache.org/ + criticality: optional + features_in_scope: "ML compiler and runtime; microTVM for bare-metal MCU (STM32, ESP32, RISC-V boards); auto-tuning" + notes: "microTVM explicitly targets RISC-V MCUs (e.g., SiFive boards). Compiler toolchain for edge targets." + + - name: whisper.cpp + repo: https://github.com/ggerganov/whisper.cpp + home: https://github.com/ggerganov/whisper.cpp + criticality: optional + features_in_scope: "On-device speech recognition (OpenAI Whisper); CPU inference; RVV-capable; edge server / capable SBC" + notes: "Shares ggml backend with llama.cpp. Key for voice-driven edge AI (smart home, robotics)." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 2: MODEL OPTIMIZATION & CONVERSION + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Model Optimization & Conversion" + nodes: + - name: ONNX (format + tooling) + repo: https://github.com/onnx/onnx + home: https://onnx.org/ + slug: onnx + criticality: critical + features_in_scope: "Cross-framework model interchange format; onnx-simplifier; onnx-mltools quantization; conversion hub" + notes: "Lingua franca for model portability. Arch-independent Python tooling." + + - name: Intel Neural Compressor (INC) + repo: https://github.com/intel/neural-compressor + home: https://intel.github.io/neural-compressor/ + criticality: optional + features_in_scope: "PTQ/QAT quantization; pruning; knowledge distillation; mixed-precision; targets ONNX Runtime, TFLite, PyTorch" + notes: "Open-source Intel tool. Generates INT8 models deployable via ONNX Runtime on edge." + + - name: NNCF (Neural Network Compression Framework, Intel) + repo: https://github.com/openvinotoolkit/nncf + home: https://github.com/openvinotoolkit/nncf + criticality: optional + features_in_scope: "QAT, structured/unstructured pruning, filter pruning; integrates with PyTorch and OpenVINO" + notes: "Companion to OpenVINO for compression-before-deployment workflow." + + - name: HuggingFace Optimum + repo: https://github.com/huggingface/optimum + home: https://huggingface.co/docs/optimum + criticality: optional + features_in_scope: "Quantization and optimization toolkit; ONNX Runtime backend; Intel, Habana, Furiosa backends; edge export" + notes: "Pure Python. Used upstream of ONNX Runtime edge deployment." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 3: KERNEL LIBRARIES & COMPUTE PRIMITIVES + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Kernel Libraries & Compute Primitives" + nodes: + - name: XNNPACK + repo: https://github.com/google/XNNPACK + home: https://github.com/google/XNNPACK + slug: xnnpack + criticality: critical + features_in_scope: "Acceleration backend for TFLite, ExecuTorch, PyTorch Mobile, ONNX Runtime Mobile, MediaPipe; RVV kernels" + notes: "Not a standalone inference engine. Backend for 7+ frameworks. Active RISC-V RVV support." + + - name: OpenBLAS + repo: https://github.com/OpenMathLib/OpenBLAS + home: https://www.openblas.net/ + slug: openblas + criticality: critical + features_in_scope: "BLAS/LAPACK for edge servers and capable SBCs; RVV 1.0 GEMM acceleration" + notes: "RVV 1.0 GEMM fully covered. TRSM partially in v0.3.34. Used by llama.cpp, ONNX Runtime, scikit-learn." + + - name: SLEEF + repo: https://github.com/shibatch/sleef + home: https://sleef.org/ + slug: sleef + criticality: critical + features_in_scope: "SIMD transcendental math (exp, log, sin, cos); RVV v1.0 backend; used by edge inference operators" + notes: "Full RVV v1.0 backend covering SP/DP. Jenkins CI on native riscv64 hardware." + + - name: ARM Compute Library (ACL) [ARM Only] + repo: https://github.com/ARM-software/ComputeLibrary + home: https://arm-software.github.io/ComputeLibrary/ + criticality: optional + features_in_scope: "Optimized kernels for ARM CPU (NEON/SVE) and GPU (OpenCL); used by Arm NN and ONNX Runtime ARM EP" + notes: "ARM-only; no RISC-V port. Listed for completeness as major edge kernel library." + + - name: RUY (Google matrix multiply) + repo: https://github.com/google/ruy + home: https://github.com/google/ruy + criticality: optional + features_in_scope: "Optimized INT8 matrix multiply for TFLite on ARM; fallback generic path for other arch" + notes: "ARM-optimized, generic scalar fallback for RISC-V. Used inside TFLite." + + - name: FlatBuffers + repo: https://github.com/google/flatbuffers + home: https://google.github.io/flatbuffers/ + slug: flatbuffers + criticality: critical + features_in_scope: "Zero-copy serialization; TFLite model format; ExecuTorch .pte format; edge model loading" + notes: "Debian sid ships riscv64. Required by TFLite, ExecuTorch, and ONNX Runtime model loading." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 4: DATA PIPELINE & LOCAL PROCESSING + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Data Pipeline & Local Processing" + nodes: + - name: OpenCV + repo: https://github.com/opencv/opencv + home: https://opencv.org/ + criticality: critical + features_in_scope: "Computer vision preprocessing; camera capture; image/video decode; inference pre/post-processing; DNN module" + notes: "Debian riscv64 package ships (libopencv-*). Core dependency for vision-based edge AI across all verticals." + + - name: GStreamer + repo: https://gitlab.freedesktop.org/gstreamer/gstreamer + home: https://gstreamer.freedesktop.org/ + slug: gstreamer + criticality: critical + features_in_scope: "Media pipeline framework; camera/video ingestion; hardware-accelerated decode; tensor_filter for ML inference in pipeline" + notes: "Debian riscv64 ships gstreamer1.0-*. Used in smart camera, surveillance, and industrial vision pipelines." + + - name: MediaPipe + repo: https://github.com/google/mediapipe + home: https://mediapipe.dev/ + criticality: optional + features_in_scope: "ML pipeline framework for vision/audio; face detection, pose estimation, hand tracking; Android/iOS/Linux" + notes: "Google. XNNPACK-accelerated. Used in healthcare wearables, retail, smart home. ARM-primary; riscv64 build untested." + + - name: Mosquitto (Eclipse) + repo: https://github.com/eclipse/mosquitto + home: https://mosquitto.org/ + criticality: critical + features_in_scope: "MQTT v5.0/3.1.1 broker and client library; IoT message bus for sensor data; lightweight edge broker" + notes: "Debian riscv64 ships libmosquitto1, libmosquittopp1, mosquitto. Core IoT data bus." + + - name: Node-RED + repo: https://github.com/node-red/node-red + home: https://nodered.org/ + criticality: optional + features_in_scope: "Flow-based IoT programming; sensor data routing; ML inference integration via custom nodes; industrial and smart home" + notes: "Node.js-based. Arch-independent. Widely used in industrial IoT for data pipeline orchestration." + + - name: InfluxDB (edge / v1.x) + repo: https://github.com/influxdata/influxdb + home: https://www.influxdata.com/ + criticality: optional + features_in_scope: "Time-series database for edge sensor data; metrics storage for ML inference pipelines; Telegraf integration" + notes: "Debian riscv64 ships influxdb 1.6.7. Primary edge metrics store alongside Prometheus." + + - name: SQLite + repo: https://www.sqlite.org/ + home: https://www.sqlite.org/ + criticality: critical + features_in_scope: "Embedded relational database; model metadata storage; inference result persistence; offline edge operation" + notes: "Arch-independent C library. Near-universal on embedded Linux and mobile. No RISC-V-specific gaps." + + - name: V4L2 (Video4Linux2) + repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + home: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/v4l2.html + criticality: critical + features_in_scope: "Linux kernel camera capture API; used by OpenCV, GStreamer, and all camera-based edge AI applications" + notes: "Part of Linux kernel. RISC-V supported. Required for any camera-input edge AI pipeline on Linux." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 5: FLEET MANAGEMENT, ORCHESTRATION, OBSERVABILITY & DEBUGGING + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Fleet Management, Orchestration, Observability, Debugging" + nodes: + - name: k3s (Rancher) + repo: https://github.com/k3s-io/k3s + home: https://k3s.io/ + criticality: critical + features_in_scope: "Lightweight Kubernetes for edge; single binary; ARM/x86/RISC-V; containerd runtime; manages AI workload containers" + notes: "Most widely deployed edge Kubernetes distribution. Primary orchestrator for edge AI container workloads." + + - name: k0s + repo: https://github.com/k0sproject/k0s + home: https://k0sproject.io/ + criticality: optional + features_in_scope: "Zero-friction Kubernetes distribution; single binary; no external host OS dependencies; edge and IoT" + notes: "Growing adoption as k3s alternative. No dedicated RISC-V CI verified." + + - name: KubeEdge + repo: https://github.com/kubeedge/kubeedge + home: https://kubeedge.io/ + criticality: critical + features_in_scope: "Kubernetes extension for edge; EdgeCore agent on device; cloud/edge sync; offline-capable; AI model deployment" + notes: "CNCF graduated project. Designed for cloud↔edge AI workload management. Strong IoT/edge adoption." + + - name: containerd + repo: https://github.com/containerd/containerd + home: https://containerd.io/ + slug: containerd + criticality: critical + features_in_scope: "Container runtime; k3s/k0s/KubeEdge default runtime; OCI image pull and run on edge devices" + notes: "Debian riscv64 ships containerd. De facto container runtime for all edge Kubernetes distributions." + + - name: crun + repo: https://github.com/containers/crun + home: https://github.com/containers/crun + criticality: optional + features_in_scope: "Lightweight OCI container runtime in C; low-overhead alternative to runc for constrained edge devices" + notes: "Debian riscv64 ships crun. Better suited than runc for memory-constrained edge devices." + + - name: WasmEdge + repo: https://github.com/WasmEdge/WasmEdge + home: https://wasmedge.org/ + criticality: optional + features_in_scope: "WebAssembly runtime for edge AI; WASI-NN for ML inference (TFLite, ONNX, PyTorch backends); lightweight sandbox" + notes: "Emerging for edge AI: WASM sandboxing + ML inference via WASI-NN standard. RISC-V support in progress." + + - name: Mender.io + repo: https://github.com/mendersoftware/mender + home: https://mender.io/ + criticality: critical + features_in_scope: "OTA firmware and software updates for embedded Linux; dual-partition A/B; rollback; delta updates; model OTA" + notes: "Debian riscv64 ships mender-client, mender-artifact, mender-connect. Leading open-source OTA for embedded Linux." + + - name: SWUpdate + repo: https://github.com/sbabic/swupdate + home: https://sbabic.github.io/swupdate/ + criticality: critical + features_in_scope: "Embedded Linux software update framework; single/dual-copy; hawkBit integration; Yocto/Buildroot native" + notes: "Debian riscv64 ships swupdate and libswupdate. Widely used in industrial and automotive embedded Linux." + + - name: RAUC (Robust Auto-Update Controller) + repo: https://github.com/rauc/rauc + home: https://rauc.readthedocs.io/ + criticality: optional + features_in_scope: "Embedded Linux OTA update framework; A/B redundancy; bundle signing; hawkBit and custom server backends" + notes: "Debian riscv64 ships rauc. Common in automotive and industrial embedded Linux." + + - name: Eclipse hawkBit + repo: https://github.com/eclipse/hawkbit + home: https://eclipse.dev/hawkbit/ + criticality: optional + features_in_scope: "Backend update server for IoT device fleets; integrates with SWUpdate, RAUC, Mender; manages AI model rollouts" + notes: "Java-based server. Arch-independent. Pairs with SWUpdate/RAUC for device-side OTA." + + - name: balenaCloud / balenaOS + repo: https://github.com/balena-os/balena-engine + home: https://www.balena.io/ + criticality: optional + features_in_scope: "Container-based edge fleet management; Docker-compatible; OTA containers including ML models; SBC-focused" + notes: "Commercial + open-source. balenaOS is a minimal Linux for running containers on SBCs. Popular in prototyping and SME IoT." + + - name: AWS IoT Greengrass v2 + repo: https://github.com/aws-greengrass/aws-greengrass-nucleus + home: https://aws.amazon.com/greengrass/ + criticality: optional + features_in_scope: "AWS-managed edge runtime; component-based deployment; ML inference components (TFLite, ONNX RT, DLR); Lambda at edge" + notes: "Commercial AWS service with open-source nucleus. Dominant in AWS IoT customers deploying ML to edge." + + - name: Azure IoT Edge + repo: https://github.com/Azure/iotedge + home: https://azure.microsoft.com/en-us/products/iot-edge + criticality: optional + features_in_scope: "Microsoft-managed edge runtime; module-based Docker container deployment; ONNX Runtime module; OPC UA integration" + notes: "Commercial Microsoft service. Widely adopted in manufacturing and industrial IoT with Azure customers." + + - name: Red Hat Device Edge (MicroShift) + repo: https://github.com/openshift/microshift + home: https://www.redhat.com/en/topics/edge-computing/microshift + criticality: optional + features_in_scope: "Minimal OpenShift/Kubernetes for edge; rpm-ostree OS updates; enterprise edge AI workload hosting" + notes: "Red Hat enterprise offering. RISC-V port not established. Growing in industrial and telco edge." + + - name: Akri (Kubernetes device plugin) + repo: https://github.com/project-akri/akri + home: https://docs.akri.sh/ + criticality: optional + features_in_scope: "Kubernetes device discovery and exposure (cameras, sensors, USB devices) to AI workloads; ONVIF, OPC UA, udev" + notes: "Bridges physical edge hardware into Kubernetes pods. Used with KubeEdge/k3s for camera AI pipelines." + + - name: OSTree / rpm-ostree + repo: https://github.com/ostreedev/ostree + home: https://ostreedev.github.io/ostree/ + criticality: optional + features_in_scope: "Atomic OS image updates for embedded Linux; image-based immutable OS for edge; used by Fedora IoT, RHEL for Edge" + notes: "Arch-independent. Core of Fedora IoT and Red Hat Device Edge OS update mechanism." + + - name: Uptane (automotive OTA standard) + repo: https://github.com/uptane/uptane-standard + home: https://uptane.github.io/ + criticality: optional + features_in_scope: "Secure OTA update standard for automotive ECUs; attack-resilient multi-repository design; TUF-based" + notes: "Industry standard for automotive OTA. Used by Linux Foundation Automotive Grade Linux (AGL) deployments." + + - name: Prometheus + repo: https://github.com/prometheus/prometheus + home: https://prometheus.io/ + slug: prometheus + criticality: critical + features_in_scope: "Metrics collection and alerting; node_exporter for device metrics; edge-deployed scrape targets; inference latency tracking" + notes: "Debian riscv64 ships prometheus. Core observability for edge Kubernetes (k3s/KubeEdge) deployments." + + - name: Grafana + repo: https://github.com/grafana/grafana + home: https://grafana.com/ + criticality: critical + features_in_scope: "Metrics visualization; edge dashboards for ML inference latency, throughput, device health; Prometheus data source" + notes: "Arch-independent Go binary. Widely deployed at edge gateway / edge server tier for ops dashboards." + + - name: Fluent Bit + repo: https://github.com/fluent/fluent-bit + home: https://fluentbit.io/ + criticality: critical + features_in_scope: "Lightweight log and metrics processor for edge; forward to cloud or local store; lower footprint than Fluentd" + notes: "Preferred over Fluentd for constrained edge devices. C-based, small binary. Arch-generic." + + - name: Telegraf + repo: https://github.com/influxdata/telegraf + home: https://www.influxdata.com/time-series-platform/telegraf/ + criticality: optional + features_in_scope: "Plugin-based metrics collection agent; MQTT input; IoT sensor metrics; feeds InfluxDB and Prometheus" + notes: "Go binary. Arch-independent. Pairs with InfluxDB for edge IoT time-series pipelines." + + - name: OpenTelemetry Collector (edge) + repo: https://github.com/open-telemetry/opentelemetry-collector + home: https://opentelemetry.io/ + criticality: optional + features_in_scope: "Vendor-neutral telemetry pipeline at edge; collects traces/metrics/logs from ML inference services; forwards to cloud" + notes: "Go binary. Arch-independent. CNCF. Used for distributed tracing of edge AI inference pipelines." + + - name: GDB / gdbserver + repo: https://sourceware.org/git/binutils-gdb.git + home: https://www.gnu.org/software/gdb/ + slug: gdb + criticality: critical + features_in_scope: "Remote debugging of edge AI applications; gdbserver for cross-debugging; RISC-V target support" + notes: "Debian riscv64 ships gdb, gdb-multiarch, gdbserver. Essential for debugging on-device inference issues." + + - name: OpenOCD + repo: https://github.com/openocd-org/openocd + home: https://openocd.org/ + criticality: optional + features_in_scope: "On-chip debugger; JTAG/SWD debugging of MCU-tier RISC-V devices running TFLite Micro or microTVM" + notes: "Critical for bare-metal MCU debugging. RISC-V JTAG support via SiFive and other implementations." + + - name: perf (Linux perf tools) + repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + home: https://perf.wiki.kernel.org/ + criticality: optional + features_in_scope: "CPU performance profiling of edge AI inference; hardware PMU counter access; riscv64 PMU support" + notes: "Kernel tool. RISC-V PMU support present. Used for inference throughput optimization on edge Linux." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 6: EMBEDDED OS & RTOS + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Embedded OS & RTOS" + nodes: + - name: Zephyr RTOS + repo: https://github.com/zephyrproject-rtos/zephyr + home: https://zephyrproject.org/ + criticality: critical + features_in_scope: "RTOS for MCU-tier edge AI; TFLite Micro integration; networking (BLE, Wi-Fi, LoRa); sensor drivers; RISC-V support" + notes: "RISC-V is a first-class target in Zephyr (SiFive, ESP32-C3, GD32VF103, etc.). TFLite Micro runs on Zephyr." + + - name: FreeRTOS + repo: https://github.com/FreeRTOS/FreeRTOS + home: https://freertos.org/ + criticality: critical + features_in_scope: "MCU RTOS for embedded inference; TFLite Micro integration; widely used in industrial IoT and healthcare devices" + notes: "RISC-V port maintained. Amazon FreeRTOS variant widely used in IoT devices." + + - name: RT-Thread + repo: https://github.com/RT-Thread/rt-thread + home: https://www.rt-thread.io/ + criticality: optional + features_in_scope: "MCU/SBC RTOS; AI packages (Tensorflow, MNN, ONNX RT bindings); dominant in Chinese IoT market" + notes: "Strong RISC-V support (Kendryte K210, GD32VF103, etc.). Widely adopted in Chinese industrial IoT." + + - name: Yocto Project + repo: https://git.yoctoproject.org/yocto-docs + home: https://www.yoctoproject.org/ + criticality: critical + features_in_scope: "Embedded Linux build system; meta-ai layer for TFLite/ONNX Runtime; RISC-V BSP layers; device firmware" + notes: "Primary build system for custom embedded Linux on edge devices. RISC-V tier supported via meta-riscv." + + - name: Buildroot + repo: https://gitlab.com/buildroot.org/buildroot + home: https://buildroot.org/ + criticality: critical + features_in_scope: "Lightweight embedded Linux build system; TFLite, ONNX Runtime, mosquitto, OpenCV packages; simpler than Yocto" + notes: "Widely used for constrained SBC and edge gateway firmware. RISC-V supported." + + - name: Ubuntu Core + repo: https://github.com/snapcore/snapd + home: https://ubuntu.com/core + criticality: optional + features_in_scope: "Snap-based immutable embedded Linux; OTA updates via snapd; containerized app deployment; edge gateway / server" + notes: "Used in industrial and retail edge deployments. RISC-V support in progress." + + - name: Flatcar Container Linux + repo: https://github.com/flatcar/scripts + home: https://www.flatcar.org/ + criticality: optional + features_in_scope: "Immutable container-optimized Linux for edge servers; auto-update via Omaha/Nebraska; k3s/containerd native" + notes: "No RISC-V port currently. Listed as increasingly adopted edge server OS." + + - name: OpenWRT + repo: https://github.com/openwrt/openwrt + home: https://openwrt.org/ + criticality: optional + features_in_scope: "Linux OS for edge gateways and routers; MQTT, Node-RED packages; lightweight ML inference (ONNX RT) possible" + notes: "Dominant OS for edge gateways and home routers. Limited RISC-V support." + + - name: micro-ROS (RTOS layer for ROS 2) + repo: https://github.com/micro-ROS/micro_ros_arduino + home: https://micro.ros.org/ + criticality: optional + features_in_scope: "ROS 2 on MCU-class hardware (FreeRTOS, Zephyr, NuttX); DDS-XRCE transport; sensor/actuator integration" + notes: "Bridges MCU-tier devices into ROS 2 ecosystem. Vulcanexus/eProsima. RISC-V board support via Zephyr." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 7: SECURITY + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Security" + nodes: + - name: OP-TEE (Open Portable Trusted Execution Environment) + repo: https://github.com/OP-TEE/optee_os + home: https://optee.readthedocs.io/ + criticality: optional + features_in_scope: "TEE OS running in ARM TrustZone (or RISC-V equivalent); secure model IP protection; secure key storage" + notes: "ARM TrustZone primary. RISC-V TEE (Keystone, RISC-V PMP) is an alternative path. Used for AI model encryption." + + - name: AppArmor + repo: https://gitlab.com/apparmor/apparmor + home: https://apparmor.net/ + criticality: critical + features_in_scope: "Mandatory access control; container security profiles; restricts edge AI inference container capabilities" + notes: "Debian riscv64 ships apparmor. Default LSM in Ubuntu. Used by containerd/k3s for workload isolation." + + - name: WireGuard + repo: https://git.zx2c4.com/wireguard-linux + home: https://www.wireguard.com/ + criticality: critical + features_in_scope: "VPN tunnel for edge device secure connectivity; zero-trust network overlay; low-overhead for constrained devices" + notes: "Debian riscv64 ships wireguard-tools, wireguard-go. In-kernel on Linux 5.6+. Core for edge-to-cloud secure tunneling." + + - name: SPIFFE / SPIRE + repo: https://github.com/spiffe/spire + home: https://spiffe.io/ + criticality: optional + features_in_scope: "Workload identity for edge containers; X.509 SVIDs; mTLS for ML inference service-to-service auth" + notes: "CNCF graduated. Used in KubeEdge and k3s deployments for zero-trust edge AI workload identity." + + - name: Falco + repo: https://github.com/falcosecurity/falco + home: https://falco.org/ + criticality: optional + features_in_scope: "Runtime security monitoring; eBPF-based syscall anomaly detection; container security at edge; threat detection" + notes: "CNCF. eBPF probe requires Linux 5.8+. Used for detecting adversarial attacks on edge AI inference containers." + + - name: OpenSSL + repo: https://github.com/openssl/openssl + home: https://www.openssl.org/ + slug: openssl + criticality: critical + features_in_scope: "TLS/crypto for all edge AI network communications; model download integrity; MQTT TLS; gRPC TLS" + notes: "Debian riscv64 ships. Required by every networked edge AI component. AES constant-time gap (PRs open)." + + - name: U-Boot (secure boot) + repo: https://source.denx.de/u-boot/u-boot + home: https://www.denx.de/wiki/U-Boot + criticality: critical + features_in_scope: "Bootloader for embedded Linux; RISC-V U-Boot; verified boot (FIT image signing); chain of trust for edge devices" + notes: "RISC-V U-Boot is active and well-supported. Foundation of secure boot on embedded Linux edge devices." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 9.a: DOMAIN-SPECIFIC — ROBOTICS + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Domain-Specific" + product: "Robotics" + nodes: + - name: ROS 2 (Robot Operating System 2) + repo: https://github.com/ros2/ros2 + home: https://docs.ros.org/ + criticality: critical + features_in_scope: "Robotics middleware; DDS-based pub/sub; sensor fusion; navigation; AI model integration via ROS 2 nodes" + notes: "Standard robotics OS. RISC-V not an official tier but community builds exist. Runs on edge server / capable SBC." + + - name: Nav2 (Navigation 2) + repo: https://github.com/ros-navigation/navigation2 + home: https://nav2.ros.org/ + criticality: optional + features_in_scope: "ROS 2 autonomous navigation stack; path planning; obstacle avoidance; integrates with AI perception pipelines" + notes: "Primary ROS 2 navigation framework. Deployed on mobile robots and AMRs. Requires ROS 2." + + - name: MoveIt 2 + repo: https://github.com/moveit/moveit2 + home: https://moveit.picknik.ai/ + criticality: optional + features_in_scope: "ROS 2 motion planning for robot arms; ML-based grasp planning integration; industrial robot use" + notes: "Standard robotic arm motion planning. Deployed in manufacturing and warehouse automation." + + - name: FastDDS (eProsima) + repo: https://github.com/eProsima/Fast-DDS + home: https://fast-dds.docs.eprosima.com/ + criticality: critical + features_in_scope: "DDS middleware for ROS 2; real-time pub/sub; used in robotics, automotive, and industrial edge AI" + notes: "Debian riscv64 ships libfastdds. Default DDS implementation for ROS 2 Humble/Iron/Jazzy." + + - name: CycloneDDS (Eclipse) + repo: https://github.com/eclipse-cyclonedds/cyclonedds + home: https://cyclonedds.io/ + criticality: optional + features_in_scope: "Alternative DDS middleware for ROS 2; lightweight; used in constrained robot platforms" + notes: "Debian riscv64 ships cyclonedds-dev. ROS 2 alternative DDS implementation." + + - name: Iceoryx (Eclipse) + repo: https://github.com/eclipse-iceoryx/iceoryx + home: https://iceoryx.io/ + criticality: optional + features_in_scope: "Zero-copy inter-process communication middleware; automotive/robotics edge; DDS-layer replacement for local comms" + notes: "Debian riscv64 ships iceoryx. True zero-copy IPC. Used in autonomous driving and industrial robotics." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 9.b: DOMAIN-SPECIFIC — INDUSTRIAL IoT + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Domain-Specific" + product: "Industrial IoT" + nodes: + - name: open62541 (OPC UA) + repo: https://github.com/open62541/open62541 + home: https://www.open62541.org/ + criticality: critical + features_in_scope: "Open-source OPC UA stack; industrial device connectivity; PLC/sensor data to ML inference pipelines; C99" + notes: "De facto open-source OPC UA implementation. RISC-V should build cleanly (C99). Core to IIoT edge AI pipelines." + + - name: Eclipse Ditto + repo: https://github.com/eclipse-ditto/ditto + home: https://eclipse.dev/ditto/ + criticality: optional + features_in_scope: "Digital twin framework; device shadow; IoT device state management; integrates with edge AI inference results" + notes: "Java-based cloud/edge digital twin. Used in Industry 4.0 edge AI deployments for state management." + + - name: FIWARE Orion Context Broker + repo: https://github.com/telefonicaid/fioriware-orion + home: https://fiware-orion.readthedocs.io/ + criticality: optional + features_in_scope: "NGSI-v2/NGSI-LD context data management; smart city and industrial IoT; AI inference result publishing" + notes: "Used in European smart city and industrial IoT deployments. C++ + MongoDB. Arch-independent." + + - name: EMQX + repo: https://github.com/emqx/emqx + home: https://www.emqx.io/ + criticality: optional + features_in_scope: "High-performance MQTT broker for large IoT fleets; MQTT to Kafka/databases bridge; rule engine for ML triggers" + notes: "Erlang-based. Scales from edge gateway to cloud. Used in manufacturing and energy IoT. Arch-generic Erlang." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 9.c: DOMAIN-SPECIFIC — AUTOMOTIVE + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Domain-Specific" + product: "Automotive" + nodes: + - name: AUTOSAR Adaptive Platform + repo: https://www.autosar.org/ + home: https://www.autosar.org/standards/adaptive-platform/ + criticality: critical + features_in_scope: "Automotive software platform for ADAS/AV ECUs; service-oriented architecture; ML model hosting via Execution Management" + notes: "Proprietary standard. Reference implementations include Apex.AI Apex.OS. RISC-V automotive ECU work is emerging." + + - name: Autoware (ROS 2-based AV stack) + repo: https://github.com/autowarefoundation/autoware + home: https://autoware.org/ + criticality: optional + features_in_scope: "Open-source autonomous driving software; perception (ML), planning, control; ROS 2-based; edge compute on vehicle" + notes: "Linux Foundation. Used by Tier IV and others. ARM64/x86 primary. RISC-V automotive compute is future-looking." + + - name: Eclipse Zenoh + repo: https://github.com/eclipse-zenoh/zenoh + home: https://zenoh.io/ + criticality: optional + features_in_scope: "Zero-overhead pub/sub/query protocol for IoT, robotics, automotive; DDS bridge; extremely low-latency" + notes: "Growing adoption in robotics and automotive as DDS complement. Rust-based. RISC-V riscv64 build possible." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 9.c: DOMAIN-SPECIFIC — SMART HOME + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Domain-Specific" + product: "Smart Home" + nodes: + - name: Home Assistant + repo: https://github.com/home-assistant/core + home: https://www.home-assistant.io/ + criticality: optional + features_in_scope: "Open-source home automation platform; local ML inference via custom components (Whisper, Piper, YOLO); edge-local" + notes: "Fastest-growing open smart home platform. Runs on Raspberry Pi and similar SBCs. Python/arch-independent core." + + - name: OpenThread + repo: https://github.com/openthread/openthread + home: https://openthread.io/ + criticality: optional + features_in_scope: "Thread networking stack for smart home MCU devices; mesh network for IoT sensors feeding edge AI" + notes: "Google. Basis for Matter/Thread. Runs on MCU-class devices. RISC-V MCU support via Zephyr." + + - name: Matter / chip-tool (Project CHIP) + repo: https://github.com/project-chip/connectedhomeip + home: https://csa-iot.org/developer-resource/connected-home-over-ip-chip/ + criticality: optional + features_in_scope: "Unified smart home protocol; device-to-device and device-to-hub; sensor data for local edge AI processing" + notes: "Industry standard (Apple, Google, Amazon, Samsung). C++ + Python. RISC-V MCU build path exists." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 10: FEDERATED LEARNING (edge client side) + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Federated Learning" + nodes: + - name: Flower (flwr) + repo: https://github.com/adap/flower + home: https://flower.ai/ + criticality: optional + features_in_scope: "Federated learning framework; edge client runs local training round; framework-agnostic (PyTorch, TFLite, ONNX)" + notes: "Most widely adopted open-source FL framework. Pure Python client. Runs on capable SBC and edge server." + + - name: TensorFlow Federated (TFF) + repo: https://github.com/google-parfait/tensorflow-federated + home: https://www.tensorflow.org/federated + criticality: optional + features_in_scope: "FL research framework; simulation and production; integrates with TFLite for edge device training rounds" + notes: "Google. Research-heavy. Edge deployment is more niche than Flower." + + # ───────────────────────────────────────────────────────────────────────────── + # LAYER 11: SUPPORTING INFRASTRUCTURE + # ───────────────────────────────────────────────────────────────────────────── + + - layer: "Supporting Infrastructure" + nodes: + - name: gRPC + repo: https://github.com/grpc/grpc + home: https://grpc.io/ + slug: grpc + criticality: optional + features_in_scope: "RPC framework for edge AI service communication; model serving APIs; inter-container comms in edge k8s" + notes: "Debian riscv64 ships. No upstream riscv64 CI; upstream has declined formal support (issue #41591 closed 2026-07-15)." + + - name: Protobuf + repo: https://github.com/protocolbuffers/protobuf + home: https://developers.google.com/protocol-buffers + slug: protocol-buffers + criticality: optional + features_in_scope: "Serialization for gRPC, ONNX model format, TFLite metadata, edge AI config/telemetry" + notes: "Debian sid ships riscv64 package (3.21.12)." + + - name: HuggingFace Hub + repo: https://github.com/huggingface/huggingface_hub + home: https://huggingface.co/docs/huggingface_hub + criticality: optional + features_in_scope: "Model registry client; download pre-quantized GGUF/TFLite/ONNX models to edge devices" + notes: "Pure Python. Arch-independent. Used by llama.cpp, ONNX Runtime, and TFLite-based edge deployments." + + - name: NumPy + repo: https://github.com/numpy/numpy + home: https://numpy.org/ + slug: numpy + criticality: optional + features_in_scope: "Array operations for edge pre/post-processing; underpins Python-based inference pipelines at edge server tier" + notes: "No upstream riscv64 PyPI wheel as of Aug 2026. RISE wheels at 2.5.2. No RVV NPYV backend." + + +chains: + - name: "TFLite vision inference pipeline (SBC)" + sequence: ["V4L2 (camera)", "OpenCV (preprocess)", "TFLite / LiteRT (inference)", "XNNPACK (acceleration)", "FlatBuffers (model load)"] + - name: "LLM inference pipeline (edge server)" + sequence: ["llama.cpp", "ggml (quantized kernels)", "OpenBLAS (GEMM)", "SLEEF (math)", "OpenSSL (model download TLS)"] + - name: "ONNX Runtime inference pipeline (edge server)" + sequence: ["ONNX Runtime CPU EP", "OpenBLAS", "SLEEF", "Protobuf (ONNX model parse)", "FlatBuffers"] + - name: "Edge AI container workload deployment" + sequence: ["KubeEdge (orchestration)", "containerd (runtime)", "k3s (Kubernetes)", "Mender / SWUpdate (OTA)", "WireGuard (secure tunnel)"] + - name: "GStreamer camera AI pipeline" + sequence: ["V4L2 (camera)", "GStreamer (pipeline)", "OpenCV (frame preprocess)", "TFLite / ONNX Runtime (inference)", "MQTT / Mosquitto (result publish)"] + - name: "Industrial IoT AI pipeline" + sequence: ["open62541 (OPC UA sensor data)", "Mosquitto (MQTT bus)", "Node-RED (data routing)", "ONNX Runtime (anomaly detection)", "InfluxDB (time-series store)", "Prometheus + Grafana (monitoring)"] + - name: "Robotics perception pipeline (ROS 2)" + sequence: ["V4L2 / sensor drivers", "ROS 2 (pub/sub)", "FastDDS (transport)", "OpenCV / TFLite (perception)", "Nav2 (navigation)"] + - name: "Secure edge device boot chain" + sequence: ["U-Boot (verified boot)", "Trusted Firmware-A (secure boot)", "OP-TEE (TEE)", "AppArmor (container isolation)", "WireGuard (network security)"] + - name: "Edge observability pipeline" + sequence: ["edge AI service (Prometheus metrics)", "Prometheus node_exporter", "Fluent Bit (log ship)", "Grafana (dashboard)", "OpenTelemetry Collector (traces)"] + - name: "MCU TinyML pipeline (Zephyr)" + sequence: ["Zephyr RTOS", "TFLite Micro (TFLM)", "microTVM (optional compiler)", "MQTT / OpenThread (connectivity)", "micro-ROS (optional robot integration)"] + - name: "Federated learning edge round" + sequence: ["Flower client", "TFLite / ONNX Runtime (local inference)", "local fine-tune step", "Mosquitto / gRPC (gradient upload)", "KubeEdge (workload management)"] diff --git a/stack-reports/edge-ai/edge-ai.svg b/stack-reports/edge-ai/edge-ai.svg new file mode 100644 index 000000000..1bbc4d2e8 --- /dev/null +++ b/stack-reports/edge-ai/edge-ai.svg @@ -0,0 +1,816 @@ + + +Edge AI +-- RISC-V +readiness + +upstream builds+tests+releases; optimized + +upstream builds+tests; mostly optimized + +upstream builds; some optimized + +no upstream build, distributions only; no optimizations + +not working + +unknown or N/A + +Robotics + +Industrial IoT + +Automotive + +Smart Home + + +Domain-Specific + +ROS 2 (Robot Operating System 2) - yellow (critical) +Release: none + + +ROS 2 (Robot +Operating System 2) + + +Nav2 (Navigation 2) - yellow (optional) +Release: none + + +Nav2 +(Navigation 2) + + +MoveIt 2 - yellow (optional) +Release: none + + +MoveIt 2 + + +FastDDS (eProsima) - yellow (critical) +Release: ubuntu +Gap: Upstream CI runs exclusively on ubuntu-24.04 (x86_64) with no riscv64 jobs in any workflow (confirmed in [ubuntu-ci.yml](https://github.com/eProsima/Fast-DDS/blob/master/.github/workflows/ubuntu-ci.yml) and [nightly-ubuntu-master.yml](https://github.com/eProsima/Fast-DDS/blob/master/.github/workflows/nightly-ubuntu-master.yml), both delegating to a reusable workflow that only targets `linux_gcc_64`). Ubuntu Resolute (26.04) and Debian Sid ship `libfastdds3.3`, `libfastdds-dev`, and `fastdds-tools` for riscv64; all 17 Debian patches are general build fixes (docs, system-library substitutions, GCC-15 fix, CMake fixes) with none targeting riscv64 specifically, confirmed by reading the full patch list via [sources.debian.org](https://sources.debian.org/src/fastdds/3.3.0+ds-3/debian/patches/), and Debian riscv64 autopkgtest reports Pass per the [Debian tracker](https://tracker.debian.org/pkg/fastdds). This clean distro build without upstream CI yields yellow (clean-distro-build). + + +FastDDS +(eProsima) + + +CycloneDDS (Eclipse) - yellow (optional) +Release: ubuntu +Gap: All five CI workflow files (linux.yml, cxx_bindings.yml, macos.yml, python_bindings.yml, windows.yml) contain zero riscv64 references; jobs run on ubuntu-22.04 and ubuntu-24.04 x86_64 runners only ([linux.yml](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/.github/workflows/linux.yml)). Ubuntu resolute (26.04) ships cyclonedds-dev 0.10.5-1build1 for riscv64 ([packages.ubuntu.com](https://packages.ubuntu.com/search?keywords=cyclonedds&searchon=names&suite=resolute&section=all)). All seven Debian packaging patches were individually inspected: none target riscv64 (patch 0005 fixes big-endian architectures which does not affect little-endian riscv64, patch 0004 targets GNU/Hurd), confirming a clean build from unmodified upstream source and supporting the yellow clean-distro-build classification. + + +CycloneDDS +(Eclipse) + + +Iceoryx (Eclipse) - yellow (optional) +Release: debian +Gap: Upstream CI ([build-test.yml](https://github.com/eclipse-iceoryx/iceoryx/blob/main/.github/workflows/build-test.yml), nightly.yml) covers only ubuntu-24.04 (x86_64), Windows, FreeBSD -- zero riscv64 jobs. Debian "resolute" ships 13 riscv64 binary packages at 2.0.6+dfsg-2 (project graph) and 2.0.8+dfsg-1 successfully built on rv-osuosl-01 (buildd.debian.org). The 8 Debian patches include two un-forwarded items (0007 libatomic INTERFACE linkage, 0008 time_t type fix) that are generic Linux/portability fixes with no riscv64-specific target; the "clean-distro-build" floor applies. Release provider is Debian, not Ubuntu: the project graph URI base is debian/resolute, correcting the proposed ubuntu attribution. + + +Iceoryx +(Eclipse) + + +open62541 (OPC UA) - yellow (critical) +Release: debian +Gap: Upstream CI ([build_linux.yml](https://github.com/open62541/open62541/blob/master/.github/workflows/build_linux.yml)) runs exclusively on x86_64 Ubuntu runners with no riscv64 job and no riscv64 binary release artifacts. Debian sid ships open62541 1.4.18-1 for riscv64 with a "Installed" build status; the single Debian patch (`hardened_ns0.diff`) is architecture-agnostic, confirming a clean build from unmodified upstream C99 source. Ubuntu questing (26.04) carries the same library at 1.4.11.1-1 for riscv64, consistent with the distribution floor of yellow/clean-distro-build. + + +open62541 (OPC +UA) + + +Eclipse Ditto - green (optional) +Release: upstream +Gap: Eclipse Ditto is 100% pure Java with no compiled native code or JNI dependencies (confirmed by inspecting the BOM pom.xml and Maven Central artifact classifiers): every released JAR is a platform-neutral `.jar` with no architecture-specific classifier, triggering Step 0 of the color model. Step 0 assigns green directly for architecture-independent projects; the absence of riscv64 Docker images is irrelevant because the deployable JARs are architecture-neutral and upstream publishes them to Maven Central for the current release (3.9.6 available at [Maven Central](https://repo1.maven.org/maven2/org/eclipse/ditto/ditto-messages-model/3.9.6/)). The proposed blue was incorrect: blue requires upstream CI that builds and tests on riscv64, of which there is none; and blue also cannot be assigned when Step 0 applies. + +Eclipse Ditto + + +FIWARE Orion Context Broker - orange (optional) +Release: none +Gap: All CI workflows ([unit.yml](https://github.com/telefonicaid/fiware-orion/blob/master/.github/workflows/unit.yml), [functional.yml](https://github.com/telefonicaid/fiware-orion/blob/master/.github/workflows/functional.yml)) run exclusively on ubuntu-22.04 x86_64 with no riscv64 jobs. No riscv64 package exists in Ubuntu Noble, Debian, or Arch RISC-V, and DockerHub confirms all published image tags are linux/amd64 only -- there is no downstream channel shipping a riscv64 artifact, making the proposed color_case "downstream-only" factually incorrect. With no positive evidence of either working or broken status on riscv64, the correct classification is grey (unknown-unknown), not orange downstream-only. + + +FIWARE Orion +Context Broker + + +EMQX - orange (optional) +Release: none +Gap: Live verification of [build_matrix.py](https://raw.githubusercontent.com/emqx/emqx/master/scripts/rel/build_matrix.py) confirms `LINUX_ARCH = ["amd64", "arm64"]` with no riscv64 entry. The [test workflow](https://raw.githubusercontent.com/emqx/emqx/master/.github/workflows/run_test_cases.yaml) runs exclusively on `aws-ubuntu22.04-amd64` runners. GitHub releases (6.2.2) and Docker Hub tags ship only linux/amd64 and linux/arm64 -- no riscv64 artifact or platform exists anywhere in the release pipeline. No Ubuntu/Debian package for emqx was found, so no distribution floor applies; this is a clean no-CI, no-distro, no-release situation. + + +EMQX + + +AUTOSAR Adaptive Platform - grey (critical) +Release: none +Gap: AUTOSAR Adaptive Platform is a proprietary specification (current release R25-11) with no public source repository, no CI system, and no open-source reference implementation. Live checks of the [primary AUTOSAR page](https://www.autosar.org/standards/adaptive-platform/) and all known commercial implementations (Elektrobit EB corbos AdaptiveCore targeting NXP/NVIDIA/Renesas/TI, Apex.AI Apex.OS) show zero mention of RISC-V. GitHub search returns no repositories combining AUTOSAR Adaptive with RISC-V. No distro package exists. The spec is POSIX-based and not inherently incompatible with RISC-V, but no confirmed support and no confirmed breakage exist -- a genuine unknown-unknown. + + +AUTOSAR Adaptive +Platform + + +Autoware (ROS 2-based AV stack) - orange (optional) +Release: none +Gap: All CI workflows enumerate exactly `amd64` and `arm64` as targets; the reusable workflow [docker-build.yaml](https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/docker-build.yaml) declares its `platform` input as `"amd64 or arm64"` with no riscv64 path, and the calling workflow [docker-build-and-push.yaml](https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/docker-build-and-push.yaml) instantiates only `humble-amd64`, `humble-arm64`, `jazzy-amd64`, `jazzy-arm64` jobs. A code search across the entire repository returns zero results for "riscv64", no RISC-V issues or PRs exist, and the latest release v1.9.0 (2026-07-16) carries no binary assets of any kind. The `downstream-only` sub-type is retained as the closest match for "no upstream CI, no riscv64 path" though no confirmed downstream distro package exists either. + + +Autoware (ROS +2-based AV stack) + + +Eclipse Zenoh - orange (optional) +Release: none +Gap: The [build-crates-standalone.yml](https://github.com/eclipse-zenoh/ci/blob/main/.github/workflows/build-crates-standalone.yml) matrix used for all releases covers x86_64, arm, armv7, and aarch64 only -- riscv64 is absent. The [1.10.0 release assets](https://github.com/eclipse-zenoh/zenoh/releases/tag/1.10.0) confirm no riscv64 binary is published. Ubuntu noble, Debian, Fedora, and Arch RISC-V carry no zenoh package, so no distribution floor applies at all; `color_case: downstream-only` from the proposed classification is incorrect because no downstream ships it either. The color stays orange but with no sub-type. + + +Eclipse Zenoh + + +Home Assistant - yellow (optional) +Release: RISE +Gap: The proposed green was refuted on two grounds. First, Step 0 does not apply: although the `homeassistant` wheel is `py3-none-any`, its mandatory (non-optional) compiled dependencies `orjson==3.12.0` (Rust) and `ciso8601==2.3.3` (C extension) have no upstream riscv64 wheels on PyPI -- installation on riscv64 fails without the RISE extra index ([RISE orjson riscv64 index](https://gitlab.com/api/v4/projects/56254198/packages/pypi/simple/orjson/)). Second, upstream CI (builder.yml, ci.yaml) targets only `["amd64", "aarch64"]` with zero riscv64 build or test jobs, so the release_provider cannot be upstream. RISE provides riscv64 wheels for both orjson (3.11.9 and 3.12.0) and ciso8601 (2.3.3), enabling installation from unmodified upstream source -- this matches the clean-distro-build distribution floor, yielding yellow. + + +Home Assistant + + +OpenThread - orange (optional) +Release: third-party +Gap: All five CI workflows (build.yml, unit.yml, simulation.yml, posix.yml, docker.yml) run exclusively on ubuntu-24.04/22.04 x86_64 runners and ARM bare-metal toolchains; docker.yml covers linux/amd64 and linux/arm64 only with no linux/riscv64 platform entry. The Thread networking stack is absent from Debian and Ubuntu packages (the "openthread" packages in those distros are OpenThreads, an unrelated threading library). RISC-V MCU support exists only via Espressif's downstream fork in ESP-IDF, which its own sbom.yml describes as "Espressif fork of OpenThread project, used to maintain ESP-specific patches" -- third-party, downstream, and not reflected in any upstream CI or platform example. + + +OpenThread + + +Matter / chip-tool (Project CHIP) - orange (optional) +Release: none +Gap: Live checks on all CI workflows confirm zero Linux riscv64 host build or test jobs: the host builder ([scripts/build/builders/host.py](https://github.com/project-chip/connectedhomeip/blob/master/scripts/build/builders/host.py)) enumerates only x64, arm64, and armhf targets. All riscv64 references in the codebase are for bare-metal MCU toolchains (riscv64-unknown-elf- for Bouffalo Lab and Telink/Zephyr) or Android riscv64, not Linux riscv64 host. No riscv64 chip-tool packages were found in Ubuntu, Debian, Fedora, or Arch RISC-V, and GitHub releases contain no riscv64 artifacts - so there is no downstream providing riscv64 support either. + + +Matter / chip-tool +(Project CHIP) + + + + + + + +ML Inference Runtimes + +llama.cpp - blue (critical) +Release: debian +Gap: Native riscv64 CI on RISE-provided `ubuntu-24.04-riscv` runners builds with native gcc-14 and executes `ctest -L main` plus an end-to-end llama2c inference test on every push to master, confirmed live by reading [build-riscv.yml](https://github.com/ggerganov/llama.cpp/blob/master/.github/workflows/build-riscv.yml). Upstream publishes no riscv64 release binaries (PR [#20991](https://github.com/ggerganov/llama.cpp/pull/20991) remains open, issue [#20988](https://github.com/ggerganov/llama.cpp/issues/20988) was closed as not-planned); Debian 13 Trixie ships riscv64 packages `libllama0` and `libllama-dev`. The optimization modifier caps at blue (partial): quants.c has full RVV vec_dot coverage across all major formats (Q2_K through Q6_K, IQ1_S through IQ4_XS), but repack.cpp GEMM/GEMV tiled paths cover only Q4_0, Q4_K, Q2_K, Q8_0, and IQ4_NL -- Q3_K, Q5_K, and Q6_K tiled GEMM/GEMV paths are absent, leaving those formats at the vec_dot scalar-tiling fallback for batched matrix operations. + + +llama.cpp + + +ONNX Runtime (edge / mobile EP) - yellow (critical) +Release: debian +Gap: No riscv64 CI exists in microsoft/onnxruntime: a live check on 2026-08-29 scanned all 51 GitHub Actions workflow files and found zero riscv64 hits, confirming the [project report](https://github.com/microsoft/onnxruntime). Debian sid ships a riscv64 binary (v1.23.2+dfsg) built from unpatched upstream source -- the `+dfsg` suffix denotes DFSG source stripping only, not riscv64-specific patches -- which lifts the floor to yellow (clean-distro-build). The optimization-purpose modifier for MLAS CPU EP rates coverage as partial (11 RVV intrinsics files covering SGEMM, INT8/FP16 GEMM, convolution, pooling, LayerNorm, RMSNorm, RoPE, activations; BF16 GEMM and FP16 RoPE are stubs), capping at blue -- which does not further constrain the yellow floor. No grounds to downgrade to orange: the report found no riscv64-specific patches in the Debian packaging, and upstream build support for riscv64 has existed since PR #19238 (January 2024). + + +ONNX Runtime (edge +/ mobile EP) + + +TensorFlow Lite / LiteRT - orange (critical) +Release: none +Gap: All 16 GitHub Actions workflow files (confirmed live 2026-08-29; 3 new files added since June 2026 report, all zero riscv64 references) contain no riscv64 jobs, no riscv64 wheel has ever appeared on PyPI, and LiteRT is absent from all Linux distro riscv64 repositories. As an optimization-purpose inference runtime whose primary value is accelerated CPU inference via XNNPACK, the optimization modifier caps at orange: Section 4 of [the project report](https://github.com/google-ai-edge/LiteRT/tree/main/tflite/kernels/internal/optimized) confirms 0 RVV files vs 4 NEON and 4 SSE files, with all RISC-V execution falling to scalar portable C. The blocking chain runs through [cpuinfo #124](https://github.com/pytorch/cpuinfo/issues/124) (still open, Zvfh detection missing) and [XNNPACK #9886](https://github.com/google/XNNPACK/issues/9886) (still open, 100+ RVV FP16 CI failures). + + +TensorFlow Lite +/ LiteRT + + +TensorFlow Lite Micro (TFLM) - orange (optional) +Release: none +Gap: Upstream CI in [suite_riscv.yml](https://github.com/tensorflow/tflite-micro/blob/main/.github/workflows/suite_riscv.yml) and [merge_group.yml](https://github.com/tensorflow/tflite-micro/blob/main/.github/workflows/merge_group.yml) targets riscv32 MCU only (TARGET=riscv32_generic, arch rv32imc, QEMU riscv32) as confirmed by [test_riscv.sh](https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/tools/ci_build/test_riscv.sh); there is no riscv64 build target (only [riscv32_generic_makefile.inc](https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/tools/make/targets/riscv32_generic_makefile.inc) exists), no riscv64 CI, and no riscv64 release artifacts (PyPI wheels are x86_64-only, no GitHub releases). The project provides architecture-specific optimized kernels for Cortex-M/CMSIS-NN, Hexagon, and Xtensa but has zero riscv64-specific kernel code, leaving all riscv64 paths as scalar C fallback; combined with no riscv64 CI and no distro packaging, this caps at orange (optimization-absent). + + +TensorFlow Lite +Micro (TFLM) + + +ExecuTorch - yellow (critical) +Release: none + + +ExecuTorch + + +ncnn - blue (critical) +Release: none +Gap: ncnn has dedicated [linux-riscv64 CI](https://github.com/Tencent/ncnn/blob/master/.github/workflows/linux-riscv64.yml) with explicit `ctest` test steps on riscv64 via QEMU (gcc-riscv64, gcc-rvv vlen=128/256, clang-rvv vlen=128/256) plus self-hosted XuanTie and SpacemiT jobs, all confirmed to run the full test suite and not merely build. The [src/layer/riscv/](https://github.com/Tencent/ncnn/tree/master/src/layer/riscv) directory contains 180 files covering all primary hot paths (convolution, GEMM, depthwise, pooling, attention, normalization) with RVV intrinsics and ZFH/ZVFH fp16 -- full optimization coverage. The [20260526 release](https://github.com/Tencent/ncnn/releases/tag/20260526) has no standalone Linux riscv64 prebuilt, only Android bundles, so blue (not green) is correct. + + +ncnn + + +MNN (Alibaba) - orange (optional) +Release: none +Gap: No riscv64 CI exists in any workflow: linux.yml, mnn_release.yml, pymnn_linux.yml, and android.yml all run exclusively on ubuntu-latest (x86_64), confirmed by reading [.github/workflows/linux.yml](https://github.com/alibaba/MNN/blob/master/.github/workflows/linux.yml) and [mnn_release.yml](https://github.com/alibaba/MNN/blob/master/.github/workflows/mnn_release.yml). Release artifacts cover android/arm, iOS, Linux-x64, macOS, and Windows only -- no riscv64 binary in any of the three most recent releases (3.6.1, 3.6.0, 3.5.0). The proposed color_case of downstream-only is incorrect: Alibaba's MNN is not packaged by Ubuntu, Debian, or Arch Linux RISC-V for any architecture, so there is no downstream either; orange is correct but solely because no upstream CI exists -- the 93 RVV source files under source/backend/cpu/riscv/rvv/ (covering matmul, INT8 GEMM, attention, depthwise conv, activations) are untested by CI. + + +MNN (Alibaba) + + +PaddlePaddle Lite - orange (optional) +Release: none +Gap: The only CI file is a lint-only `.travis.yml` (no build or test jobs); no `.github/workflows` directory exists. The [lite/kernels directory](https://github.com/PaddlePaddle/Paddle-Lite/tree/develop/lite/kernels) contains backends for arm, host, metal, nnadapter, opencl, x86, and xpu but no riscv backend, and a full-repo code search returns zero hits for "riscv". Release assets through v2.14-rc cover only arm, x86, iOS, and macOS -- no riscv64 artifact. As an optimization-purpose inference runtime with absent RISC-V optimization (all paths fall back to generic scalar via the "host" backend), the grade is capped at orange. + + +PaddlePaddle +Lite + + +MindSpore Lite (Huawei) - orange (optional) +Release: none +Gap: The active development repository is `mindspore-ai/mindspore-lite` (last pushed 2026-08-29), not the archived monorepo cited in the proposal. It has a cross-compilation build path for rv64 (`MSLITE_CROSS_RISCV=rv64`) and an `rvv/` kernel directory; `adderfloat_rvv.c` contains genuine RVV intrinsics (vsetvl, vle32, vfsub, vfadd, etc.) for element-wise activation ops, but `matmul_rvv.c` -- the critical hot path -- uses scalar C only despite being in the rvv/ directory. No upstream CI builds or tests riscv64 (Jenkins-only lint checks; no GitHub Actions), no riscv64 release artifacts exist, and the primary optimization value (matrix multiplication for inference) has no real RVV implementation, so the optimization-absent cap at orange applies and the no-CI base color of orange is confirmed. See [mindspore-ai/mindspore-lite rvv directory](https://github.com/mindspore-ai/mindspore-lite/tree/master/mindspore-lite/src/litert/kernel/cpu/nnacl_c/intrinsics/rvv). + + +MindSpore Lite +(Huawei) + + +OpenVINO Runtime - yellow (critical) +Release: none + + +OpenVINO +Runtime + + +Apache TVM / microTVM - orange (optional) +Release: none +Gap: No upstream riscv64 CI exists: the cpu_jenkinsfile defines `ci_riscv = ''` as an empty placeholder and no corresponding Docker image is in [docker-images.ini](https://github.com/apache/tvm/blob/main/ci/jenkins/docker-images.ini) (confirmed live 2026-08-29); no riscv64 wheel is published on PyPI (latest 0.26.0 covers x86_64, aarch64, macOS arm64, Windows only); no Linux distribution packages TVM for riscv64. The proposed `optimization-absent` color_case is incorrect: TVM has RISC-V-specific optimizations in [riscv_cpu.py](https://github.com/apache/tvm/blob/main/python/tvm/s_tir/tensor_intrin/riscv_cpu.py) (241-line RVV dot-product kernel intrinsics using `rvv_vec_dot_product_kernels`) and SiFive/SpacemiT CPU target tags -- but coverage is minimal (dot-product only; no RISC-V-specific dlight GEMV/GEMM schedule rules comparable to arm64 SME/NEON), which would cap at yellow under the optimization modifier -- a cap that has no effect since the primary grade is already orange from absent CI. + + +Apache TVM / +microTVM + + +whisper.cpp - blue (optional) +Release: none + + +whisper.cpp + + + +Model Optimization & +Conversion + +ONNX (format + tooling) - yellow (critical) +Release: RISE +Gap: Upstream CI ([release_linux_cibw.yml](https://github.com/onnx/onnx/blob/main/.github/workflows/release_linux_cibw.yml)) covers only x86_64 and aarch64 with no riscv64 job, and no riscv64 wheel is published to PyPI by upstream. Ubuntu resolute (26.04) ships `python3-onnx` 1.20.0-1 and `libonnx-dev` 1.20.0-1 for riscv64 with only generic packaging patches (cmake-no-rpath, fix-shebang, soversion -- no architecture-specific patches), qualifying as a clean distro build and triggering the yellow distribution floor. RISE additionally provides current `onnx-1.22.0-cp312-abi3-manylinux_2_39_riscv64.whl` wheels covering v1.19.1 through v1.22.0; ONNX is a protobuf schema and tooling library with no architecture-specific compute kernels, so the optimization modifier does not apply. + + +ONNX (format + +tooling) + + +Intel Neural Compressor (INC) - green (optional) +Release: upstream +Gap: Intel Neural Compressor v3.9 ships as [neural_compressor-3.9-py3-none-any.whl](https://pypi.org/pypi/neural-compressor/3.9/json) with `ext_modules=[]` unconditionally in setup.py and zero C/C++/Cython/CUDA files in the repository tree, making it architecture-independent pure Python that runs on riscv64 by construction (Step 0 shortcut). The wheel is published directly to PyPI by the Intel AIPT team (suyue.chen@intel.com), so release_provider is upstream. INC is a Python orchestration layer for quantization workflows that delegates compute to PyTorch/TF/JAX backends, so the optimization-purpose modifier (Step 2) does not apply. + +Intel Neural +Compressor (INC) + + +NNCF (Neural Network Compression Framework, Intel) - orange (optional) +Release: upstream +Gap: Although the PyPI artifact is a `py3-none-any` wheel, NNCF ships C++/CUDA source files under `src/nncf/torch/extensions/` that are JIT-compiled at runtime via `torch.utils.cpp_extension.load()` with `ninja` as a hard dependency ([pyproject.toml](https://github.com/openvinotoolkit/nncf/blob/develop/pyproject.toml), [extensions.py](https://github.com/openvinotoolkit/nncf/blob/develop/src/nncf/torch/quantization/extensions.py)); this disqualifies the Step 0 "architecture-independent" shortcut. All CI workflows run exclusively on `ubuntu-latest` (x86_64) or GPU runners -- no riscv64 build or test job exists -- placing this at orange under Step 1 (no upstream riscv64 CI). The CPU extension does have a graceful Python fallback on compile failure, but the project has never been tested on riscv64 and no distro floor has been established. + +NNCF (Neural Network +Compression +Framework, Intel) + + +HuggingFace Optimum - green (optional) +Release: upstream +Gap: HuggingFace Optimum ships exclusively as a `py3-none-any` wheel (confirmed for the latest release [optimum 2.3.0](https://pypi.org/pypi/optimum/2.3.0/json)). A scan of the full repository tree confirms zero compiled source files (.c, .cpp, .rs, etc.) and `setup.py` declares no `ext_modules`, making the package architecture-independent. Step 0 applies: green by construction, no riscv64 CI required or penalized for absence. + +HuggingFace +Optimum + + +Kernel Libraries & +Compute Primitives + +XNNPACK - yellow (critical) +Release: none + + +XNNPACK + + +OpenBLAS - blue (critical) +Release: debian +Gap: Upstream [riscv64_vector.yml](https://github.com/OpenMathLib/OpenBLAS/blob/develop/.github/workflows/riscv64_vector.yml) builds and runs the full BLAS L1/L2/L3 test suite under QEMU for ZVL128B, ZVL256B, and DYNAMIC_ARCH on every push/PR, confirming blue CI posture (tests pass, no upstream riscv64 binary release - only Windows and source tarballs in GitHub releases). The optimization modifier is partial: GEMM and GEMV have full RVV 1.0 coverage for all precisions; TRSM gained RVV kernels via [PR #5830](https://github.com/OpenMathLib/OpenBLAS/pull/5830) (merged 2026-08-16) giving STRSM full RVV coverage, but DTRSM LN/LT, CTRSM LN/LT, and ZTRSM LN/LT/RN still fall back to generic C on both ZVL128B and ZVL256B targets. Partial optimization caps at blue, matching the CI grade. + + +OpenBLAS + + +SLEEF - blue (critical) +Release: debian +Gap: The Jenkinsfile at shibatch/sleef has two riscv64 stages on `riscv && ubuntu24` agents that run `ctest` with `-DSLEEF_ENFORCE_TESTER4=True -DSLEEF_ENFORCE_RVVM1=True -DSLEEF_ENFORCE_RVVM2=True`; TLFloat-based tester4 accuracy tests execute for all transcendentals -- confirmed genuine test execution, not build-only ([Jenkinsfile](https://github.com/shibatch/sleef/blob/master/Jenkinsfile)). The RVV backend in `src/arch/helperrvv.h` (1407 lines of RVV intrinsics) covers all SP and DP transcendentals for RVVM1 and RVVM2, delivering full optimization coverage with no downward cap. Upstream GitHub releases are source-only (no binary assets for any arch); Debian sid ships `libsleef3` 3.9.0-1 for riscv64 from unpatched upstream source (no riscv64-specific patches in debian/patches/, confirmed via [sources.debian.org](https://sources.debian.org/src/sleef/3.9.0-1/debian/patches/)). + + +SLEEF + + +ARM Compute Library (ACL) [ARM Only] - grey (optional) +Release: none +Gap: ARM Compute Library is by design exclusive to Arm architectures: the README explicitly states it is "optimized for Arm Cortex-A, Neoverse, and Mali GPU architectures," CMakeLists.txt only supports armv8-a/armv8.2-a/armv8.6-a targets, and a full GitHub code search returns zero files referencing riscv. All upstream releases (confirmed through v53.2.0) are exclusively aarch64 and armv7a binaries with no riscv64 variant. The project-graph confirms no riscv64 distro package exists. RISC-V is not applicable by design. + + +ARM Compute Library +(ACL) [ARM Only] + + +RUY (Google matrix multiply) - orange (optional) +Release: ubuntu +Gap: Adversarial verification confirms the proposed color. No .github/workflows directory exists (404 from GitHub API), confirming zero upstream CI for any architecture. Ubuntu 26.04 (resolute) and Ubuntu 24.04 (noble) both ship libruy-dev for riscv64 (confirmed via project graph: version 0.0.0~git20230215.21a85fe-3, suite resolute, arch riscv64); the single Debian packaging patch (Remove_cxx14_compat.patch) removes a generic -Wc++14-compat warning flag from CMakeLists.txt for all architectures and is not riscv64-specific, so the clean-distro-build yellow floor applies. Ruy is an optimization-purpose library (SIMD matmul) with zero RISC-V-specific code -- no RUY_PLATFORM_RISCV macro, no RVV kernel, no riscv64 path enum entry (confirmed live in platform.h and path.h) -- so the absent-optimization cap lowers yellow to orange. + + +RUY (Google +matrix multiply) + + +FlatBuffers - yellow (critical) +Release: ubuntu +Gap: Upstream [google/flatbuffers](https://github.com/google/flatbuffers) has no riscv64 CI in any of its six workflow files -- confirmed by live check of [build.yml](https://github.com/google/flatbuffers/blob/master/.github/workflows/build.yml) (no riscv64, QEMU, or cross-compile references). Ubuntu 26.04 (resolute) ships `libflatbuffers-dev`, `libflatbuffers23.5.26`, `flatbuffers-compiler`, and `flatbuffers-compiler-dev` at 23.5.26+dfsg-4build1 for riscv64 (confirmed via project-graph); the three Debian packaging patches (`8201.patch` for mips/hppa NaN, `s390x.patch` for GCC warning suppression, `setup-py.patch`) are none of them riscv64-specific, confirming a clean unpatched upstream build on riscv64. FlatBuffers is architecture-agnostic (no SIMD, no assembly), so no optimization gap exists. + + +FlatBuffers + + + +Data Pipeline & Local +Processing + +OpenCV - blue (critical) +Release: ubuntu +Gap: The `OCV-PR-5.x-RISCV.yaml` workflow in the `opencv/ci-gha-workflow` repo defines a `BuildAndTest` job that cross-compiles with RVV enabled and then executes three accuracy test suites (core, imgproc, dnn) under QEMU; the nightly `OCV-Nightly-RISCV.yaml` runs the same suites on real RISC-V boards (`lichee1`, `canmv1`). Upstream publishes no riscv64 release artifact (the 5.0.0 release ships only Android, iOS, Windows, and docs), but Ubuntu ships `python3-opencv` for riscv64 from noble (24.04 LTS) onward at version 4.10.0, placing release_provider at ubuntu. OpenCV also has a broad RVV HAL under `hal/riscv-rvv/` covering core, imgproc, dnn, and features2d hot paths, giving a partial-to-full optimization level that does not cap below blue. + + +OpenCV + + +GStreamer - yellow (critical) +Release: ubuntu +Gap: GStreamer's own monorepo has no riscv64 CI job of any kind (confirmed live against the [GitHub mirror CI config](https://raw.githubusercontent.com/GStreamer/gstreamer/main/.gitlab-ci.yml) on 2026-08-29). The distribution floor applies: Ubuntu 26.04 "Resolute" ships libgstreamer1.0-0 1.28.2-1 and a full plugin set for riscv64 (confirmed via project graph and [packages.ubuntu.com/resolute/libgstreamer1.0-0](https://packages.ubuntu.com/resolute/libgstreamer1.0-0)), with no riscv64-specific patches in the Debian packaging diff. ORC (GStreamer's SIMD layer) gained a native riscv64 CI job with meson test execution on 2026-08-05 -- a meaningful positive signal for the dependency stack -- but GStreamer's own grade is driven by its own CI posture, not ORC's. + + +GStreamer + + +MediaPipe - orange (optional) +Release: none +Gap: The only CI workflow in google/mediapipe is `stale.yaml` (issue management); there is no build or test CI for any architecture. PyPI lists wheels only for x86_64 and aarch64/arm64 across all versions including v1.0.1 -- no riscv64 wheel has ever been published ([PyPI JSON](https://pypi.org/pypi/mediapipe/json)). A code search for "riscv64" across the entire repository returns zero results, and no Linux distribution (Debian, Ubuntu Noble, Arch RISC-V) packages mediapipe for riscv64. The proposed `color_case: downstream-only` was incorrect: that sub-type requires a downstream distro to be shipping the package, which is not the case here; plain orange (no CI, no distro coverage) is the correct classification. + + +MediaPipe + + +Mosquitto (Eclipse) - yellow (critical) +Release: none + + +Mosquitto +(Eclipse) + + +Node-RED - green (optional) +Release: upstream +Gap: Node-RED is effectively architecture-independent: it ships no compiled code of its own (no gypfile, no cpu/os fields), and its sole native optionalDependency (`@node-rs/bcrypt` 1.10.7) has an explicit try/catch fallback to the pure-JS `bcryptjs` in [`packages/node_modules/@node-red/editor-api/lib/auth/users.js`](https://github.com/node-red/node-red/blob/main/packages/node_modules/%40node-red/editor-api/lib/auth/users.js), so the absence of a riscv64 prebuilt for `@node-rs/bcrypt` does not affect functionality. Upstream publishes releases directly to npm (latest: v5.0.4), and the Step 0 architecture-independent shortcut applies -- no riscv64 CI is required for this grade. The proposed justification claiming "all 57 dependencies are pure JavaScript" was slightly inaccurate (one optional native dep exists) but the green conclusion stands because full functionality is preserved on riscv64 via the pure-JS fallback. + +Node-RED + + +InfluxDB (edge / v1.x) - yellow (optional) +Release: none + + +InfluxDB (edge +/ v1.x) + + +SQLite - yellow (critical) +Release: ubuntu +Gap: SQLite has no upstream CI of any kind -- the GitHub mirror's `.github/` directory returns HTTP 404, confirmed live. No upstream riscv64 artifact is published (official downloads provide Linux x64 only). Ubuntu 24.04 and Debian sid (3.53.4-2, "Installed" on rv-manda-01) both ship sqlite3 for riscv64 from unpatched upstream source: the Debian packaging contains 11 patches, none riscv64-specific (the two cross-compilation patches are generic fixes applicable to all target architectures). The optimization-purpose modifier does not apply -- SQLite is pure portable C with no SIMD, no assembly, and no JIT on any architecture. + + +SQLite + + +V4L2 (Video4Linux2) - yellow (critical) +Release: Debian +Gap: The proposed green color and `release_provider: upstream` cannot be sustained. Upstream (kernel.org for V4L2-in-kernel, linuxtv.org for v4l-utils) publishes source tarballs only - no riscv64 binary artifacts - so the release_provider is the distro, not upstream, which precludes green. The Debian buildd confirms v4l-utils 1.32.0-5 builds successfully on riscv64 with only a documentation patch (`dont-gererate-treeview.diff`, not riscv64-specific), qualifying as a clean distro build. Upstream CI for riscv64 testing could not be confirmed (linuxtv.org v4l-utils CI is Anubis-blocked and no riscv64 test evidence was found), so the floor is yellow/clean-distro-build per the color model. + + +V4L2 +(Video4Linux2) + + +Fleet Management, +Orchestration, +Observability, +Debugging + +k3s (Rancher) - orange (critical) +Release: none +Gap: All 20 workflow files on main contain zero riscv64 build or test jobs -- the single `riscv64` mention in [build-k3s.yaml](https://github.com/k3s-io/k3s/blob/master/.github/workflows/build-k3s.yaml) is only a runner-selection conditional, not a build target. The [latest release v1.36.4+k3s1](https://github.com/k3s-io/k3s/releases/tag/v1.36.4%2Bk3s1) (2026-08-27) ships only amd64, arm64, and armhf binaries. Draft [PR #13854](https://github.com/k3s-io/k3s/pull/13854) proposing riscv64 e2e CI (on RISE runners) remains unmerged and was last updated 2026-04-28; a second open PR [#14529](https://github.com/k3s-io/k3s/pull/14529) fixing a seccomp issue in riscv64 builds confirms external development interest but is also unmerged. + + +k3s (Rancher) + + +k0s - blue (optional) +Release: none +Gap: The nightly riscv64.yml workflow (merged via PR #7414 on 2026-06-19) runs three confirmed test-execution steps on native RISE RISC-V hardware (Scaleway EM-RV1): unit tests via `make check-unit` in unittests-k0s.yml, and two integration smoke tests (basic, airgap) via `make -C inttest` in smoketest.yaml -- this is genuine test execution, not build-only CI, confirming blue over yellow. However, the latest upstream release (v1.36.3+k0s.2, 2026-08-12) contains zero riscv64 assets, no distro ships a riscv64 k0s binary, and the workflow has no pull_request trigger so riscv64 is not a merge gate, ruling out green and confirming blue. + + +k0s + + +KubeEdge - orange (critical) +Release: none +Gap: KubeEdge upstream CI covers only amd64, arm64, and arm/v7 -- confirmed by the [release workflow](https://github.com/kubeedge/kubeedge/blob/master/.github/workflows/release.yml) and the [v1.23.1 release assets](https://github.com/kubeedge/kubeedge/releases/tag/v1.23.1) (published 2026-07-15), which contain no riscv64 binary. The sole riscv64 cross-build attempt ([PR #3904](https://github.com/kubeedge/kubeedge/pull/3904)) was closed stale and unmerged in September 2022 and no further riscv64 PRs or issues exist. No Linux distribution (Ubuntu noble, Debian, Fedora) ships a riscv64 KubeEdge package, so the distribution floor does not apply; orange reflects the absence of any upstream or downstream riscv64 support. + + +KubeEdge + + +containerd - yellow (critical) +Release: upstream +Gap: Upstream containerd publishes a first-class `linux/riscv64` tarball with every release (confirmed in [v2.3.4](https://github.com/containerd/containerd/releases/tag/v2.3.4): `containerd-2.3.4-linux-riscv64.tar.gz` and static variant). The [ci.yml](https://github.com/containerd/containerd/blob/main/.github/workflows/ci.yml) `integration-linux` job matrix targets only `ubuntu-22.04`, `ubuntu-24.04`, and `ubuntu-24.04-arm` -- no riscv64 runner is present. [PR #13124](https://github.com/containerd/containerd/pull/13124), which would add riscv64 to the test matrix via RISE runners, remains open and unmerged (merged_at: null, last updated 2026-08-08). The [nightly.yml](https://github.com/containerd/containerd/blob/main/.github/workflows/nightly.yml) cross-compiles riscv64 with `make binaries` only -- no test execution step. Yellow (build-only-ci) is confirmed; proposed color cannot be refuted. + +containerd + + +crun - yellow (optional) +Release: upstream +Gap: The [test.yaml](https://github.com/containers/crun/blob/main/.github/workflows/test.yaml) `build_job` matrix includes a `riscv64` entry that uses `uraimo/run-on-arch-action` to run `./autogen.sh`, `./configure`, and `make ... crun` inside QEMU -- no `make check` or test execution of any kind. The companion `Test` job (which carries `check`, `check-no-openat2`, `podman`, `containerd`, and a dozen other test variants) runs exclusively on `ubuntu-latest` (amd64) with no riscv64 entry. Upstream publishes signed riscv64 release binaries directly (e.g. `crun-1.29.1-linux-riscv64`) via [release.yaml](https://github.com/containers/crun/blob/main/.github/workflows/release.yaml) cross-build, confirming `release_provider: upstream`; but build-only CI caps the grade at yellow. + +crun + + +WasmEdge - blue (optional) +Release: none +Gap: The upstream CI workflow [build_for_riscv.yml](https://github.com/WasmEdge/WasmEdge/blob/master/.github/workflows/build_for_riscv.yml) contains a dedicated `test_riscv64` job (separate from `cross_compile`) that downloads riscv64 build artifacts and executes the test suite under `qemu-riscv64-static` via `run-riscv64-quick-tests.sh`, confirming genuine test execution not just a build-only step. However, releases 0.17.1 through 0.18.0-alpha.1 publish no riscv64 binary assets -- only x86_64, aarch64, darwin, android, and Windows artifacts are shipped -- so no consumable upstream riscv64 release exists, blocking green. + + +WasmEdge + + +Mender.io - yellow (critical) +Release: debian +Gap: Upstream CI is GitLab-only (`.gitlab-ci.yml`, 173 lines confirmed) with no riscv64 job references and no GitHub Actions workflows; all runners use x86-64 container images. Debian sid ships `mender-client` 3.4.0+ds1-5+b15 for riscv64 ([packages.debian.org](https://packages.debian.org/sid/mender-client)) and Ubuntu 24.04 noble ships it as well ([packages.ubuntu.com](https://packages.ubuntu.com/search?keywords=mender-client&searchon=names&suite=noble&section=all)); all 3 Debian patches are general build/test environment adjustments with no riscv64-specific content ([sources.debian.org](https://sources.debian.org/patches/mender-client/3.4.0+ds1-5/)), confirming clean-distro-build at yellow. + + +Mender.io + + +SWUpdate - yellow (critical) +Release: ubuntu +Gap: Upstream CI ([ci_tests.yml](https://github.com/sbabic/swupdate/blob/master/.github/workflows/ci_tests.yml)) runs on `ubuntu-24.04` (amd64) only across three container variants; the workflow does execute `./ci/test-configs.sh` (real tests) but solely on amd64 -- no riscv64 jobs exist. Debian sid carries version `2026.05.1+dfsg-1` built successfully on `rv-osuosl-03`; Ubuntu ships riscv64 packages from Jammy through Stonking (26.04 Resolute: `2025.12+dfsg-4ubuntu1`). The Debian tracker lists 5 generic patches with no riscv64-specific entries, confirming a clean build from unmodified upstream source -- distribution floor applies: yellow (clean-distro-build). + + +SWUpdate + + +RAUC (Robust Auto-Update Controller) - yellow (optional) +Release: ubuntu +Gap: Upstream CI in [tests.yml](https://github.com/rauc/rauc/blob/master/.github/workflows/tests.yml) runs a cross-build-and-test matrix covering arm/v5, arm/v7, arm64/v8, and 386 only -- riscv64 is entirely absent (verified by reading the file directly). Ubuntu resolute (26.04) ships [rauc 1.15.1-1 for riscv64](https://packages.ubuntu.com/search?keywords=rauc&searchon=names&suite=resolute&section=all) built from unpatched upstream source; both Debian packaging patches (disable-network-tests, install-wrapper-to-pkgdatadir) are architecture-neutral, neither is riscv64-specific. This qualifies for the clean-distro-build yellow floor. + + +RAUC (Robust +Auto-Update +Controller) + + +Eclipse hawkBit - green (optional) +Release: none + + +Eclipse hawkBit + + +balenaCloud / balenaOS - orange (optional) +Release: none +Gap: The [docker-bake.hcl](https://github.com/balena-os/balena-engine/blob/release/v25.0/docker-bake.hcl) `_platforms` target (also confirmed on master) covers amd64, arm/v5/v6/v7, arm64, ppc64le, and s390x -- riscv64 is absent from every target group. The `ci.yml` cross-compile job and `test.yml` smoke job both derive their platform matrix from the same bake file, so no riscv64 CI job exists anywhere. No release assets, no distro packages, and no open issues or PRs requesting riscv64 support were found. + + +balenaCloud / +balenaOS + + +AWS IoT Greengrass v2 - orange (optional) +Release: none +Gap: The [maven.yml CI workflow](https://github.com/aws-greengrass/aws-greengrass-nucleus/blob/main/.github/workflows/maven.yml) targets only `ubuntu-latest` and `windows-latest` with no riscv64 build or test jobs. AWS official documentation explicitly lists supported Linux architectures as Armv7l, Armv8 (AArch64), and x86_64 only -- [RISC-V is absent](https://docs.aws.amazon.com/greengrass/v2/developerguide/greengrass-nucleus-component.html). GitHub releases carry no attached binary artifacts for any architecture (confirmed v2.18.3 and prior), and no confirmed riscv64 distribution package exists via any Linux distro or third party. The `color_case: downstream-only` from the proposed classification is unsupported: no downstream (distro or third-party) riscv64 package was found. The project is a JVM application with JNA native dependency; JNA 5.x ships linux-riscv64 natives that are NOT excluded by the pom.xml strip rules, so runtime is likely possible but is entirely untested and unsupported by AWS. + + +AWS IoT +Greengrass v2 + + +Azure IoT Edge - orange (optional) +Release: none +Gap: The official [Azure IoT Edge supported platforms page](https://learn.microsoft.com/en-us/azure/iot-edge/support) (updated 2026-07-16) lists only AMD64, ARM32v7, and ARM64 across Tier 1 and Tier 2; RISC-V is entirely absent. Live checks on 2026-08-29 confirmed: the GitHub repo contains only issue-labeler and stale CI workflows (no build/test CI); all three most recent releases (1.6.2, 1.6.1, 1.5.44) have zero release assets attached; Ubuntu 24.04 noble and Debian sid carry no iotedge package; and Microsoft's packages.microsoft.com has no riscv64 binary directory (HTTP 404). No downstream distro ships a riscv64 package either, making the proposed downstream-only sub-type a marginal fit -- the project simply has no riscv64 presence anywhere. + + +Azure IoT Edge + + +Red Hat Device Edge (MicroShift) - orange (optional) +Release: none + + +Red Hat Device +Edge (MicroShift) + + +Akri (Kubernetes device plugin) - orange (optional) +Release: none +Gap: The build-rust-containers.yml workflow confirms platforms `linux/amd64,linux/arm64,linux/arm/v7` only -- riscv64 is explicitly absent. The run-test-cases.yml e2e suite also runs only on ubuntu-latest (amd64), with no riscv64 runner or platform target. No Ubuntu Noble, Debian, or Arch RISC-V package for Akri was found, so no distribution floor exists. Zero riscv64-related issues or PRs exist in the repository, confirming no upstream work is in progress. Orange with no distribution floor is the correct classification; the `color_case: downstream-only` is retained as the closest applicable sub-type for no-upstream-CI orange, though strictly no distro ships Akri for riscv64 either. + + +Akri (Kubernetes +device plugin) + + +OSTree / rpm-ostree - yellow (optional) +Release: ubuntu +Gap: Upstream ostree CI ([tests.yml](https://github.com/ostreedev/ostree/blob/main/.github/workflows/tests.yml), [rust.yml](https://github.com/ostreedev/ostree/blob/main/.github/workflows/rust.yml)) runs exclusively on x86_64 GitHub-hosted runners with no riscv64 jobs, cross-compilation, or QEMU testing -- confirmed by reading the workflow files directly. Debian sid 2026.4-1 built successfully on native riscv64 hardware (rv-manda-02), and the sole patch in `debian/patches/` is a platform-agnostic bspatch security fix already accepted upstream (Applied-upstream: 2026.5) -- no riscv64-specific patches -- confirming a clean build from unmodified upstream source. Ubuntu noble (24.04) and resolute (26.04 LTS) both ship ostree for riscv64, setting the distro floor at yellow (clean-distro-build). + + +OSTree / +rpm-ostree + + +Uptane (automotive OTA standard) - green (optional) +Release: upstream +Gap: The [uptane/uptane-standard](https://github.com/uptane/uptane-standard) repository is a pure text specification rendered to HTML/PDF/TXT/XML/MD via Ruby (kramdown-rfc2629) and Python (xml2rfc) tooling in Docker; confirmed by reading the [Dockerfile](https://github.com/uptane/uptane-standard/blob/master/Dockerfile) and verifying the [2.1.0 release assets](https://github.com/uptane/uptane-standard/releases/tag/2.1.0) which contain only document files with no compiled or architecture-specific binaries. Step 0 of the color model applies: the project ships no compiled artifact, so riscv64 support is inherent -- any RISC-V ECU implementation can follow this standard. Upstream publishes the specification directly via GitHub Releases, satisfying the release_provider: upstream prerequisite for green. + +Uptane (automotive +OTA standard) + + +Prometheus - yellow (critical) +Release: upstream +Gap: Prometheus upstream publishes `prometheus-3.14.0.linux-riscv64.tar.gz` directly (confirmed live via GitHub Releases API). The `build_all` CI job in [`.github/workflows/ci.yml`](https://github.com/prometheus/prometheus/blob/main/.github/workflows/ci.yml) cross-compiles all architectures via `promu crossbuild` on `ubuntu-latest`, but no test job (`test_go`, `test_go_more`, `test_go_386`, or any other) runs with `GOARCH=riscv64` or on riscv64 hardware, confirming build-only CI with zero riscv64 test execution. The stored report (2026-06-17) and the live CI check agree exactly; no delta detected. + +Prometheus + + +Grafana - yellow (critical) +Release: none + + +Grafana + + +Fluent Bit - blue (critical) +Release: none +Gap: The [unit-tests.yaml](https://github.com/fluent/fluent-bit/blob/master/.github/workflows/unit-tests.yaml) `run-qemu-ubuntu-unit-tests` job includes `riscv64` in its matrix and its `run:` step executes `cmake`, `make`, and `ctest` under QEMU -- confirmed to be a full build-and-test job, not build-only. The master run from 2026-08-27 (ID 33097131056) shows `run-qemu-ubuntu-unit-tests (riscv64)` as `success` (the overall run failure is due to unrelated macOS jobs). No riscv64 target appears in [packaging/build-config.json](https://github.com/fluent/fluent-bit/blob/master/packaging/build-config.json) or the container image workflow, which covers only `amd64` and `arm64`, so no upstream riscv64 release artifact exists. + + +Fluent Bit + + +Telegraf - yellow (optional) +Release: none + + +Telegraf + + +OpenTelemetry Collector (edge) - yellow (optional) +Release: upstream +Gap: The `cross-build-collector` job in [build-and-test.yml](https://github.com/open-telemetry/opentelemetry-collector/blob/main/.github/workflows/build-and-test.yml) cross-compiles riscv64 on ubuntu-latest with a single `make otelcorecol` step and zero test execution; the `build-and-test-arm.yml` runs tests only on `ubuntu-22.04-arm` and `macos-14` (arm64), with no riscv64 runner anywhere. Upstream does ship riscv64 `.deb`, `.rpm`, and `.tar.gz` for otelcol, otelcol-contrib, otelcol-k8s, and otelcol-otlp in every release (confirmed in v0.159.0 via [collector-releases](https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.159.0)), but since CI tests are never executed on riscv64, the grade is capped at yellow (build-only-ci). + +OpenTelemetry +Collector (edge) + + +GDB / gdbserver - yellow (critical) +Release: none + + +GDB / gdbserver + + +OpenOCD - yellow (optional) +Release: ubuntu +Gap: The sole upstream CI workflow ([snapshot.yml](https://github.com/openocd-org/openocd/blob/master/.github/workflows/snapshot.yml)) cross-compiles only a Windows (i686-w64-mingw32) artifact; there is no riscv64 build or test job. Debian sid ships `openocd 0.12.0-3+b2` for riscv64 (built successfully on rv-osuosl-05), and all five Debian packaging patches address jimtcl, udev, and libgpiod compatibility -- none are riscv64-specific -- confirming the clean-distro-build floor applies. No upstream riscv64 release artifact exists; release_provider is the distro (Ubuntu/Debian). + + +OpenOCD + + +perf (Linux perf tools) - yellow (optional) +Release: upstream +Gap: The linux-riscv patchwork CI ([pw_ci.py](https://raw.githubusercontent.com/linux-riscv/linux/workflow/.github/scripts/pw_ci.py)) was read directly and confirmed to contain only compile-check jobs for riscv64 (`build-rv64-clang-allmodconfig`, `build-rv64-gcc-allmodconfig`, `build-rv64-nommu-k210-defconfig`, `build-rv64-nommu-k210-virt`) -- no test execution. Two additional workflows exist (`kselftest.yml`, `testsuites.yml`) that do run functional tests on riscv64, but both are gated on `endsWith(github.head_ref, '_manual')` or `startsWith(github.head_ref, 'linus')` and do not trigger automatically for patch submissions, and neither includes perf-specific functional tests. The two correctness bugs (PMU throttle IRQ storm, fixed counter stop) remain unmerged as of August 2026; a post-report resource-cleanup patch (`e24a141`, August 2026) merged but does not resolve either blocking bug. + +perf (Linux +perf tools) + + + +Embedded OS & RTOS + +Zephyr RTOS - green (critical) +Release: upstream +Gap: RISC-V is a first-class Zephyr target with test execution on riscv64 confirmed. The [hello_world_multiplatform.yaml](https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/workflows/hello_world_multiplatform.yaml) runs `west twister -p qemu_riscv64` on `ubuntu-24.04` without `--build-only`, and `qemu_riscv64.yaml` carries `testing: default: true` confirming QEMU test execution on every push/PR. The [Zephyr SDK v1.0.1](https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v1.0.1) ships upstream `riscv64-zephyr-elf` toolchain binaries for Linux (x86_64 and aarch64), macOS (aarch64), and Windows -- satisfying the upstream-release prerequisite for green. The `-M` flag in TWISTER_COMMON is `--runtime-artifact-cleanup`, not `--build-only`; weekly CI uses `--build-only` but PR and push runs do not. + +Zephyr RTOS + + +FreeRTOS - orange (critical) +Release: none +Gap: All CI workflow files in both FreeRTOS/FreeRTOS and FreeRTOS/FreeRTOS-Kernel were read directly; zero mentions of riscv, rv32, or rv64 appear in any of them - coverage is ARM, MSP430, MicroBlaze, WIN32, and POSIX only. The RISC-V port exists in-tree at portable/GCC/RISC-V/ with RV32/RV64 chip extensions and multiple QEMU demo directories, but none are wired into upstream CI. Upstream releases are source-only zip archives with no riscv64 binary artifacts, and no Linux distro packages this embedded RTOS - so the `downstream-only` color_case from the proposal is incorrect; orange derives here from the plain "no upstream RISC-V CI" baseline with no distro floor applicable. + + +FreeRTOS + + +RT-Thread - blue (optional) +Release: upstream +Gap: The [utest_auto_run.yml](https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/utest_auto_run.yml) CI workflow confirmed to contain three distinct steps for riscv64: Build BSP (cross-compile), QEMU Run Test (launches qemu-system-riscv64 with the built kernel), and Monitor qemu log (actively checks for test pass/fail signals and exits non-zero on failure). This covers standard, RT-Smart, and SMP variants across kernel, IPC, memory, and atomic test configs -- genuine test execution, not build-only. The [v5.2.0 release](https://github.com/RT-Thread/rt-thread/releases/tag/v5.2.0) ships only riscv64gc cross-toolchain tarballs for enabling user builds, not pre-built firmware images, so the release-provider criterion for green is not met; blue is correct. + +RT-Thread + + +Yocto Project - yellow (critical) +Release: none + + +Yocto Project + + +Buildroot - yellow (critical) +Release: none + + +Buildroot + + +Ubuntu Core - orange (optional) +Release: none + + +Ubuntu Core + + +Flatcar Container Linux - orange (optional) +Release: third-party +Gap: The upstream CI workflow at [flatcar/scripts/.github/workflows/ci.yaml](https://github.com/flatcar/scripts/blob/main/.github/workflows/ci.yaml) hard-codes `matrix: arch: ["amd64", "arm64"]`; no riscv64 job exists and all five most-recent upstream release tags (`stable-4593.2.5`, `alpha-4790.0.0`, etc.) carry zero riscv64 assets. A community contributor maintains a working QEMU PoC on a personal fork ([riscv-poc-07-jan-2025](https://github.com/ader1990/scripts/releases/tag/riscv-poc-07-jan-2025)) that has not been merged into mainline, as tracked by the open feature request [flatcar/Flatcar#1420](https://github.com/flatcar/Flatcar/issues/1420) (last updated 2025-02-13). + + +Flatcar +Container Linux + + +OpenWRT - yellow (optional) +Release: upstream +Gap: The shared CI workflow [multi-arch-test-build.yml](https://github.com/openwrt/actions-shared-workflows/blob/main/.github/workflows/multi-arch-test-build.yml) includes a `riscv64_generic` matrix entry targeting `sifiveu-generic` with `runtime_test: false`; all runtime test steps (QEMU registration, Docker container build, test execution) are explicitly gated on `matrix.runtime_test`, so they never run for riscv64 -- confirming build-only CI. Upstream does publish riscv64 release firmware for three targets (d1, sifiveu, starfive) in [v25.12.5](https://downloads.openwrt.org/releases/25.12.5/targets/), but the absence of test execution prevents green; yellow (build-only-ci) is the correct and verified color. + +OpenWRT + + +micro-ROS (RTOS layer for ROS 2) - yellow (optional) +Release: none +Gap: The [micro_ros_espidf_component CI](https://github.com/micro-ROS/micro_ros_espidf_component/blob/rolling/.github/workflows/ci.yml) is an upstream micro-ROS org repo that builds for esp32c3 (RV32IMC) and esp32c6 (RV32IMAC) in its matrix -- both are genuine RISC-V 32-bit cores -- making this build-only upstream CI rather than downstream-only. No test step (`idf.py test` or QEMU execution) exists anywhere for RISC-V, and the primary `micro_ros_arduino` repo targets only ARM and Xtensa boards. The proposed `downstream-only` (orange) sub-type was incorrect because upstream CI for RISC-V does exist in the espidf integration pathway; `build-only-ci` (yellow) is the right sub-type. + + +micro-ROS (RTOS +layer for ROS 2) + + +Security + +OP-TEE (Open Portable Trusted Execution Environment) - orange (optional) +Release: none + + +OP-TEE (Open Portable +Trusted Execution +Environment) + + +AppArmor - yellow (critical) +Release: debian +Gap: AppArmor's upstream GitLab CI (`master` branch `.gitlab-ci.yml`) contains no riscv64 jobs and is exclusively x86_64-targeted -- all spread/test jobs set `ARCH: x86_64` / `SPREAD_GOARCH: amd64` with no architecture matrix. However, Debian sid (4.1.8-1) builds successfully on riscv64 hardware (rv-osuosl-02, status "Installed") with no `debian/patches/` directory, confirming a clean build from unmodified upstream source; Ubuntu noble (24.04) also ships the `apparmor` package for riscv64. The proposed justification incorrectly cited "Ubuntu 26.04 (resolute)" -- the verified source is Ubuntu 24.04 (noble) and Debian unstable. + + +AppArmor + + +WireGuard - yellow (critical) +Release: none + + +WireGuard + + +SPIFFE / SPIRE - yellow (optional) +Release: none + + +SPIFFE / SPIRE + + +Falco - orange (optional) +Release: none +Gap: The [release.yaml](https://github.com/falcosecurity/falco/blob/master/.github/workflows/release.yaml) and [reusable_build_packages.yaml](https://github.com/falcosecurity/falco/blob/master/.github/workflows/reusable_build_packages.yaml) workflows accept only `x86_64` or `aarch64` as arch inputs; no riscv64 jobs appear anywhere in the CI. GitHub release assets across all published versions contain only `aarch64` and `x86_64` debug symbols; no riscv64 asset has ever been published. Ubuntu noble does not package falco, and no distro floor applies, confirming orange with no provider. + + +Falco + + +OpenSSL - blue (critical) +Release: ubuntu +Gap: OpenSSL upstream builds and tests riscv64 unconditionally via [cross-compiles.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/cross-compiles.yml) (full suite on push, EVP tests on PR, via QEMU) and conditionally via [riscv-more-cross-compiles.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/riscv-more-cross-compiles.yml) (13 extension-specific matrix entries). A native riscv64 self-hosted runner was added in [os-zoo.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/os-zoo.yml) (nightly/dispatch, with FIPS, merged 2026-08-07), upgrading the CI posture from QEMU-only to QEMU-plus-native-hardware. Upstream publishes source tarballs only; consumable riscv64 binaries are provided by Ubuntu, so blue (not green) applies. + + +OpenSSL + + +U-Boot (secure boot) - blue (critical) +Release: ubuntu +Gap: Upstream GitLab CI runs four riscv64 QEMU jobs (`qemu-riscv64`, `qemu-riscv64_spl`, `qemu-riscv64_smode`, `qemu-riscv64_smode_acpi`) invoking `test/py/test.py` with `TEST_PY_TEST_SPEC: "not sleep"`, none marked `allow_failure`, confirming riscv64 builds and general tests pass ([.gitlab-ci.yml](https://source.denx.de/u-boot/u-boot/-/raw/master/.gitlab-ci.yml)). The FIT image signing and verified boot tests (`test_vboot.py`, `test_fit.py`) are both decorated `@pytest.mark.boardspec('sandbox')` and run only on the sandbox board (amd64/arm64 host), so riscv64-specific verified boot CI coverage is absent -- though the underlying FIT signing code is architecture-independent. Upstream publishes source tarballs only; Ubuntu Noble ships `u-boot-sifive`, `u-boot-starfive`, and `u-boot-microchip` for riscv64 as the consumable release artifacts. + + +U-Boot (secure +boot) + + + +Federated Learning + +Flower (flwr) - green (optional) +Release: upstream +Gap: Flower ships exclusively as [py3-none-any wheels on PyPI](https://pypi.org/project/flwr/) (latest 1.35.0 on PyPI, 1.36.0 in main branch); the [framework/pyproject.toml](https://github.com/adap/flower/blob/main/framework/pyproject.toml) uses `uv-build` as the build backend with no ext_modules or any native compilation, confirmed by direct inspection. Under Step 0 of the color model, architecture-independent packages are classified green by construction -- no riscv64 CI is required or penalized. The `grpcio` runtime dependency has native wheels, but that is a separate classification concern and does not affect Flower's own artifact. + +Flower (flwr) + + +TensorFlow Federated (TFF) - orange (optional) +Release: none +Gap: The sole CI workflow ([publish.yaml](https://github.com/google-parfait/tensorflow-federated/blob/main/.github/workflows/publish.yaml)) runs exclusively on ubuntu-latest (x86_64), builds a manylinux_2_31_x86_64 wheel, and has no riscv64 build job, no QEMU, and no cross-compilation step. PyPI confirms that every release from v0.49.0 (Feb 2023) through v0.87.0 (latest) is published only as manylinux_2_31_x86_64; no riscv64 artifact exists from upstream, RISE, or any Linux distribution. Orange is correct; color_case downstream-only is applied because the orange tier requires no upstream CI, which holds -- though no downstream provider exists either, orange is still the right color since the project is simply absent from riscv64 with no known breakage evidence to trigger red. + + +TensorFlow +Federated (TFF) + + +Supporting +Infrastructure + +gRPC - orange (optional) +Release: RISE +Gap: No riscv64 CI exists in [grpc/grpc](https://github.com/grpc/grpc) -- confirmed by reading all six `.github/workflows/` files (a new `push_php_mirror.yml` was added since the report; it also has zero riscv64 references). Distro builds require riscv64-specific patches (system OpenSSL substitution, `-latomic` linkage fix), placing the distribution floor at orange rather than yellow. Upstream formally declined riscv64 wheel support when [issue #41591](https://github.com/grpc/grpc/issues/41591) was closed 2026-07-15 by maintainer sergiitk citing Google's OSS Support Policy which does not cover riscv64; RISE provides unofficial wheels at version 1.78.0 (updated from 1.76.0) via a non-default PyPI index, while PyPI official remains at 1.83.1 with zero riscv64 wheels. + + +gRPC + + +Protobuf - yellow (optional) +Release: ubuntu +Gap: Upstream CI has zero riscv64 references across all 10 active workflow files (confirmed live on main branch, 2026-08-29), and v36.0 ships no riscv64 protoc binary. Ubuntu 26.04 (plucky) ports archive ships libprotobuf-dev, protobuf-compiler, and python3-protobuf at v3.21.12-10build2 for riscv64; inspection of the debian tarball (protobuf_3.21.12-10ubuntu0.1.debian.tar.xz) confirms zero riscv64-specific patches, qualifying as a clean-distro-build and placing the floor at yellow. No open riscv64 correctness bugs exist and the library builds natively with a -latomic workaround, but the upstream maintainer has explicitly stated "RISC-V isn't on our roadmap" (PR [#23206](https://github.com/protocolbuffers/protobuf/pull/23206), August 2025). + + +Protobuf + + +HuggingFace Hub - green (optional) +Release: none + + +HuggingFace Hub + + +NumPy - yellow (optional) +Release: RISE +Gap: The upstream [`linux_riscv64.yml`](https://github.com/numpy/numpy/blob/main/.github/workflows/linux_riscv64.yml) workflow builds a manylinux wheel on RISE-provided native riscv64 hardware but contains no `CIBW_TEST_COMMAND` and no test step -- live-verified 2026-08-29; the only riscv64 test execution occurs in [`linux_qemu.yml`](https://github.com/numpy/numpy/blob/main/.github/workflows/linux_qemu.yml) under QEMU with `continue-on-error: true` at two points (lines 49 and 169), confirmed non-blocking. No upstream riscv64 PyPI wheels exist; consumable wheels are provided by RISE at version 2.5.2 (upgraded from 2.4.3 in the June 2026 report), and distro packages exist in Ubuntu 24.04 and Debian sid. The NPYV SIMD layer has no RVV backend so all vectorized arithmetic, transcendental, and reduction kernels fall back to scalar C, but the optimization-purpose modifier does not fire because NumPy's core value is its array-semantics API, not raw SIMD throughput. + + +NumPy + + +Hardware: RISC-V CPU (RVA23U64) + \ No newline at end of file diff --git a/stack-reports/edge-ai/edge-ai.yml b/stack-reports/edge-ai/edge-ai.yml new file mode 100644 index 000000000..615cea0f0 --- /dev/null +++ b/stack-reports/edge-ai/edge-ai.yml @@ -0,0 +1,778 @@ +title: "Edge AI" +target_profile: "RVA23U64" +hardware_label: "Hardware: RISC-V CPU (RVA23U64)" +columns: + - "Robotics" + - "Industrial IoT" + - "Automotive" + - "Smart Home" +product_layers: + - "Domain-Specific" +shared_layers: + - "ML Inference Runtimes" + - "Model Optimization & Conversion" + - "Kernel Libraries & Compute Primitives" + - "Data Pipeline & Local Processing" + - "Fleet Management, Orchestration, Observability, Debugging" + - "Embedded OS & RTOS" + - "Security" + - "Federated Learning" + - "Supporting Infrastructure" +legend: + - color: "green" + label: "upstream builds+tests+releases; optimized" + - color: "blue" + label: "upstream builds+tests; mostly optimized" + - color: "yellow" + label: "upstream builds; some optimized" + - color: "orange" + label: "no upstream build, distributions only; no optimizations" + - color: "red" + label: "not working" + - color: "grey" + label: "unknown or N/A" +nodes: + - name: "llama.cpp" + color: "blue" + criticality: "critical" + column: null + layer: "ML Inference Runtimes" + release_provider: "debian" + upstream_release: false + gap: "Native riscv64 CI on RISE-provided `ubuntu-24.04-riscv` runners builds with native gcc-14 and executes `ctest -L main` plus an end-to-end llama2c inference test on every push to master, confirmed live by reading [build-riscv.yml](https://github.com/ggerganov/llama.cpp/blob/master/.github/workflows/build-riscv.yml). Upstream publishes no riscv64 release binaries (PR [#20991](https://github.com/ggerganov/llama.cpp/pull/20991) remains open, issue [#20988](https://github.com/ggerganov/llama.cpp/issues/20988) was closed as not-planned); Debian 13 Trixie ships riscv64 packages `libllama0` and `libllama-dev`. The optimization modifier caps at blue (partial): quants.c has full RVV vec_dot coverage across all major formats (Q2_K through Q6_K, IQ1_S through IQ4_XS), but repack.cpp GEMM/GEMV tiled paths cover only Q4_0, Q4_K, Q2_K, Q8_0, and IQ4_NL -- Q3_K, Q5_K, and Q6_K tiled GEMM/GEMV paths are absent, leaving those formats at the vec_dot scalar-tiling fallback for batched matrix operations." + - name: "ONNX Runtime (edge / mobile EP)" + color: "yellow" + criticality: "critical" + column: null + layer: "ML Inference Runtimes" + release_provider: "debian" + upstream_release: false + gap: "No riscv64 CI exists in microsoft/onnxruntime: a live check on 2026-08-29 scanned all 51 GitHub Actions workflow files and found zero riscv64 hits, confirming the [project report](https://github.com/microsoft/onnxruntime). Debian sid ships a riscv64 binary (v1.23.2+dfsg) built from unpatched upstream source -- the `+dfsg` suffix denotes DFSG source stripping only, not riscv64-specific patches -- which lifts the floor to yellow (clean-distro-build). The optimization-purpose modifier for MLAS CPU EP rates coverage as partial (11 RVV intrinsics files covering SGEMM, INT8/FP16 GEMM, convolution, pooling, LayerNorm, RMSNorm, RoPE, activations; BF16 GEMM and FP16 RoPE are stubs), capping at blue -- which does not further constrain the yellow floor. No grounds to downgrade to orange: the report found no riscv64-specific patches in the Debian packaging, and upstream build support for riscv64 has existed since PR #19238 (January 2024)." + - name: "TensorFlow Lite / LiteRT" + color: "orange" + criticality: "critical" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "All 16 GitHub Actions workflow files (confirmed live 2026-08-29; 3 new files added since June 2026 report, all zero riscv64 references) contain no riscv64 jobs, no riscv64 wheel has ever appeared on PyPI, and LiteRT is absent from all Linux distro riscv64 repositories. As an optimization-purpose inference runtime whose primary value is accelerated CPU inference via XNNPACK, the optimization modifier caps at orange: Section 4 of [the project report](https://github.com/google-ai-edge/LiteRT/tree/main/tflite/kernels/internal/optimized) confirms 0 RVV files vs 4 NEON and 4 SSE files, with all RISC-V execution falling to scalar portable C. The blocking chain runs through [cpuinfo #124](https://github.com/pytorch/cpuinfo/issues/124) (still open, Zvfh detection missing) and [XNNPACK #9886](https://github.com/google/XNNPACK/issues/9886) (still open, 100+ RVV FP16 CI failures)." + - name: "TensorFlow Lite Micro (TFLM)" + color: "orange" + criticality: "optional" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "Upstream CI in [suite_riscv.yml](https://github.com/tensorflow/tflite-micro/blob/main/.github/workflows/suite_riscv.yml) and [merge_group.yml](https://github.com/tensorflow/tflite-micro/blob/main/.github/workflows/merge_group.yml) targets riscv32 MCU only (TARGET=riscv32_generic, arch rv32imc, QEMU riscv32) as confirmed by [test_riscv.sh](https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/tools/ci_build/test_riscv.sh); there is no riscv64 build target (only [riscv32_generic_makefile.inc](https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/tools/make/targets/riscv32_generic_makefile.inc) exists), no riscv64 CI, and no riscv64 release artifacts (PyPI wheels are x86_64-only, no GitHub releases). The project provides architecture-specific optimized kernels for Cortex-M/CMSIS-NN, Hexagon, and Xtensa but has zero riscv64-specific kernel code, leaving all riscv64 paths as scalar C fallback; combined with no riscv64 CI and no distro packaging, this caps at orange (optimization-absent)." + - name: "ExecuTorch" + color: "yellow" + criticality: "critical" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "" + - name: "ncnn" + color: "blue" + criticality: "critical" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "ncnn has dedicated [linux-riscv64 CI](https://github.com/Tencent/ncnn/blob/master/.github/workflows/linux-riscv64.yml) with explicit `ctest` test steps on riscv64 via QEMU (gcc-riscv64, gcc-rvv vlen=128/256, clang-rvv vlen=128/256) plus self-hosted XuanTie and SpacemiT jobs, all confirmed to run the full test suite and not merely build. The [src/layer/riscv/](https://github.com/Tencent/ncnn/tree/master/src/layer/riscv) directory contains 180 files covering all primary hot paths (convolution, GEMM, depthwise, pooling, attention, normalization) with RVV intrinsics and ZFH/ZVFH fp16 -- full optimization coverage. The [20260526 release](https://github.com/Tencent/ncnn/releases/tag/20260526) has no standalone Linux riscv64 prebuilt, only Android bundles, so blue (not green) is correct." + - name: "MNN (Alibaba)" + color: "orange" + criticality: "optional" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "No riscv64 CI exists in any workflow: linux.yml, mnn_release.yml, pymnn_linux.yml, and android.yml all run exclusively on ubuntu-latest (x86_64), confirmed by reading [.github/workflows/linux.yml](https://github.com/alibaba/MNN/blob/master/.github/workflows/linux.yml) and [mnn_release.yml](https://github.com/alibaba/MNN/blob/master/.github/workflows/mnn_release.yml). Release artifacts cover android/arm, iOS, Linux-x64, macOS, and Windows only -- no riscv64 binary in any of the three most recent releases (3.6.1, 3.6.0, 3.5.0). The proposed color_case of downstream-only is incorrect: Alibaba's MNN is not packaged by Ubuntu, Debian, or Arch Linux RISC-V for any architecture, so there is no downstream either; orange is correct but solely because no upstream CI exists -- the 93 RVV source files under source/backend/cpu/riscv/rvv/ (covering matmul, INT8 GEMM, attention, depthwise conv, activations) are untested by CI." + - name: "PaddlePaddle Lite" + color: "orange" + criticality: "optional" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "The only CI file is a lint-only `.travis.yml` (no build or test jobs); no `.github/workflows` directory exists. The [lite/kernels directory](https://github.com/PaddlePaddle/Paddle-Lite/tree/develop/lite/kernels) contains backends for arm, host, metal, nnadapter, opencl, x86, and xpu but no riscv backend, and a full-repo code search returns zero hits for \"riscv\". Release assets through v2.14-rc cover only arm, x86, iOS, and macOS -- no riscv64 artifact. As an optimization-purpose inference runtime with absent RISC-V optimization (all paths fall back to generic scalar via the \"host\" backend), the grade is capped at orange." + - name: "MindSpore Lite (Huawei)" + color: "orange" + criticality: "optional" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "The active development repository is `mindspore-ai/mindspore-lite` (last pushed 2026-08-29), not the archived monorepo cited in the proposal. It has a cross-compilation build path for rv64 (`MSLITE_CROSS_RISCV=rv64`) and an `rvv/` kernel directory; `adderfloat_rvv.c` contains genuine RVV intrinsics (vsetvl, vle32, vfsub, vfadd, etc.) for element-wise activation ops, but `matmul_rvv.c` -- the critical hot path -- uses scalar C only despite being in the rvv/ directory. No upstream CI builds or tests riscv64 (Jenkins-only lint checks; no GitHub Actions), no riscv64 release artifacts exist, and the primary optimization value (matrix multiplication for inference) has no real RVV implementation, so the optimization-absent cap at orange applies and the no-CI base color of orange is confirmed. See [mindspore-ai/mindspore-lite rvv directory](https://github.com/mindspore-ai/mindspore-lite/tree/master/mindspore-lite/src/litert/kernel/cpu/nnacl_c/intrinsics/rvv)." + - name: "OpenVINO Runtime" + color: "yellow" + criticality: "critical" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Apache TVM / microTVM" + color: "orange" + criticality: "optional" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "No upstream riscv64 CI exists: the cpu_jenkinsfile defines `ci_riscv = ''` as an empty placeholder and no corresponding Docker image is in [docker-images.ini](https://github.com/apache/tvm/blob/main/ci/jenkins/docker-images.ini) (confirmed live 2026-08-29); no riscv64 wheel is published on PyPI (latest 0.26.0 covers x86_64, aarch64, macOS arm64, Windows only); no Linux distribution packages TVM for riscv64. The proposed `optimization-absent` color_case is incorrect: TVM has RISC-V-specific optimizations in [riscv_cpu.py](https://github.com/apache/tvm/blob/main/python/tvm/s_tir/tensor_intrin/riscv_cpu.py) (241-line RVV dot-product kernel intrinsics using `rvv_vec_dot_product_kernels`) and SiFive/SpacemiT CPU target tags -- but coverage is minimal (dot-product only; no RISC-V-specific dlight GEMV/GEMM schedule rules comparable to arm64 SME/NEON), which would cap at yellow under the optimization modifier -- a cap that has no effect since the primary grade is already orange from absent CI." + - name: "whisper.cpp" + color: "blue" + criticality: "optional" + column: null + layer: "ML Inference Runtimes" + release_provider: "none" + upstream_release: false + gap: "" + - name: "ONNX (format + tooling)" + color: "yellow" + criticality: "critical" + column: null + layer: "Model Optimization & Conversion" + release_provider: "RISE" + upstream_release: false + gap: "Upstream CI ([release_linux_cibw.yml](https://github.com/onnx/onnx/blob/main/.github/workflows/release_linux_cibw.yml)) covers only x86_64 and aarch64 with no riscv64 job, and no riscv64 wheel is published to PyPI by upstream. Ubuntu resolute (26.04) ships `python3-onnx` 1.20.0-1 and `libonnx-dev` 1.20.0-1 for riscv64 with only generic packaging patches (cmake-no-rpath, fix-shebang, soversion -- no architecture-specific patches), qualifying as a clean distro build and triggering the yellow distribution floor. RISE additionally provides current `onnx-1.22.0-cp312-abi3-manylinux_2_39_riscv64.whl` wheels covering v1.19.1 through v1.22.0; ONNX is a protobuf schema and tooling library with no architecture-specific compute kernels, so the optimization modifier does not apply." + - name: "Intel Neural Compressor (INC)" + color: "green" + criticality: "optional" + column: null + layer: "Model Optimization & Conversion" + release_provider: "upstream" + upstream_release: true + gap: "Intel Neural Compressor v3.9 ships as [neural_compressor-3.9-py3-none-any.whl](https://pypi.org/pypi/neural-compressor/3.9/json) with `ext_modules=[]` unconditionally in setup.py and zero C/C++/Cython/CUDA files in the repository tree, making it architecture-independent pure Python that runs on riscv64 by construction (Step 0 shortcut). The wheel is published directly to PyPI by the Intel AIPT team (suyue.chen@intel.com), so release_provider is upstream. INC is a Python orchestration layer for quantization workflows that delegates compute to PyTorch/TF/JAX backends, so the optimization-purpose modifier (Step 2) does not apply." + - name: "NNCF (Neural Network Compression Framework, Intel)" + color: "orange" + criticality: "optional" + column: null + layer: "Model Optimization & Conversion" + release_provider: "upstream" + upstream_release: true + gap: "Although the PyPI artifact is a `py3-none-any` wheel, NNCF ships C++/CUDA source files under `src/nncf/torch/extensions/` that are JIT-compiled at runtime via `torch.utils.cpp_extension.load()` with `ninja` as a hard dependency ([pyproject.toml](https://github.com/openvinotoolkit/nncf/blob/develop/pyproject.toml), [extensions.py](https://github.com/openvinotoolkit/nncf/blob/develop/src/nncf/torch/quantization/extensions.py)); this disqualifies the Step 0 \"architecture-independent\" shortcut. All CI workflows run exclusively on `ubuntu-latest` (x86_64) or GPU runners -- no riscv64 build or test job exists -- placing this at orange under Step 1 (no upstream riscv64 CI). The CPU extension does have a graceful Python fallback on compile failure, but the project has never been tested on riscv64 and no distro floor has been established." + - name: "HuggingFace Optimum" + color: "green" + criticality: "optional" + column: null + layer: "Model Optimization & Conversion" + release_provider: "upstream" + upstream_release: true + gap: "HuggingFace Optimum ships exclusively as a `py3-none-any` wheel (confirmed for the latest release [optimum 2.3.0](https://pypi.org/pypi/optimum/2.3.0/json)). A scan of the full repository tree confirms zero compiled source files (.c, .cpp, .rs, etc.) and `setup.py` declares no `ext_modules`, making the package architecture-independent. Step 0 applies: green by construction, no riscv64 CI required or penalized for absence." + - name: "XNNPACK" + color: "yellow" + criticality: "critical" + column: null + layer: "Kernel Libraries & Compute Primitives" + release_provider: "none" + upstream_release: false + gap: "" + - name: "OpenBLAS" + color: "blue" + criticality: "critical" + column: null + layer: "Kernel Libraries & Compute Primitives" + release_provider: "debian" + upstream_release: false + gap: "Upstream [riscv64_vector.yml](https://github.com/OpenMathLib/OpenBLAS/blob/develop/.github/workflows/riscv64_vector.yml) builds and runs the full BLAS L1/L2/L3 test suite under QEMU for ZVL128B, ZVL256B, and DYNAMIC_ARCH on every push/PR, confirming blue CI posture (tests pass, no upstream riscv64 binary release - only Windows and source tarballs in GitHub releases). The optimization modifier is partial: GEMM and GEMV have full RVV 1.0 coverage for all precisions; TRSM gained RVV kernels via [PR #5830](https://github.com/OpenMathLib/OpenBLAS/pull/5830) (merged 2026-08-16) giving STRSM full RVV coverage, but DTRSM LN/LT, CTRSM LN/LT, and ZTRSM LN/LT/RN still fall back to generic C on both ZVL128B and ZVL256B targets. Partial optimization caps at blue, matching the CI grade." + - name: "SLEEF" + color: "blue" + criticality: "critical" + column: null + layer: "Kernel Libraries & Compute Primitives" + release_provider: "debian" + upstream_release: false + gap: "The Jenkinsfile at shibatch/sleef has two riscv64 stages on `riscv && ubuntu24` agents that run `ctest` with `-DSLEEF_ENFORCE_TESTER4=True -DSLEEF_ENFORCE_RVVM1=True -DSLEEF_ENFORCE_RVVM2=True`; TLFloat-based tester4 accuracy tests execute for all transcendentals -- confirmed genuine test execution, not build-only ([Jenkinsfile](https://github.com/shibatch/sleef/blob/master/Jenkinsfile)). The RVV backend in `src/arch/helperrvv.h` (1407 lines of RVV intrinsics) covers all SP and DP transcendentals for RVVM1 and RVVM2, delivering full optimization coverage with no downward cap. Upstream GitHub releases are source-only (no binary assets for any arch); Debian sid ships `libsleef3` 3.9.0-1 for riscv64 from unpatched upstream source (no riscv64-specific patches in debian/patches/, confirmed via [sources.debian.org](https://sources.debian.org/src/sleef/3.9.0-1/debian/patches/))." + - name: "ARM Compute Library (ACL) [ARM Only]" + color: "grey" + criticality: "optional" + column: null + layer: "Kernel Libraries & Compute Primitives" + release_provider: "none" + upstream_release: false + gap: "ARM Compute Library is by design exclusive to Arm architectures: the README explicitly states it is \"optimized for Arm Cortex-A, Neoverse, and Mali GPU architectures,\" CMakeLists.txt only supports armv8-a/armv8.2-a/armv8.6-a targets, and a full GitHub code search returns zero files referencing riscv. All upstream releases (confirmed through v53.2.0) are exclusively aarch64 and armv7a binaries with no riscv64 variant. The project-graph confirms no riscv64 distro package exists. RISC-V is not applicable by design." + - name: "RUY (Google matrix multiply)" + color: "orange" + criticality: "optional" + column: null + layer: "Kernel Libraries & Compute Primitives" + release_provider: "ubuntu" + upstream_release: false + gap: "Adversarial verification confirms the proposed color. No .github/workflows directory exists (404 from GitHub API), confirming zero upstream CI for any architecture. Ubuntu 26.04 (resolute) and Ubuntu 24.04 (noble) both ship libruy-dev for riscv64 (confirmed via project graph: version 0.0.0~git20230215.21a85fe-3, suite resolute, arch riscv64); the single Debian packaging patch (Remove_cxx14_compat.patch) removes a generic -Wc++14-compat warning flag from CMakeLists.txt for all architectures and is not riscv64-specific, so the clean-distro-build yellow floor applies. Ruy is an optimization-purpose library (SIMD matmul) with zero RISC-V-specific code -- no RUY_PLATFORM_RISCV macro, no RVV kernel, no riscv64 path enum entry (confirmed live in platform.h and path.h) -- so the absent-optimization cap lowers yellow to orange." + - name: "FlatBuffers" + color: "yellow" + criticality: "critical" + column: null + layer: "Kernel Libraries & Compute Primitives" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream [google/flatbuffers](https://github.com/google/flatbuffers) has no riscv64 CI in any of its six workflow files -- confirmed by live check of [build.yml](https://github.com/google/flatbuffers/blob/master/.github/workflows/build.yml) (no riscv64, QEMU, or cross-compile references). Ubuntu 26.04 (resolute) ships `libflatbuffers-dev`, `libflatbuffers23.5.26`, `flatbuffers-compiler`, and `flatbuffers-compiler-dev` at 23.5.26+dfsg-4build1 for riscv64 (confirmed via project-graph); the three Debian packaging patches (`8201.patch` for mips/hppa NaN, `s390x.patch` for GCC warning suppression, `setup-py.patch`) are none of them riscv64-specific, confirming a clean unpatched upstream build on riscv64. FlatBuffers is architecture-agnostic (no SIMD, no assembly), so no optimization gap exists." + - name: "OpenCV" + color: "blue" + criticality: "critical" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "ubuntu" + upstream_release: false + gap: "The `OCV-PR-5.x-RISCV.yaml` workflow in the `opencv/ci-gha-workflow` repo defines a `BuildAndTest` job that cross-compiles with RVV enabled and then executes three accuracy test suites (core, imgproc, dnn) under QEMU; the nightly `OCV-Nightly-RISCV.yaml` runs the same suites on real RISC-V boards (`lichee1`, `canmv1`). Upstream publishes no riscv64 release artifact (the 5.0.0 release ships only Android, iOS, Windows, and docs), but Ubuntu ships `python3-opencv` for riscv64 from noble (24.04 LTS) onward at version 4.10.0, placing release_provider at ubuntu. OpenCV also has a broad RVV HAL under `hal/riscv-rvv/` covering core, imgproc, dnn, and features2d hot paths, giving a partial-to-full optimization level that does not cap below blue." + - name: "GStreamer" + color: "yellow" + criticality: "critical" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "ubuntu" + upstream_release: false + gap: "GStreamer's own monorepo has no riscv64 CI job of any kind (confirmed live against the [GitHub mirror CI config](https://raw.githubusercontent.com/GStreamer/gstreamer/main/.gitlab-ci.yml) on 2026-08-29). The distribution floor applies: Ubuntu 26.04 \"Resolute\" ships libgstreamer1.0-0 1.28.2-1 and a full plugin set for riscv64 (confirmed via project graph and [packages.ubuntu.com/resolute/libgstreamer1.0-0](https://packages.ubuntu.com/resolute/libgstreamer1.0-0)), with no riscv64-specific patches in the Debian packaging diff. ORC (GStreamer's SIMD layer) gained a native riscv64 CI job with meson test execution on 2026-08-05 -- a meaningful positive signal for the dependency stack -- but GStreamer's own grade is driven by its own CI posture, not ORC's." + - name: "MediaPipe" + color: "orange" + criticality: "optional" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "none" + upstream_release: false + gap: "The only CI workflow in google/mediapipe is `stale.yaml` (issue management); there is no build or test CI for any architecture. PyPI lists wheels only for x86_64 and aarch64/arm64 across all versions including v1.0.1 -- no riscv64 wheel has ever been published ([PyPI JSON](https://pypi.org/pypi/mediapipe/json)). A code search for \"riscv64\" across the entire repository returns zero results, and no Linux distribution (Debian, Ubuntu Noble, Arch RISC-V) packages mediapipe for riscv64. The proposed `color_case: downstream-only` was incorrect: that sub-type requires a downstream distro to be shipping the package, which is not the case here; plain orange (no CI, no distro coverage) is the correct classification." + - name: "Mosquitto (Eclipse)" + color: "yellow" + criticality: "critical" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Node-RED" + color: "green" + criticality: "optional" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "upstream" + upstream_release: true + gap: "Node-RED is effectively architecture-independent: it ships no compiled code of its own (no gypfile, no cpu/os fields), and its sole native optionalDependency (`@node-rs/bcrypt` 1.10.7) has an explicit try/catch fallback to the pure-JS `bcryptjs` in [`packages/node_modules/@node-red/editor-api/lib/auth/users.js`](https://github.com/node-red/node-red/blob/main/packages/node_modules/%40node-red/editor-api/lib/auth/users.js), so the absence of a riscv64 prebuilt for `@node-rs/bcrypt` does not affect functionality. Upstream publishes releases directly to npm (latest: v5.0.4), and the Step 0 architecture-independent shortcut applies -- no riscv64 CI is required for this grade. The proposed justification claiming \"all 57 dependencies are pure JavaScript\" was slightly inaccurate (one optional native dep exists) but the green conclusion stands because full functionality is preserved on riscv64 via the pure-JS fallback." + - name: "InfluxDB (edge / v1.x)" + color: "yellow" + criticality: "optional" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "none" + upstream_release: false + gap: "" + - name: "SQLite" + color: "yellow" + criticality: "critical" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "ubuntu" + upstream_release: false + gap: "SQLite has no upstream CI of any kind -- the GitHub mirror's `.github/` directory returns HTTP 404, confirmed live. No upstream riscv64 artifact is published (official downloads provide Linux x64 only). Ubuntu 24.04 and Debian sid (3.53.4-2, \"Installed\" on rv-manda-01) both ship sqlite3 for riscv64 from unpatched upstream source: the Debian packaging contains 11 patches, none riscv64-specific (the two cross-compilation patches are generic fixes applicable to all target architectures). The optimization-purpose modifier does not apply -- SQLite is pure portable C with no SIMD, no assembly, and no JIT on any architecture." + - name: "V4L2 (Video4Linux2)" + color: "yellow" + criticality: "critical" + column: null + layer: "Data Pipeline & Local Processing" + release_provider: "Debian" + upstream_release: false + gap: "The proposed green color and `release_provider: upstream` cannot be sustained. Upstream (kernel.org for V4L2-in-kernel, linuxtv.org for v4l-utils) publishes source tarballs only - no riscv64 binary artifacts - so the release_provider is the distro, not upstream, which precludes green. The Debian buildd confirms v4l-utils 1.32.0-5 builds successfully on riscv64 with only a documentation patch (`dont-gererate-treeview.diff`, not riscv64-specific), qualifying as a clean distro build. Upstream CI for riscv64 testing could not be confirmed (linuxtv.org v4l-utils CI is Anubis-blocked and no riscv64 test evidence was found), so the floor is yellow/clean-distro-build per the color model." + - name: "k3s (Rancher)" + color: "orange" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "All 20 workflow files on main contain zero riscv64 build or test jobs -- the single `riscv64` mention in [build-k3s.yaml](https://github.com/k3s-io/k3s/blob/master/.github/workflows/build-k3s.yaml) is only a runner-selection conditional, not a build target. The [latest release v1.36.4+k3s1](https://github.com/k3s-io/k3s/releases/tag/v1.36.4%2Bk3s1) (2026-08-27) ships only amd64, arm64, and armhf binaries. Draft [PR #13854](https://github.com/k3s-io/k3s/pull/13854) proposing riscv64 e2e CI (on RISE runners) remains unmerged and was last updated 2026-04-28; a second open PR [#14529](https://github.com/k3s-io/k3s/pull/14529) fixing a seccomp issue in riscv64 builds confirms external development interest but is also unmerged." + - name: "k0s" + color: "blue" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The nightly riscv64.yml workflow (merged via PR #7414 on 2026-06-19) runs three confirmed test-execution steps on native RISE RISC-V hardware (Scaleway EM-RV1): unit tests via `make check-unit` in unittests-k0s.yml, and two integration smoke tests (basic, airgap) via `make -C inttest` in smoketest.yaml -- this is genuine test execution, not build-only CI, confirming blue over yellow. However, the latest upstream release (v1.36.3+k0s.2, 2026-08-12) contains zero riscv64 assets, no distro ships a riscv64 k0s binary, and the workflow has no pull_request trigger so riscv64 is not a merge gate, ruling out green and confirming blue." + - name: "KubeEdge" + color: "orange" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "KubeEdge upstream CI covers only amd64, arm64, and arm/v7 -- confirmed by the [release workflow](https://github.com/kubeedge/kubeedge/blob/master/.github/workflows/release.yml) and the [v1.23.1 release assets](https://github.com/kubeedge/kubeedge/releases/tag/v1.23.1) (published 2026-07-15), which contain no riscv64 binary. The sole riscv64 cross-build attempt ([PR #3904](https://github.com/kubeedge/kubeedge/pull/3904)) was closed stale and unmerged in September 2022 and no further riscv64 PRs or issues exist. No Linux distribution (Ubuntu noble, Debian, Fedora) ships a riscv64 KubeEdge package, so the distribution floor does not apply; orange reflects the absence of any upstream or downstream riscv64 support." + - name: "containerd" + color: "yellow" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "upstream" + upstream_release: true + gap: "Upstream containerd publishes a first-class `linux/riscv64` tarball with every release (confirmed in [v2.3.4](https://github.com/containerd/containerd/releases/tag/v2.3.4): `containerd-2.3.4-linux-riscv64.tar.gz` and static variant). The [ci.yml](https://github.com/containerd/containerd/blob/main/.github/workflows/ci.yml) `integration-linux` job matrix targets only `ubuntu-22.04`, `ubuntu-24.04`, and `ubuntu-24.04-arm` -- no riscv64 runner is present. [PR #13124](https://github.com/containerd/containerd/pull/13124), which would add riscv64 to the test matrix via RISE runners, remains open and unmerged (merged_at: null, last updated 2026-08-08). The [nightly.yml](https://github.com/containerd/containerd/blob/main/.github/workflows/nightly.yml) cross-compiles riscv64 with `make binaries` only -- no test execution step. Yellow (build-only-ci) is confirmed; proposed color cannot be refuted." + - name: "crun" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "upstream" + upstream_release: true + gap: "The [test.yaml](https://github.com/containers/crun/blob/main/.github/workflows/test.yaml) `build_job` matrix includes a `riscv64` entry that uses `uraimo/run-on-arch-action` to run `./autogen.sh`, `./configure`, and `make ... crun` inside QEMU -- no `make check` or test execution of any kind. The companion `Test` job (which carries `check`, `check-no-openat2`, `podman`, `containerd`, and a dozen other test variants) runs exclusively on `ubuntu-latest` (amd64) with no riscv64 entry. Upstream publishes signed riscv64 release binaries directly (e.g. `crun-1.29.1-linux-riscv64`) via [release.yaml](https://github.com/containers/crun/blob/main/.github/workflows/release.yaml) cross-build, confirming `release_provider: upstream`; but build-only CI caps the grade at yellow." + - name: "WasmEdge" + color: "blue" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The upstream CI workflow [build_for_riscv.yml](https://github.com/WasmEdge/WasmEdge/blob/master/.github/workflows/build_for_riscv.yml) contains a dedicated `test_riscv64` job (separate from `cross_compile`) that downloads riscv64 build artifacts and executes the test suite under `qemu-riscv64-static` via `run-riscv64-quick-tests.sh`, confirming genuine test execution not just a build-only step. However, releases 0.17.1 through 0.18.0-alpha.1 publish no riscv64 binary assets -- only x86_64, aarch64, darwin, android, and Windows artifacts are shipped -- so no consumable upstream riscv64 release exists, blocking green." + - name: "Mender.io" + color: "yellow" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "debian" + upstream_release: false + gap: "Upstream CI is GitLab-only (`.gitlab-ci.yml`, 173 lines confirmed) with no riscv64 job references and no GitHub Actions workflows; all runners use x86-64 container images. Debian sid ships `mender-client` 3.4.0+ds1-5+b15 for riscv64 ([packages.debian.org](https://packages.debian.org/sid/mender-client)) and Ubuntu 24.04 noble ships it as well ([packages.ubuntu.com](https://packages.ubuntu.com/search?keywords=mender-client&searchon=names&suite=noble§ion=all)); all 3 Debian patches are general build/test environment adjustments with no riscv64-specific content ([sources.debian.org](https://sources.debian.org/patches/mender-client/3.4.0+ds1-5/)), confirming clean-distro-build at yellow." + - name: "SWUpdate" + color: "yellow" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream CI ([ci_tests.yml](https://github.com/sbabic/swupdate/blob/master/.github/workflows/ci_tests.yml)) runs on `ubuntu-24.04` (amd64) only across three container variants; the workflow does execute `./ci/test-configs.sh` (real tests) but solely on amd64 -- no riscv64 jobs exist. Debian sid carries version `2026.05.1+dfsg-1` built successfully on `rv-osuosl-03`; Ubuntu ships riscv64 packages from Jammy through Stonking (26.04 Resolute: `2025.12+dfsg-4ubuntu1`). The Debian tracker lists 5 generic patches with no riscv64-specific entries, confirming a clean build from unmodified upstream source -- distribution floor applies: yellow (clean-distro-build)." + - name: "RAUC (Robust Auto-Update Controller)" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream CI in [tests.yml](https://github.com/rauc/rauc/blob/master/.github/workflows/tests.yml) runs a cross-build-and-test matrix covering arm/v5, arm/v7, arm64/v8, and 386 only -- riscv64 is entirely absent (verified by reading the file directly). Ubuntu resolute (26.04) ships [rauc 1.15.1-1 for riscv64](https://packages.ubuntu.com/search?keywords=rauc&searchon=names&suite=resolute§ion=all) built from unpatched upstream source; both Debian packaging patches (disable-network-tests, install-wrapper-to-pkgdatadir) are architecture-neutral, neither is riscv64-specific. This qualifies for the clean-distro-build yellow floor." + - name: "Eclipse hawkBit" + color: "green" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "" + - name: "balenaCloud / balenaOS" + color: "orange" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The [docker-bake.hcl](https://github.com/balena-os/balena-engine/blob/release/v25.0/docker-bake.hcl) `_platforms` target (also confirmed on master) covers amd64, arm/v5/v6/v7, arm64, ppc64le, and s390x -- riscv64 is absent from every target group. The `ci.yml` cross-compile job and `test.yml` smoke job both derive their platform matrix from the same bake file, so no riscv64 CI job exists anywhere. No release assets, no distro packages, and no open issues or PRs requesting riscv64 support were found." + - name: "AWS IoT Greengrass v2" + color: "orange" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The [maven.yml CI workflow](https://github.com/aws-greengrass/aws-greengrass-nucleus/blob/main/.github/workflows/maven.yml) targets only `ubuntu-latest` and `windows-latest` with no riscv64 build or test jobs. AWS official documentation explicitly lists supported Linux architectures as Armv7l, Armv8 (AArch64), and x86_64 only -- [RISC-V is absent](https://docs.aws.amazon.com/greengrass/v2/developerguide/greengrass-nucleus-component.html). GitHub releases carry no attached binary artifacts for any architecture (confirmed v2.18.3 and prior), and no confirmed riscv64 distribution package exists via any Linux distro or third party. The `color_case: downstream-only` from the proposed classification is unsupported: no downstream (distro or third-party) riscv64 package was found. The project is a JVM application with JNA native dependency; JNA 5.x ships linux-riscv64 natives that are NOT excluded by the pom.xml strip rules, so runtime is likely possible but is entirely untested and unsupported by AWS." + - name: "Azure IoT Edge" + color: "orange" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The official [Azure IoT Edge supported platforms page](https://learn.microsoft.com/en-us/azure/iot-edge/support) (updated 2026-07-16) lists only AMD64, ARM32v7, and ARM64 across Tier 1 and Tier 2; RISC-V is entirely absent. Live checks on 2026-08-29 confirmed: the GitHub repo contains only issue-labeler and stale CI workflows (no build/test CI); all three most recent releases (1.6.2, 1.6.1, 1.5.44) have zero release assets attached; Ubuntu 24.04 noble and Debian sid carry no iotedge package; and Microsoft's packages.microsoft.com has no riscv64 binary directory (HTTP 404). No downstream distro ships a riscv64 package either, making the proposed downstream-only sub-type a marginal fit -- the project simply has no riscv64 presence anywhere." + - name: "Red Hat Device Edge (MicroShift)" + color: "orange" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Akri (Kubernetes device plugin)" + color: "orange" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The build-rust-containers.yml workflow confirms platforms `linux/amd64,linux/arm64,linux/arm/v7` only -- riscv64 is explicitly absent. The run-test-cases.yml e2e suite also runs only on ubuntu-latest (amd64), with no riscv64 runner or platform target. No Ubuntu Noble, Debian, or Arch RISC-V package for Akri was found, so no distribution floor exists. Zero riscv64-related issues or PRs exist in the repository, confirming no upstream work is in progress. Orange with no distribution floor is the correct classification; the `color_case: downstream-only` is retained as the closest applicable sub-type for no-upstream-CI orange, though strictly no distro ships Akri for riscv64 either." + - name: "OSTree / rpm-ostree" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream ostree CI ([tests.yml](https://github.com/ostreedev/ostree/blob/main/.github/workflows/tests.yml), [rust.yml](https://github.com/ostreedev/ostree/blob/main/.github/workflows/rust.yml)) runs exclusively on x86_64 GitHub-hosted runners with no riscv64 jobs, cross-compilation, or QEMU testing -- confirmed by reading the workflow files directly. Debian sid 2026.4-1 built successfully on native riscv64 hardware (rv-manda-02), and the sole patch in `debian/patches/` is a platform-agnostic bspatch security fix already accepted upstream (Applied-upstream: 2026.5) -- no riscv64-specific patches -- confirming a clean build from unmodified upstream source. Ubuntu noble (24.04) and resolute (26.04 LTS) both ship ostree for riscv64, setting the distro floor at yellow (clean-distro-build)." + - name: "Uptane (automotive OTA standard)" + color: "green" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "upstream" + upstream_release: true + gap: "The [uptane/uptane-standard](https://github.com/uptane/uptane-standard) repository is a pure text specification rendered to HTML/PDF/TXT/XML/MD via Ruby (kramdown-rfc2629) and Python (xml2rfc) tooling in Docker; confirmed by reading the [Dockerfile](https://github.com/uptane/uptane-standard/blob/master/Dockerfile) and verifying the [2.1.0 release assets](https://github.com/uptane/uptane-standard/releases/tag/2.1.0) which contain only document files with no compiled or architecture-specific binaries. Step 0 of the color model applies: the project ships no compiled artifact, so riscv64 support is inherent -- any RISC-V ECU implementation can follow this standard. Upstream publishes the specification directly via GitHub Releases, satisfying the release_provider: upstream prerequisite for green." + - name: "Prometheus" + color: "yellow" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "upstream" + upstream_release: true + gap: "Prometheus upstream publishes `prometheus-3.14.0.linux-riscv64.tar.gz` directly (confirmed live via GitHub Releases API). The `build_all` CI job in [`.github/workflows/ci.yml`](https://github.com/prometheus/prometheus/blob/main/.github/workflows/ci.yml) cross-compiles all architectures via `promu crossbuild` on `ubuntu-latest`, but no test job (`test_go`, `test_go_more`, `test_go_386`, or any other) runs with `GOARCH=riscv64` or on riscv64 hardware, confirming build-only CI with zero riscv64 test execution. The stored report (2026-06-17) and the live CI check agree exactly; no delta detected." + - name: "Grafana" + color: "yellow" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Fluent Bit" + color: "blue" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "The [unit-tests.yaml](https://github.com/fluent/fluent-bit/blob/master/.github/workflows/unit-tests.yaml) `run-qemu-ubuntu-unit-tests` job includes `riscv64` in its matrix and its `run:` step executes `cmake`, `make`, and `ctest` under QEMU -- confirmed to be a full build-and-test job, not build-only. The master run from 2026-08-27 (ID 33097131056) shows `run-qemu-ubuntu-unit-tests (riscv64)` as `success` (the overall run failure is due to unrelated macOS jobs). No riscv64 target appears in [packaging/build-config.json](https://github.com/fluent/fluent-bit/blob/master/packaging/build-config.json) or the container image workflow, which covers only `amd64` and `arm64`, so no upstream riscv64 release artifact exists." + - name: "Telegraf" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "" + - name: "OpenTelemetry Collector (edge)" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "upstream" + upstream_release: true + gap: "The `cross-build-collector` job in [build-and-test.yml](https://github.com/open-telemetry/opentelemetry-collector/blob/main/.github/workflows/build-and-test.yml) cross-compiles riscv64 on ubuntu-latest with a single `make otelcorecol` step and zero test execution; the `build-and-test-arm.yml` runs tests only on `ubuntu-22.04-arm` and `macos-14` (arm64), with no riscv64 runner anywhere. Upstream does ship riscv64 `.deb`, `.rpm`, and `.tar.gz` for otelcol, otelcol-contrib, otelcol-k8s, and otelcol-otlp in every release (confirmed in v0.159.0 via [collector-releases](https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.159.0)), but since CI tests are never executed on riscv64, the grade is capped at yellow (build-only-ci)." + - name: "GDB / gdbserver" + color: "yellow" + criticality: "critical" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "none" + upstream_release: false + gap: "" + - name: "OpenOCD" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "ubuntu" + upstream_release: false + gap: "The sole upstream CI workflow ([snapshot.yml](https://github.com/openocd-org/openocd/blob/master/.github/workflows/snapshot.yml)) cross-compiles only a Windows (i686-w64-mingw32) artifact; there is no riscv64 build or test job. Debian sid ships `openocd 0.12.0-3+b2` for riscv64 (built successfully on rv-osuosl-05), and all five Debian packaging patches address jimtcl, udev, and libgpiod compatibility -- none are riscv64-specific -- confirming the clean-distro-build floor applies. No upstream riscv64 release artifact exists; release_provider is the distro (Ubuntu/Debian)." + - name: "perf (Linux perf tools)" + color: "yellow" + criticality: "optional" + column: null + layer: "Fleet Management, Orchestration, Observability, Debugging" + release_provider: "upstream" + upstream_release: true + gap: "The linux-riscv patchwork CI ([pw_ci.py](https://raw.githubusercontent.com/linux-riscv/linux/workflow/.github/scripts/pw_ci.py)) was read directly and confirmed to contain only compile-check jobs for riscv64 (`build-rv64-clang-allmodconfig`, `build-rv64-gcc-allmodconfig`, `build-rv64-nommu-k210-defconfig`, `build-rv64-nommu-k210-virt`) -- no test execution. Two additional workflows exist (`kselftest.yml`, `testsuites.yml`) that do run functional tests on riscv64, but both are gated on `endsWith(github.head_ref, '_manual')` or `startsWith(github.head_ref, 'linus')` and do not trigger automatically for patch submissions, and neither includes perf-specific functional tests. The two correctness bugs (PMU throttle IRQ storm, fixed counter stop) remain unmerged as of August 2026; a post-report resource-cleanup patch (`e24a141`, August 2026) merged but does not resolve either blocking bug." + - name: "Zephyr RTOS" + color: "green" + criticality: "critical" + column: null + layer: "Embedded OS & RTOS" + release_provider: "upstream" + upstream_release: true + gap: "RISC-V is a first-class Zephyr target with test execution on riscv64 confirmed. The [hello_world_multiplatform.yaml](https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/workflows/hello_world_multiplatform.yaml) runs `west twister -p qemu_riscv64` on `ubuntu-24.04` without `--build-only`, and `qemu_riscv64.yaml` carries `testing: default: true` confirming QEMU test execution on every push/PR. The [Zephyr SDK v1.0.1](https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v1.0.1) ships upstream `riscv64-zephyr-elf` toolchain binaries for Linux (x86_64 and aarch64), macOS (aarch64), and Windows -- satisfying the upstream-release prerequisite for green. The `-M` flag in TWISTER_COMMON is `--runtime-artifact-cleanup`, not `--build-only`; weekly CI uses `--build-only` but PR and push runs do not." + - name: "FreeRTOS" + color: "orange" + criticality: "critical" + column: null + layer: "Embedded OS & RTOS" + release_provider: "none" + upstream_release: false + gap: "All CI workflow files in both FreeRTOS/FreeRTOS and FreeRTOS/FreeRTOS-Kernel were read directly; zero mentions of riscv, rv32, or rv64 appear in any of them - coverage is ARM, MSP430, MicroBlaze, WIN32, and POSIX only. The RISC-V port exists in-tree at portable/GCC/RISC-V/ with RV32/RV64 chip extensions and multiple QEMU demo directories, but none are wired into upstream CI. Upstream releases are source-only zip archives with no riscv64 binary artifacts, and no Linux distro packages this embedded RTOS - so the `downstream-only` color_case from the proposal is incorrect; orange derives here from the plain \"no upstream RISC-V CI\" baseline with no distro floor applicable." + - name: "RT-Thread" + color: "blue" + criticality: "optional" + column: null + layer: "Embedded OS & RTOS" + release_provider: "upstream" + upstream_release: true + gap: "The [utest_auto_run.yml](https://github.com/RT-Thread/rt-thread/blob/master/.github/workflows/utest_auto_run.yml) CI workflow confirmed to contain three distinct steps for riscv64: Build BSP (cross-compile), QEMU Run Test (launches qemu-system-riscv64 with the built kernel), and Monitor qemu log (actively checks for test pass/fail signals and exits non-zero on failure). This covers standard, RT-Smart, and SMP variants across kernel, IPC, memory, and atomic test configs -- genuine test execution, not build-only. The [v5.2.0 release](https://github.com/RT-Thread/rt-thread/releases/tag/v5.2.0) ships only riscv64gc cross-toolchain tarballs for enabling user builds, not pre-built firmware images, so the release-provider criterion for green is not met; blue is correct." + - name: "Yocto Project" + color: "yellow" + criticality: "critical" + column: null + layer: "Embedded OS & RTOS" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Buildroot" + color: "yellow" + criticality: "critical" + column: null + layer: "Embedded OS & RTOS" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Ubuntu Core" + color: "orange" + criticality: "optional" + column: null + layer: "Embedded OS & RTOS" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Flatcar Container Linux" + color: "orange" + criticality: "optional" + column: null + layer: "Embedded OS & RTOS" + release_provider: "third-party" + upstream_release: false + gap: "The upstream CI workflow at [flatcar/scripts/.github/workflows/ci.yaml](https://github.com/flatcar/scripts/blob/main/.github/workflows/ci.yaml) hard-codes `matrix: arch: [\"amd64\", \"arm64\"]`; no riscv64 job exists and all five most-recent upstream release tags (`stable-4593.2.5`, `alpha-4790.0.0`, etc.) carry zero riscv64 assets. A community contributor maintains a working QEMU PoC on a personal fork ([riscv-poc-07-jan-2025](https://github.com/ader1990/scripts/releases/tag/riscv-poc-07-jan-2025)) that has not been merged into mainline, as tracked by the open feature request [flatcar/Flatcar#1420](https://github.com/flatcar/Flatcar/issues/1420) (last updated 2025-02-13)." + - name: "OpenWRT" + color: "yellow" + criticality: "optional" + column: null + layer: "Embedded OS & RTOS" + release_provider: "upstream" + upstream_release: true + gap: "The shared CI workflow [multi-arch-test-build.yml](https://github.com/openwrt/actions-shared-workflows/blob/main/.github/workflows/multi-arch-test-build.yml) includes a `riscv64_generic` matrix entry targeting `sifiveu-generic` with `runtime_test: false`; all runtime test steps (QEMU registration, Docker container build, test execution) are explicitly gated on `matrix.runtime_test`, so they never run for riscv64 -- confirming build-only CI. Upstream does publish riscv64 release firmware for three targets (d1, sifiveu, starfive) in [v25.12.5](https://downloads.openwrt.org/releases/25.12.5/targets/), but the absence of test execution prevents green; yellow (build-only-ci) is the correct and verified color." + - name: "micro-ROS (RTOS layer for ROS 2)" + color: "yellow" + criticality: "optional" + column: null + layer: "Embedded OS & RTOS" + release_provider: "none" + upstream_release: false + gap: "The [micro_ros_espidf_component CI](https://github.com/micro-ROS/micro_ros_espidf_component/blob/rolling/.github/workflows/ci.yml) is an upstream micro-ROS org repo that builds for esp32c3 (RV32IMC) and esp32c6 (RV32IMAC) in its matrix -- both are genuine RISC-V 32-bit cores -- making this build-only upstream CI rather than downstream-only. No test step (`idf.py test` or QEMU execution) exists anywhere for RISC-V, and the primary `micro_ros_arduino` repo targets only ARM and Xtensa boards. The proposed `downstream-only` (orange) sub-type was incorrect because upstream CI for RISC-V does exist in the espidf integration pathway; `build-only-ci` (yellow) is the right sub-type." + - name: "OP-TEE (Open Portable Trusted Execution Environment)" + color: "orange" + criticality: "optional" + column: null + layer: "Security" + release_provider: "none" + upstream_release: false + gap: "" + - name: "AppArmor" + color: "yellow" + criticality: "critical" + column: null + layer: "Security" + release_provider: "debian" + upstream_release: false + gap: "AppArmor's upstream GitLab CI (`master` branch `.gitlab-ci.yml`) contains no riscv64 jobs and is exclusively x86_64-targeted -- all spread/test jobs set `ARCH: x86_64` / `SPREAD_GOARCH: amd64` with no architecture matrix. However, Debian sid (4.1.8-1) builds successfully on riscv64 hardware (rv-osuosl-02, status \"Installed\") with no `debian/patches/` directory, confirming a clean build from unmodified upstream source; Ubuntu noble (24.04) also ships the `apparmor` package for riscv64. The proposed justification incorrectly cited \"Ubuntu 26.04 (resolute)\" -- the verified source is Ubuntu 24.04 (noble) and Debian unstable." + - name: "WireGuard" + color: "yellow" + criticality: "critical" + column: null + layer: "Security" + release_provider: "none" + upstream_release: false + gap: "" + - name: "SPIFFE / SPIRE" + color: "yellow" + criticality: "optional" + column: null + layer: "Security" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Falco" + color: "orange" + criticality: "optional" + column: null + layer: "Security" + release_provider: "none" + upstream_release: false + gap: "The [release.yaml](https://github.com/falcosecurity/falco/blob/master/.github/workflows/release.yaml) and [reusable_build_packages.yaml](https://github.com/falcosecurity/falco/blob/master/.github/workflows/reusable_build_packages.yaml) workflows accept only `x86_64` or `aarch64` as arch inputs; no riscv64 jobs appear anywhere in the CI. GitHub release assets across all published versions contain only `aarch64` and `x86_64` debug symbols; no riscv64 asset has ever been published. Ubuntu noble does not package falco, and no distro floor applies, confirming orange with no provider." + - name: "OpenSSL" + color: "blue" + criticality: "critical" + column: null + layer: "Security" + release_provider: "ubuntu" + upstream_release: false + gap: "OpenSSL upstream builds and tests riscv64 unconditionally via [cross-compiles.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/cross-compiles.yml) (full suite on push, EVP tests on PR, via QEMU) and conditionally via [riscv-more-cross-compiles.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/riscv-more-cross-compiles.yml) (13 extension-specific matrix entries). A native riscv64 self-hosted runner was added in [os-zoo.yml](https://github.com/openssl/openssl/blob/master/.github/workflows/os-zoo.yml) (nightly/dispatch, with FIPS, merged 2026-08-07), upgrading the CI posture from QEMU-only to QEMU-plus-native-hardware. Upstream publishes source tarballs only; consumable riscv64 binaries are provided by Ubuntu, so blue (not green) applies." + - name: "U-Boot (secure boot)" + color: "blue" + criticality: "critical" + column: null + layer: "Security" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream GitLab CI runs four riscv64 QEMU jobs (`qemu-riscv64`, `qemu-riscv64_spl`, `qemu-riscv64_smode`, `qemu-riscv64_smode_acpi`) invoking `test/py/test.py` with `TEST_PY_TEST_SPEC: \"not sleep\"`, none marked `allow_failure`, confirming riscv64 builds and general tests pass ([.gitlab-ci.yml](https://source.denx.de/u-boot/u-boot/-/raw/master/.gitlab-ci.yml)). The FIT image signing and verified boot tests (`test_vboot.py`, `test_fit.py`) are both decorated `@pytest.mark.boardspec('sandbox')` and run only on the sandbox board (amd64/arm64 host), so riscv64-specific verified boot CI coverage is absent -- though the underlying FIT signing code is architecture-independent. Upstream publishes source tarballs only; Ubuntu Noble ships `u-boot-sifive`, `u-boot-starfive`, and `u-boot-microchip` for riscv64 as the consumable release artifacts." + - name: "ROS 2 (Robot Operating System 2)" + color: "yellow" + criticality: "critical" + column: "Robotics" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "" + - name: "Nav2 (Navigation 2)" + color: "yellow" + criticality: "optional" + column: "Robotics" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "" + - name: "MoveIt 2" + color: "yellow" + criticality: "optional" + column: "Robotics" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "" + - name: "FastDDS (eProsima)" + color: "yellow" + criticality: "critical" + column: "Robotics" + layer: "Domain-Specific" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream CI runs exclusively on ubuntu-24.04 (x86_64) with no riscv64 jobs in any workflow (confirmed in [ubuntu-ci.yml](https://github.com/eProsima/Fast-DDS/blob/master/.github/workflows/ubuntu-ci.yml) and [nightly-ubuntu-master.yml](https://github.com/eProsima/Fast-DDS/blob/master/.github/workflows/nightly-ubuntu-master.yml), both delegating to a reusable workflow that only targets `linux_gcc_64`). Ubuntu Resolute (26.04) and Debian Sid ship `libfastdds3.3`, `libfastdds-dev`, and `fastdds-tools` for riscv64; all 17 Debian patches are general build fixes (docs, system-library substitutions, GCC-15 fix, CMake fixes) with none targeting riscv64 specifically, confirmed by reading the full patch list via [sources.debian.org](https://sources.debian.org/src/fastdds/3.3.0+ds-3/debian/patches/), and Debian riscv64 autopkgtest reports Pass per the [Debian tracker](https://tracker.debian.org/pkg/fastdds). This clean distro build without upstream CI yields yellow (clean-distro-build)." + - name: "CycloneDDS (Eclipse)" + color: "yellow" + criticality: "optional" + column: "Robotics" + layer: "Domain-Specific" + release_provider: "ubuntu" + upstream_release: false + gap: "All five CI workflow files (linux.yml, cxx_bindings.yml, macos.yml, python_bindings.yml, windows.yml) contain zero riscv64 references; jobs run on ubuntu-22.04 and ubuntu-24.04 x86_64 runners only ([linux.yml](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/.github/workflows/linux.yml)). Ubuntu resolute (26.04) ships cyclonedds-dev 0.10.5-1build1 for riscv64 ([packages.ubuntu.com](https://packages.ubuntu.com/search?keywords=cyclonedds&searchon=names&suite=resolute§ion=all)). All seven Debian packaging patches were individually inspected: none target riscv64 (patch 0005 fixes big-endian architectures which does not affect little-endian riscv64, patch 0004 targets GNU/Hurd), confirming a clean build from unmodified upstream source and supporting the yellow clean-distro-build classification." + - name: "Iceoryx (Eclipse)" + color: "yellow" + criticality: "optional" + column: "Robotics" + layer: "Domain-Specific" + release_provider: "debian" + upstream_release: false + gap: "Upstream CI ([build-test.yml](https://github.com/eclipse-iceoryx/iceoryx/blob/main/.github/workflows/build-test.yml), nightly.yml) covers only ubuntu-24.04 (x86_64), Windows, FreeBSD -- zero riscv64 jobs. Debian \"resolute\" ships 13 riscv64 binary packages at 2.0.6+dfsg-2 (project graph) and 2.0.8+dfsg-1 successfully built on rv-osuosl-01 (buildd.debian.org). The 8 Debian patches include two un-forwarded items (0007 libatomic INTERFACE linkage, 0008 time_t type fix) that are generic Linux/portability fixes with no riscv64-specific target; the \"clean-distro-build\" floor applies. Release provider is Debian, not Ubuntu: the project graph URI base is debian/resolute, correcting the proposed ubuntu attribution." + - name: "open62541 (OPC UA)" + color: "yellow" + criticality: "critical" + column: "Industrial IoT" + layer: "Domain-Specific" + release_provider: "debian" + upstream_release: false + gap: "Upstream CI ([build_linux.yml](https://github.com/open62541/open62541/blob/master/.github/workflows/build_linux.yml)) runs exclusively on x86_64 Ubuntu runners with no riscv64 job and no riscv64 binary release artifacts. Debian sid ships open62541 1.4.18-1 for riscv64 with a \"Installed\" build status; the single Debian patch (`hardened_ns0.diff`) is architecture-agnostic, confirming a clean build from unmodified upstream C99 source. Ubuntu questing (26.04) carries the same library at 1.4.11.1-1 for riscv64, consistent with the distribution floor of yellow/clean-distro-build." + - name: "Eclipse Ditto" + color: "green" + criticality: "optional" + column: "Industrial IoT" + layer: "Domain-Specific" + release_provider: "upstream" + upstream_release: true + gap: "Eclipse Ditto is 100% pure Java with no compiled native code or JNI dependencies (confirmed by inspecting the BOM pom.xml and Maven Central artifact classifiers): every released JAR is a platform-neutral `.jar` with no architecture-specific classifier, triggering Step 0 of the color model. Step 0 assigns green directly for architecture-independent projects; the absence of riscv64 Docker images is irrelevant because the deployable JARs are architecture-neutral and upstream publishes them to Maven Central for the current release (3.9.6 available at [Maven Central](https://repo1.maven.org/maven2/org/eclipse/ditto/ditto-messages-model/3.9.6/)). The proposed blue was incorrect: blue requires upstream CI that builds and tests on riscv64, of which there is none; and blue also cannot be assigned when Step 0 applies." + - name: "FIWARE Orion Context Broker" + color: "orange" + criticality: "optional" + column: "Industrial IoT" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "All CI workflows ([unit.yml](https://github.com/telefonicaid/fiware-orion/blob/master/.github/workflows/unit.yml), [functional.yml](https://github.com/telefonicaid/fiware-orion/blob/master/.github/workflows/functional.yml)) run exclusively on ubuntu-22.04 x86_64 with no riscv64 jobs. No riscv64 package exists in Ubuntu Noble, Debian, or Arch RISC-V, and DockerHub confirms all published image tags are linux/amd64 only -- there is no downstream channel shipping a riscv64 artifact, making the proposed color_case \"downstream-only\" factually incorrect. With no positive evidence of either working or broken status on riscv64, the correct classification is grey (unknown-unknown), not orange downstream-only." + - name: "EMQX" + color: "orange" + criticality: "optional" + column: "Industrial IoT" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "Live verification of [build_matrix.py](https://raw.githubusercontent.com/emqx/emqx/master/scripts/rel/build_matrix.py) confirms `LINUX_ARCH = [\"amd64\", \"arm64\"]` with no riscv64 entry. The [test workflow](https://raw.githubusercontent.com/emqx/emqx/master/.github/workflows/run_test_cases.yaml) runs exclusively on `aws-ubuntu22.04-amd64` runners. GitHub releases (6.2.2) and Docker Hub tags ship only linux/amd64 and linux/arm64 -- no riscv64 artifact or platform exists anywhere in the release pipeline. No Ubuntu/Debian package for emqx was found, so no distribution floor applies; this is a clean no-CI, no-distro, no-release situation." + - name: "AUTOSAR Adaptive Platform" + color: "grey" + criticality: "critical" + column: "Automotive" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "AUTOSAR Adaptive Platform is a proprietary specification (current release R25-11) with no public source repository, no CI system, and no open-source reference implementation. Live checks of the [primary AUTOSAR page](https://www.autosar.org/standards/adaptive-platform/) and all known commercial implementations (Elektrobit EB corbos AdaptiveCore targeting NXP/NVIDIA/Renesas/TI, Apex.AI Apex.OS) show zero mention of RISC-V. GitHub search returns no repositories combining AUTOSAR Adaptive with RISC-V. No distro package exists. The spec is POSIX-based and not inherently incompatible with RISC-V, but no confirmed support and no confirmed breakage exist -- a genuine unknown-unknown." + - name: "Autoware (ROS 2-based AV stack)" + color: "orange" + criticality: "optional" + column: "Automotive" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "All CI workflows enumerate exactly `amd64` and `arm64` as targets; the reusable workflow [docker-build.yaml](https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/docker-build.yaml) declares its `platform` input as `\"amd64 or arm64\"` with no riscv64 path, and the calling workflow [docker-build-and-push.yaml](https://github.com/autowarefoundation/autoware/blob/main/.github/workflows/docker-build-and-push.yaml) instantiates only `humble-amd64`, `humble-arm64`, `jazzy-amd64`, `jazzy-arm64` jobs. A code search across the entire repository returns zero results for \"riscv64\", no RISC-V issues or PRs exist, and the latest release v1.9.0 (2026-07-16) carries no binary assets of any kind. The `downstream-only` sub-type is retained as the closest match for \"no upstream CI, no riscv64 path\" though no confirmed downstream distro package exists either." + - name: "Eclipse Zenoh" + color: "orange" + criticality: "optional" + column: "Automotive" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "The [build-crates-standalone.yml](https://github.com/eclipse-zenoh/ci/blob/main/.github/workflows/build-crates-standalone.yml) matrix used for all releases covers x86_64, arm, armv7, and aarch64 only -- riscv64 is absent. The [1.10.0 release assets](https://github.com/eclipse-zenoh/zenoh/releases/tag/1.10.0) confirm no riscv64 binary is published. Ubuntu noble, Debian, Fedora, and Arch RISC-V carry no zenoh package, so no distribution floor applies at all; `color_case: downstream-only` from the proposed classification is incorrect because no downstream ships it either. The color stays orange but with no sub-type." + - name: "Home Assistant" + color: "yellow" + criticality: "optional" + column: "Smart Home" + layer: "Domain-Specific" + release_provider: "RISE" + upstream_release: false + gap: "The proposed green was refuted on two grounds. First, Step 0 does not apply: although the `homeassistant` wheel is `py3-none-any`, its mandatory (non-optional) compiled dependencies `orjson==3.12.0` (Rust) and `ciso8601==2.3.3` (C extension) have no upstream riscv64 wheels on PyPI -- installation on riscv64 fails without the RISE extra index ([RISE orjson riscv64 index](https://gitlab.com/api/v4/projects/56254198/packages/pypi/simple/orjson/)). Second, upstream CI (builder.yml, ci.yaml) targets only `[\"amd64\", \"aarch64\"]` with zero riscv64 build or test jobs, so the release_provider cannot be upstream. RISE provides riscv64 wheels for both orjson (3.11.9 and 3.12.0) and ciso8601 (2.3.3), enabling installation from unmodified upstream source -- this matches the clean-distro-build distribution floor, yielding yellow." + - name: "OpenThread" + color: "orange" + criticality: "optional" + column: "Smart Home" + layer: "Domain-Specific" + release_provider: "third-party" + upstream_release: false + gap: "All five CI workflows (build.yml, unit.yml, simulation.yml, posix.yml, docker.yml) run exclusively on ubuntu-24.04/22.04 x86_64 runners and ARM bare-metal toolchains; docker.yml covers linux/amd64 and linux/arm64 only with no linux/riscv64 platform entry. The Thread networking stack is absent from Debian and Ubuntu packages (the \"openthread\" packages in those distros are OpenThreads, an unrelated threading library). RISC-V MCU support exists only via Espressif's downstream fork in ESP-IDF, which its own sbom.yml describes as \"Espressif fork of OpenThread project, used to maintain ESP-specific patches\" -- third-party, downstream, and not reflected in any upstream CI or platform example." + - name: "Matter / chip-tool (Project CHIP)" + color: "orange" + criticality: "optional" + column: "Smart Home" + layer: "Domain-Specific" + release_provider: "none" + upstream_release: false + gap: "Live checks on all CI workflows confirm zero Linux riscv64 host build or test jobs: the host builder ([scripts/build/builders/host.py](https://github.com/project-chip/connectedhomeip/blob/master/scripts/build/builders/host.py)) enumerates only x64, arm64, and armhf targets. All riscv64 references in the codebase are for bare-metal MCU toolchains (riscv64-unknown-elf- for Bouffalo Lab and Telink/Zephyr) or Android riscv64, not Linux riscv64 host. No riscv64 chip-tool packages were found in Ubuntu, Debian, Fedora, or Arch RISC-V, and GitHub releases contain no riscv64 artifacts - so there is no downstream providing riscv64 support either." + - name: "Flower (flwr)" + color: "green" + criticality: "optional" + column: null + layer: "Federated Learning" + release_provider: "upstream" + upstream_release: true + gap: "Flower ships exclusively as [py3-none-any wheels on PyPI](https://pypi.org/project/flwr/) (latest 1.35.0 on PyPI, 1.36.0 in main branch); the [framework/pyproject.toml](https://github.com/adap/flower/blob/main/framework/pyproject.toml) uses `uv-build` as the build backend with no ext_modules or any native compilation, confirmed by direct inspection. Under Step 0 of the color model, architecture-independent packages are classified green by construction -- no riscv64 CI is required or penalized. The `grpcio` runtime dependency has native wheels, but that is a separate classification concern and does not affect Flower's own artifact." + - name: "TensorFlow Federated (TFF)" + color: "orange" + criticality: "optional" + column: null + layer: "Federated Learning" + release_provider: "none" + upstream_release: false + gap: "The sole CI workflow ([publish.yaml](https://github.com/google-parfait/tensorflow-federated/blob/main/.github/workflows/publish.yaml)) runs exclusively on ubuntu-latest (x86_64), builds a manylinux_2_31_x86_64 wheel, and has no riscv64 build job, no QEMU, and no cross-compilation step. PyPI confirms that every release from v0.49.0 (Feb 2023) through v0.87.0 (latest) is published only as manylinux_2_31_x86_64; no riscv64 artifact exists from upstream, RISE, or any Linux distribution. Orange is correct; color_case downstream-only is applied because the orange tier requires no upstream CI, which holds -- though no downstream provider exists either, orange is still the right color since the project is simply absent from riscv64 with no known breakage evidence to trigger red." + - name: "gRPC" + color: "orange" + criticality: "optional" + column: null + layer: "Supporting Infrastructure" + release_provider: "RISE" + upstream_release: false + gap: "No riscv64 CI exists in [grpc/grpc](https://github.com/grpc/grpc) -- confirmed by reading all six `.github/workflows/` files (a new `push_php_mirror.yml` was added since the report; it also has zero riscv64 references). Distro builds require riscv64-specific patches (system OpenSSL substitution, `-latomic` linkage fix), placing the distribution floor at orange rather than yellow. Upstream formally declined riscv64 wheel support when [issue #41591](https://github.com/grpc/grpc/issues/41591) was closed 2026-07-15 by maintainer sergiitk citing Google's OSS Support Policy which does not cover riscv64; RISE provides unofficial wheels at version 1.78.0 (updated from 1.76.0) via a non-default PyPI index, while PyPI official remains at 1.83.1 with zero riscv64 wheels." + - name: "Protobuf" + color: "yellow" + criticality: "optional" + column: null + layer: "Supporting Infrastructure" + release_provider: "ubuntu" + upstream_release: false + gap: "Upstream CI has zero riscv64 references across all 10 active workflow files (confirmed live on main branch, 2026-08-29), and v36.0 ships no riscv64 protoc binary. Ubuntu 26.04 (plucky) ports archive ships libprotobuf-dev, protobuf-compiler, and python3-protobuf at v3.21.12-10build2 for riscv64; inspection of the debian tarball (protobuf_3.21.12-10ubuntu0.1.debian.tar.xz) confirms zero riscv64-specific patches, qualifying as a clean-distro-build and placing the floor at yellow. No open riscv64 correctness bugs exist and the library builds natively with a -latomic workaround, but the upstream maintainer has explicitly stated \"RISC-V isn't on our roadmap\" (PR [#23206](https://github.com/protocolbuffers/protobuf/pull/23206), August 2025)." + - name: "HuggingFace Hub" + color: "green" + criticality: "optional" + column: null + layer: "Supporting Infrastructure" + release_provider: "none" + upstream_release: false + gap: "" + - name: "NumPy" + color: "yellow" + criticality: "optional" + column: null + layer: "Supporting Infrastructure" + release_provider: "RISE" + upstream_release: false + gap: "The upstream [`linux_riscv64.yml`](https://github.com/numpy/numpy/blob/main/.github/workflows/linux_riscv64.yml) workflow builds a manylinux wheel on RISE-provided native riscv64 hardware but contains no `CIBW_TEST_COMMAND` and no test step -- live-verified 2026-08-29; the only riscv64 test execution occurs in [`linux_qemu.yml`](https://github.com/numpy/numpy/blob/main/.github/workflows/linux_qemu.yml) under QEMU with `continue-on-error: true` at two points (lines 49 and 169), confirmed non-blocking. No upstream riscv64 PyPI wheels exist; consumable wheels are provided by RISE at version 2.5.2 (upgraded from 2.4.3 in the June 2026 report), and distro packages exist in Ubuntu 24.04 and Debian sid. The NPYV SIMD layer has no RVV backend so all vectorized arithmetic, transcendental, and reduction kernels fall back to scalar C, but the optimization-purpose modifier does not fire because NumPy's core value is its array-semantics API, not raw SIMD throughput."