DC-ROMA AI PC - RISC-V Mainboard II

[geerlingguy]

Basic information

• Board URL (official): https://store.deepcomputing.io/products/dc-roma-ai-pc-risc-v-mainboard-ii-for-framework-laptop-13
• Board purchased from: Provided for review, by DeepComputing
• Board purchase date: 2025-10-09
• Board specs (as tested): 32GB RAM (16GB for CPU), 512GB SSD, 8-core 1.8 GHz SiFive P550 CPU
• Board price (as tested): $899 (standalone Mainboard starts at $349 for 32GB/No SSD)

Linux/system information

# output of `screenfetch`
$ screenfetch
                          ./+o+-       roma@roma
                  yyyyy- -yyyyyy+      OS: Ubuntu 24.04 noble
               ://+//////-yyyyyyo      Kernel: riscv64 Linux 6.6.92-eic7x-2025.07
           .++ .:/++++++/-.+sss/`      Uptime: 9m
         .:++o:  /++++++++/:--:/-      Packages: 1954
        o:+o+:++.`..```.-/oo+++++/     Shell: bash 5.2.21
       .:+o:+o/.          `+sssoo+/    Disk: 25G / 468G (6%)
  .++/+:+oo+o:`             /sssooo.   CPU: Unknown @ 8x 1.8GHz
 /+++//+:`oo+o               /::--:.   GPU: 
 \+/+o+++`o++o               ++////.   RAM: 1529MiB / 14682MiB
  .++.o+++oo+:`             /dddhhh.  
       .+.o+oo:.          `oddhhhh+   
        \+.++o+o``-````.:ohdhhhhh+    
         `:o+++ `ohhhhhhhhyo++os:     
           .o:`.syhhhhhhh/.oo++o`     
               /osyyyyyyo++ooo+++/    
                   ````` +oo+++o\:    
                          `oo++.    

# output of `uname -a`
Linux roma 6.6.92-eic7x-2025.07 #2025.09.25.06.45+ SMP Thu Sep 25 06:53:10 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux

Benchmark results

CPU

• Geekbench 6: (174 single / 640 multi - https://browser.geekbench.com/v6/cpu/14421987)
• 17.759 Gflops at 32.5W, for 0.55 Gflops/W (geerlingguy/top500-benchmark HPL result)

Power

• Sleep power draw (at wall): 2.2 W
• Idle power draw (charging, battery 80%): 41.4 W
• Idle power draw (at wall, battery 100%): 25.1 W
• Maximum simulated power draw (stress-ng --matrix 0): 31.7 W
• During Geekbench multicore benchmark: 32.1 W
• During top500 HPL benchmark: 32.9 W

Disk

ZHITAI TiPlus7100 512GB

Benchmark	Result
iozone 4K random read	60.31 MB/s
iozone 4K random write	126.92 MB/s
iozone 1M random read	1042.36 MB/s
iozone 1M random write	1306.80 MB/s
iozone 1M sequential read	1076.06 MB/s
iozone 1M sequential write	1301.79 MB/s

Network

iperf3 results:

WLAN (WiFi 6, built-in Intel AX200)

• iperf3 -c $SERVER_IP: 637 Mbps
• iperf3 -c $SERVER_IP --reverse: 293 Mbps
• iperf3 -c $SERVER_IP --bidir: 510 Mbps up, 141 Mbps down

(Be sure to test all interfaces, noting any that are non-functional.)

GPU

The device includes a PowerVR A-Series AXM-8-256, with some precompiled drivers for OpenGL and Vulkan, but compatibility seemed a little hit or miss...

glmark2

glmark2-es2-wayland results:

=======================================================
    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      Imagination Technologies
    GL_RENDERER:    PowerVR A-Series AXM-8-256
    GL_VERSION:     OpenGL ES 3.2 build 24.2@6643903
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 205 FrameTime: 4.884 ms
[build] use-vbo=true: FPS: 475 FrameTime: 2.106 ms
[texture] texture-filter=nearest: FPS: 525 FrameTime: 1.907 ms
[texture] texture-filter=linear: FPS: 542 FrameTime: 1.846 ms
[texture] texture-filter=mipmap: FPS: 534 FrameTime: 1.875 ms
[shading] shading=gouraud: FPS: 471 FrameTime: 2.126 ms
[shading] shading=blinn-phong-inf: FPS: 493 FrameTime: 2.029 ms
[shading] shading=phong: FPS: 513 FrameTime: 1.953 ms
[shading] shading=cel: FPS: 475 FrameTime: 2.107 ms
[bump] bump-render=high-poly: FPS: 546 FrameTime: 1.832 ms
[bump] bump-render=normals: FPS: 548 FrameTime: 1.825 ms
[bump] bump-render=height: FPS: 535 FrameTime: 1.871 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 492 FrameTime: 2.035 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 602 FrameTime: 1.661 ms
[pulsar] light=false:quads=5:texture=false: FPS: 536 FrameTime: 1.868 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 116 FrameTime: 8.670 ms
[desktop] effect=shadow:windows=4: FPS: 956 FrameTime: 1.046 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 243 FrameTime: 4.121 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 242 FrameTime: 4.144 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 362 FrameTime: 2.763 ms
[ideas] speed=duration: FPS: 693 FrameTime: 1.443 ms
[jellyfish] <default>: FPS: 1729 FrameTime: 0.579 ms
[terrain] <default>: FPS: 117 FrameTime: 8.606 ms
[shadow] <default>: FPS: 1505 FrameTime: 0.665 ms
[refract] <default>: FPS: 196 FrameTime: 5.122 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 2185 FrameTime: 0.458 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 2212 FrameTime: 0.452 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 1473 FrameTime: 0.679 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 2198 FrameTime: 0.455 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 2294 FrameTime: 0.436 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 2337 FrameTime: 0.428 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 2297 FrameTime: 0.435 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 2287 FrameTime: 0.437 ms
=======================================================
                                  glmark2 Score: 936 
=======================================================

vkmark

vkmark results:

$ DISPLAY=:0 vkmark --debug
Debug: WindowSystemLoader: Looking in /usr/lib/riscv64-linux-gnu/vkmark for window system plugins
Debug: WindowSystemLoader: Loading options from /usr/lib/riscv64-linux-gnu/vkmark/kms.so... ok
Debug: WindowSystemLoader: Loading options from /usr/lib/riscv64-linux-gnu/vkmark/wayland.so... ok
Debug: WindowSystemLoader: Loading options from /usr/lib/riscv64-linux-gnu/vkmark/xcb.so... ok
Debug: WindowSystemLoader: Probing /usr/lib/riscv64-linux-gnu/vkmark/kms.so... succeeded with priority 255
Debug: WindowSystemLoader: Probing /usr/lib/riscv64-linux-gnu/vkmark/wayland.so... succeeded with priority 255
Authorization required, but no authorization protocol specified

Debug: WindowSystemLoader: Probing /usr/lib/riscv64-linux-gnu/vkmark/xcb.so... succeeded with priority 0
Debug: WindowSystemLoader: Selected window system plugin /usr/lib/riscv64-linux-gnu/vkmark/kms.so (best match)
Debug: KMSWindowSystemPlugin: Using legacy modesetting
Segmentation fault (core dumped)

With a version compiled from source, I got:

Error: No suitable Vulkan physical devices found

Here is the vulkaninfo for the board:

Click to expand `vulkaninfo`

==========
VULKANINFO
==========

Vulkan Instance Version: 1.3.275


Instance Extensions: count = 23
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 4
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6
VK_LUNARG_direct_driver_loading        : extension revision 1

Instance Layers: count = 2
--------------------------
VK_LAYER_MESA_device_select Linux device selection layer 1.3.211  version 1
VK_LAYER_MESA_overlay       Mesa Overlay layer           1.3.211  version 1

Devices:
========
GPU0:
	apiVersion         = 1.3.277
	driverVersion      = 1.598.191
	vendorID           = 0x1010
	deviceID           = 0x30010101
	deviceType         = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
	deviceName         = PowerVR A-Series AXM-8-256
	driverID           = DRIVER_ID_IMAGINATION_PROPRIETARY
	driverName         = PowerVR A-Series Vulkan Driver
	driverInfo         = 24.2@6643903
	conformanceVersion = 1.3.8.1
	deviceUUID         = 33302033-2034-3038-2031-303100000000
	driverUUID         = 36363433-3930-3300-0000-000000000000

GravityMark

GravityMark results:

1. Download the latest version of GravityMark: https://gravitymark.tellusim.com
2. Run `chmod +x [downloaded_filename].run`
3. Run `sudo ./[downloaded_filename].run` and press `y` to accept the terms.
4. Open the link it prints, and run the Benchmark defaults, changing to 720p resolution and 50,000 asteroids.

Note: These benchmarks require an active display on the device. Not all devices may be able to run glmark2-es2, so in that case, make a note and move on!

AI / LLM Inference

ollama LLM model inference results:

NPU Inference

System	CPU/GPU	Model	Eval Rate	Power (Peak)
DC-ROMA Mainboard II (8-core RISC-V)	NPU	deepseek-r1:7b	4.9 Tokens/s	38.9 W

CPU Inference

System	CPU/GPU	Model	Eval Rate	Power (Peak)
DC-ROMA Mainboard II (8-core RISC-V)	CPU	deepseek-r1:1.5b	0.59 Tokens/s	32.0 W
DC-ROMA Mainboard II (8-core RISC-V)	CPU	llama3.2:3b	0.31 Tokens/s	30.6 W

More results: geerlingguy/ai-benchmarks#28

Memory

tinymembench results:

Click to expand memory benchmark result

tinymembench v0.4.10 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   4818.5 MB/s (0.2%)
 C copy backwards (32 byte blocks)                    :   4826.0 MB/s
 C copy backwards (64 byte blocks)                    :   4842.2 MB/s (0.2%)
 C copy                                               :   4800.1 MB/s
 C copy prefetched (32 bytes step)                    :   4825.5 MB/s (32.0%)
 C copy prefetched (64 bytes step)                    :    864.5 MB/s (0.2%)
 C 2-pass copy                                        :    717.7 MB/s
 C 2-pass copy prefetched (32 bytes step)             :    716.7 MB/s
 C 2-pass copy prefetched (64 bytes step)             :    716.8 MB/s
 C fill                                               :   7789.3 MB/s (28.7%)
 C fill (shuffle within 16 byte blocks)               :   7794.9 MB/s
 C fill (shuffle within 32 byte blocks)               :   7837.7 MB/s (0.4%)
 C fill (shuffle within 64 byte blocks)               :   7804.5 MB/s
 ---
 standard memcpy                                      :   4335.0 MB/s
 standard memset                                      :   7837.1 MB/s (0.2%)

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read, [MADV_NOHUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.0 ns          /     0.0 ns 
     32768 :    0.0 ns          /     0.0 ns 
     65536 :    2.5 ns          /     3.9 ns 
    131072 :    3.8 ns          /     5.2 ns 
    262144 :    7.3 ns          /    10.5 ns 
    524288 :   15.8 ns          /    22.3 ns 
   1048576 :   20.2 ns          /    26.5 ns 
   2097152 :   22.8 ns          /    28.3 ns 
   4194304 :   51.9 ns          /    79.3 ns 
   8388608 :  117.8 ns          /   165.3 ns 
  16777216 :  153.1 ns          /   194.1 ns 
  33554432 :  172.3 ns          /   208.8 ns 
  67108864 :  185.7 ns          /   222.5 ns 

block size : single random read / dual random read, [MADV_HUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.0 ns          /     0.0 ns 
     32768 :    0.0 ns          /     0.0 ns 
     65536 :    2.5 ns          /     3.9 ns 
    131072 :    3.8 ns          /     5.2 ns 
    262144 :    4.7 ns          /     6.1 ns 
    524288 :   12.1 ns          /    16.4 ns 
   1048576 :   16.1 ns          /    19.4 ns 
   2097152 :   17.7 ns          /    20.3 ns 
   4194304 :   45.2 ns          /    66.7 ns 
   8388608 :  106.8 ns          /   146.5 ns 
  16777216 :  137.7 ns          /   168.9 ns 
  33554432 :  153.1 ns          /   175.6 ns 
  67108864 :  164.9 ns          /   183.9 ns 

Core to Core Memory Latency

See discussion about memory access improvements on this system.

sbc-bench results

See: ThomasKaiser/sbc-bench#125

Phoronix Test Suite

Results from pi-general-benchmark.sh:

• pts/encode-mp3: TODO sec
• pts/x264 4K: TODO fps
• pts/x264 1080p: TODO fps
• pts/phpbench: 104733
• pts/build-linux-kernel (defconfig): 2852.438 sec

[geerlingguy]

More to come; testing will commence soon on the DC-ROMA Mainboard II version of the Framework 13" laptop. I was provided a unit for test and review along with a custom Raspberry Pi RP2350 USB-C expansion module, which I'll also try to test under Ubuntu.

A few quick notes from use:

• The Framework build quality is very good; though not Apple-premium, especially the keyboard. It's a tiny bit squishy likely due to the plastic parts on the chassis.
• I very much enjoy the simplicity of the system. Though having more than four expansion ports would be nice.
• The fan ramps up to 100% while the battery is charging a while (I ran it down to 30% then plugged it into my meter, and it's charging at 55W) quite often, even at idle. The system is usually pulling down between 24-28W of power, no matter what performance profile is selected (that's power draw at the wall with battery charged to 100% for over an hour).
• The screen is excellent, but running at 2x resolution I'm noticing a bit of lag like I have on other RISC-V systems, it can't quite keep up with GUI-heavy tasks. It does seem like the integrated GPU is used for some stuff, but not for things like video playback in FireFox (I could only play 720p smoothly there)
• The trackpad is great, though right click (two finger + click) seems to be tricky to nail, not sure why.
• It feels a little strange having Pi 4-level performance... on a laptop that feels extremely modern/new. It's like running my Pi 5 on a 4K monitor, something feels wrong about that, but in a good way lol
• The Framework HDMI module worked—though I believe it will only work in the top right bay, where there's a USB-C multiplexer chip that muxes in the HDMI signal.
• Chromium had GPU acceleration, FireFox did not (much like the Pi), and WebGL Aquarium ran at 40-ish fps with defaults on Chromium, and 16-17 fps on FireFox. YouTube playback was similar to FireFox, it didn't seem to benefit from GPU acceleration, and wasn't smooth until 720p (still some choppy audio).
• SuperTuxKart ran at 7-8 fps on high settings at 1080p, and 30+ fps on half-resolution with low graphics settings.
• Crispy-Doom ran at full resolution, and was smooth and playable... but like, that's from 1993, so it better!
• Like the Pi 4, I think this system is the first RISC-V desktop environment that isn't painful to use, just inconvenient. Actions still have delays, but the delays are more reasonable, and don't make me constantly question if the computer's frozen.
• The SoC is two chips on an Interposer (Eswin EIC7700X 4-core CPU + GPU + 19.95 TOPS INT8 NPU), plus access to 32 GB of total LPDDR5 RAM... plus built-in H.265 encode and decode. There's a lot of specs—but how much of it will be supported? Eswin already does a better job than many Arm vendors at supporting things in Linux, though. I'm slightly hopeful...
• The Eswin SoC only supports the RV64GC / RVA20 profile, not RVA23, which means distros like Ubuntu, moving forward, are going to obsolete older RISC-V chip designs with cores like the P550—meaning this hardware will have a short useful life, as I don't think any distro maintainers will meaningfully support older RISC-V chips. Ubuntu 24.04 standard support goes out to 2029.
  • But it is nice that the Framework chassis can outlive the RISC-V mainboard—I will try to upgrade to an AMD APU mainboard and compare it really quick too.
• The external USB ports are SuperSpeed / 5 Gbps (so USB 3.0), and file copies to/from an external SSD went around 100 MB/sec, so definitely faster than USB 2.0 speeds.
• I tried the included Deepseek R1:7b model (I believe it's INT8), which runs on the NPU, and got 4.9 Tokens/s. See this issue for more details on AI/LLM testing.
• I plugged in an RP2350 GPIO expansion module (see more here), and tested it with SemiTOV-MCL, a Python to MicroPython tool for working with the MCU connected directly to the USB-C port over serial.

Things I have yet to test:

• Can I run Fedora 42? (and does Fedora have a different stance on RVV20/23 support timelines?)

[geerlingguy]

I noticed there's only 16 GB of RAM available, but asking DeepComputing, they said this should be a 32GB model, and 16GB is pre-allocated to the NPU. I'd like to see if it's possible to change that allocation (for testing and for fun, especially testing the HPL/Top500 benchmark).

Searching dmesg logs, I find:

$ sudo dmesg | grep _npu
[   11.320204] win2030-lpcpu soc:lpcpu@0: Direct firmware load for eic7702_lpcpu_npu_fw_die0.bin failed with error -2
[   11.433416] win2030-lpcpu soc:lpcpu@1: Direct firmware load for eic7702_lpcpu_npu_fw_die1.bin failed with error -2
[   23.136633] eswin_npu 51c00000.eswin-npu: device is not dma coherent
[   23.154130] eswin_npu 51c00000.eswin-npu: Adding to iommu group 29
[   23.180345] eswin_npu 51c00000.eswin-npu: device is behind an iommu
[   23.290397] eswin_npu 51c00000.eswin-npu: EM: created perf domain
[   23.632632] eswin_npu 51c00000.eswin-npu: win_engine 0xffffaf80d4000040
[   23.645744] eswin_npu 71c00000.eswin-npu: device is not dma coherent
[   23.663446] eswin_npu 71c00000.eswin-npu: Adding to iommu group 30
[   23.676984] eswin_npu 71c00000.eswin-npu: device is behind an iommu
[   23.766147] eswin_npu 71c00000.eswin-npu: EM: created perf domain
[   24.225058] eswin_npu 71c00000.eswin-npu: win_engine 0xffffaf9fd758f840

I didn't see a kernel module nor service for the NPU, so trying to find out if it's part of the custom kernel build or something.

Also, while digging I found there's a service es-fand that's controlling fan speeds. It uses a script at /usr/bin/es-fand.sh, which runs the binary /usr/bin/es-fand. Not sure what tweaks/controls there may be, but that might explain why the fan goes from 0% to like 80%, then soon 100% when the battery's charging.

I'm not complaining, as I'm happier with the fan overdoing it on a dev machine rather than letting things burn up :)

[geerlingguy]

Here's a graph of power usage before/during/after some benchmarking runs. You can see the CPU keeps its clock up at 1.8 GHz, keeping the idle power draw fairly high at 25W. Then it ramps up a bit while under heavy load to 32-33W.

[geerlingguy]

While looking into u-boot and sources for this laptop, I found this fun little bit on the Debian mailing list from @blizzardfinnegan (which I believe refers to the pre-Framework-Mainboard version of the DC-ROMA laptop, which used a SpacemiT SoC instead of the Eswin with P550 cores):

I own this laptop, and as a person who is lucky enough to not need any accessibility settings, it is frankly a nightmare to use in it's current state. Simply running system updates is not an option, and I've had to completely reinstall the operating system on mine several times because I forgot. I've tried off-and-on since I bought it at least a year ago, and it's currently gathering dust next to my other K1/M1 system while I wait for the upstreaming effort to finish. Even after the CPU gets upstreamed, owners of this laptop will probably need to use DeepComputing's custom ISO while Imagination Technologies (the GPU vendor) gets their act together and finally merges their changes to mesa into upstream.

I would highly recommend reading through the issues in the DC ROMA II Github page (see here: https://github.com/DC-DeepComputing/DC-ROMA_Gen2_LAPTOP_K1_RV-L2A ), just to get a sense for the state of the device as a whole. It's clunky, it's not ready, and it's largely been forgotten by DeepComputing as far as I can tell while they figure out their Framework Mainboard endeavour. The JH7110 SOC is kinda the only good RISC-V chip to recommend right now for anything outside the absolute most niche cases, because it's been almost entirely upstreamed, and therefore is supported by the Debian installer natively. RISC-V is a really cool technology, and I love it a lot, but the hardware ecosystem right now is about the same as the Raspberry Pi 2 was when it came out, and I mean that both from a software support standpoint and from a hardware performance perspective.

To be perfectly frank, if I could talk to my past self, I would say to not buy this laptop and save myself the migraines. In a few years, it will be better, but the hardware barely runs on the hardware manufacturer blessed distro images. The fact that anyone tried to cram this chip in a laptop is a testament to the arrogance of man, because a laptop appeals to normal people, and this laptop is at best a marketing stunt to drum up good PR for RISC-V on the whole.

Remember again, this was written about the previous laptop iteration—the DC-ROMA RISC-V Mainboard II is using a different SoC and has a different architecture.

Though right now the sources and OS images are still in a 'coming soon' state! See: https://github.com/DC-DeepComputing/Framework

[blizzardfinnegan]

Thanks for the ping! Wild to see my name show up in one of these info-dumps, been following the channel for a good bit.

I'm trying my best to keep up with the RISC-V, so I feel like I'm in a decent spot to give you a bit more information on the landscape.

Firstly, I should clarify with more concrete information regarding the timeline. The DC ROMA II laptop was first discussed by DeepComputing in June 2024 (see here). The original announcement of the Framework RISCV Mainboard is from the same time (see here). The DC ROMA II (according to the Wayback Machine's archives of their ad page, they seem to have gone on sale pretty much immediately, as opposed to the Framework Mainboard which didn't go on sale until Feb. 4th 2025 (see here). You are correct that the device being discussed is a different device, although it's more powerful than the original Framework Mainboard.

Secondly, I think I do need to make an update to a previous statement regarding Imagination Technologies. Phoronix yesterday caught that Imagination has upstreamed some support for both the JH7110 (Framework Mainboard) and K1/M1 (DC ROMA II) GPUs. (The JH7110 uses the BXE-4-32 GPU, while the K1/M1 use the BXE-3-32 GPU.) It doesn't really help with Debian, due to Debian's slow release cadence, and it's unofficial support but it is progress. Later on in the discussion, one of the respondents suggested that hardware vendors are going to start upstreaming hardware support before hardware release starting in 2026, which is a really important change and going to be huge for the community. You mention the cores here are using the P550 architecture; the only chips I've seen so far that use the P550 core is the EIC7700X (also used in the HiFive Premier P550 and the Milk-V Megrez boards). That chip uses the AXM-8-256 GPU from Imagination, and afaict is not actively supported at this time, and given the notes on the B-series newer designs, I don't expect it to be upstreamed. The fact that DeepComputing's website mentions a "dual-die" design makes me a bit hesitant in that analysis, but without seeing a teardown it's hard to tell for sure. I should also say, in my opinion, Imagination's GPUs are kinda bargain-basement. Encode/Decode is rough around the edges, the Vulkan and OpenCL support is a bit shoddy (see here), and anything above 1080 is asking a lot. You mention issues with youtube above 720, and I'm not in the least surprised. A proper iGP IP block on the die from someone like AMD, Intel, NVidia, honestly Arm's stuff would probably do better if it was compatible.

Thirdly, I think one of the biggest hurdles that I didn't really touch on in that discussion was the fact that most current RISC-V boards don't have UEFI support. This is a massive limitation of RISC-V on the whole, since it's the majority of the reason why boards have to use unique images for said boards. (There's a lot of nuance in that statement, but it's one of the biggest reasons.) From the limited details on the pages you link to, they don't explicitly mention UEFI support (and at least Milk-V seem to recognise it as a huge selling point, all of their boards that support it say so on their main landing pages), and I think that's gonna hamper any use of this device, both in the short and long term. Once hardware manufacturers build in UEFI support, the RISC-V ecosystem is gonna explode (/pos), and there's evidence they know that and are heading in that direction.

Can't wait to see the full video, curious to hear your thoughts on the experience. That being said, I would also say to hold out at least a little hope for the future of RISC-V until after boards regularly support UEFI. I think you'll have a lot better time, and it'll be a lot more interesting for everybody.

[blizzardfinnegan]

I noticed there's only 16 GB of RAM available, but asking DeepComputing, they said this should be a 32GB model, and 16GB is pre-allocated to the NPU. I'd like to see if it's possible to change that allocation (for testing and for fun, especially testing the HPL/Top500 benchmark).
...
I didn't see a kernel module nor service for the NPU, so trying to find out if it's part of the custom kernel build or something.

I would recommend decompiling the DeviceTree Binary (.dtb) for the device found in /boot, see if you can find anything in there. It's not as scary as it sounds, promise. All signs point to this laptop using DeviceTree U-Boot, and if that's the case, the most surefire way to make a change like this to that is to modify the DeviceTree file before building the kernel and initramfs. That would also mean that making such a modification is gonna be non-trivial for users, in which case... rough.

[geerlingguy]

Once hardware manufacturers build in UEFI support, the RISC-V ecosystem is gonna explode (/pos), and there's evidence they know that and are heading in that direction.

Heh, you have high hopes; I have a feeling we may have a long time for that still, like we've had with Arm SoCs. But where there's a will, there's a way.

If RISC-V can solve the efficiency gap (at least somewhat) and work with UEFI, it would be an amazing ecosystem compared to Arm. But they're still ironing out architectural issues and haven't even gotten to a full RVV spec in a shipping chip that will be easy for all distros to support in the current state :(

We'll see, though. I'm still bullish on the potential, and the performance is getting better as they add in little tweaks chip to chip (even if efficiency is pretty flat).

[blizzardfinnegan]

I definitely am reaching a bit, don't get me wrong. But also, several of the new Milk-V RISC-V boards explicitly mention coming with UEFI, which at least makes it feel like it's not totally unreasonable to hope. The VisionFive2 also has experimental UEFI support, so it's not impossible to see UEFI support come from both ends of the timeline. I myself am just waiting on the SpacemiT K1/M1 stuff to get upstreamed to start working on my own port of Tianocore for the Milk-V Jupiter (partially to get NVidia GPUs running; at least for the cards I have for testing, you need x86 emulation in the boot setup to get an NVidia GPU to boot, and Intel has an x86 emulation extension for Tianocore that shouldn't be too hard to get added in). Technically the info is available in the sources on SpacemiT's Gitee, but accessing it is kinda hit-or-miss in my experience.

The ISA spec also moves incredibly fast compared to silicon. In discussions that GamersNexus has had with other tech journalists, it takes like 5 years between making a decision and actually following through with it, for x86 hardware. I wouldn't be surprised if RISC-V was the same or longer, so I don't think we'll get any boards compatible with the next Ubuntu LTS by the time it comes out. Canonical's decision to drop all current-gen hardware support really irks me, but at least it's not a universal thing yet. Someone asked about RVV-gating the next Debian release, and the response was something to the effect of "Maybe in a couple releases from now, but we don't have the hardware to do that".

Given the above, I'm also incredibly eager to see efficiency go up. The hardware designers have been so busy implementing the spec that they don't have the time or bandwidth to actually implement efficiency at the hardware level (and they don't have a big enough market share to go for a cutting-edge process node and get efficiencies that way). If efficiency is largely flat as performance is improving, then the only thing stopping more efficient design is the ISA moving around. The instruction space of the ISA is reasonably full (I wanna ballpark at like 70%? I haven't looked at more recent iterations, it might be higher than that), and there's not a lot left to do from a low-level perspective. I feel like RVA23 is a really solid profile, and that hardware designers can stick with it for a long time, and focus on other stuff like efficiency and power (primarily GPU power >.>).

Edit:
Just a quick follow up on this, with what i said previously and a bit more empirical evidence.

In discussions that GamersNexus has had with other tech journalists, it takes like 5 years between making a decision and actually following through with it, for x86 hardware.

The P550 core was announced in June of 2021 according to this article from SiFive. June 2021 to Jan 2025 (release date of the Premier, the first board I can find to use the P550 core) is 3.5 years. Given this, a very ignorant projection says that if someone designed a core the day RVA23 got ratified (announced Oct. 24th, 2024), hardware with it will come out in the first half of 2028, 2 years after the release of Ubuntu 26.04 LTS. Alternatively, if we go with the first RVA23 core announced at the end of August 2023, we come out with March 2027. Now, one would argue that these chips are RVA23, including the previously mentioned UR-DP1000, A210, and K3. The cores that the A210 and UR-DP1000 are based off of aren't actually RVA23 compliant (according to reddit), but even then, the K3 is supposed to come out in 2026 (although at time of writing, no boards are advertised as using the chip). So Ubuntu 25.10 will most likely not support any physical RISC-V boards, and 26.04 LTS might not initially support anything either.

[geerlingguy]

A little digging on the model name FML13V03, I found a couple GitHub repos that seem to have disappeared but were in DuckDuckGo's search index, like https://github.com/DC-DeepComputing/fml13v03_u-boot/releases

But also the issue where the eic7702-deepcomputing-fml13v03.dtb was added, DeepComputing's fml13v03 PPA with custom builds of chromium, firefox, ffmpeg, wayland, vlc, mpv, mesa...

Also noticed this comparison of the upcoming UltraRISC DP1000 chip, versus the DC-ROMA Mainboard II: https://browser.geekbench.com/v5/cpu/compare/23667112?baseline=23647778

Looks like 1.5-2x as fast per core, still not quite Pi 5 level, but certainly interesting to observe. That's the chip Milk-V seems to be incorporating into its Titan board (which as you mention, is supposed to have UEFI support...).

That GeekBench run is on v5, though.

[geerlingguy]

At @ThomasKaiser's suggestion (and it will interest @blizzardfinnegan too ;), I've decompiled the dtb:

The file /boot/dtbs/6.6.92-eic7x-2025.07/eic7702-deepcomputing-fml13v03.dtb is a symlink to the same file inside the /boot/dtbs/eswin folder:

/boot/dtbs/6.6.92-eic7x-2025.07/eswin/eic7702-deepcomputing-fml13v03.dtb

$ sudo apt install -y device-tree-compiler
$ dtc -I dtb -O dts /boot/dtbs/6.6.92-eic7x-2025.07/eswin/eic7702-deepcomputing-fml13v03.dtb

The decompiled device tree is attached: eic7702-deepcomputing-fml13v03.dts.txt

[ThomasKaiser]

As for the dts it seems there is one cache-controller and two ddr-controllers per NUMA node (probably only dealing with the CPU side of things and the NPU being configured through BLOBs) and a quick search suggests the SoC supporting EDAC as such you could install edac-utils and then do an edac-util -vv --report=full.