[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Deep Computing DC-ROMA ii won't boot



For what it's worth, its not DeepComputing's fault. This is how new hardware and architectures go, and if hardware developers like SpacemiT and Imagination don't dump a ton of money, time, and effort into upstreaming (ideally before the hardware releases like Intel, AMD, and NVidia do), it's gonna keep sucking. SpacemiT has a decent clip at upstreaming, but Imagination has had 5 years since the release of the B-series GPUs (according to Wikipedia) and they *just* merged BXM drivers (both the K1/M1 and the JH7110 use the BXE design, which is different enough to mean that it most likely won't work).

Furthermore, in fairness to Imagination, their OSS driver according to the kernel mailing list appears to be from the ground up, and they're working from one design and fanning out to similar designs as they go. I can't exactly say I'd be doing a better job in their position.

11 Sept 2025 20:25:55 梁宇宁 <yuning.liang@deepcomputing.io>:

absolutely agree on everything Blizzard said.
We unreservedly apologised on the pain our customers going through. 

most of our RISCV SoC suppliers understand the problem but with upstream unfriendly like GPU. No mass production software quality is guaranteed in non designated version LTS kernel.

For those non display like integrated GPU related features, we seeing the light of the tunnel once K1 upstreaming is done on CPU related as per https://github.com/spacemit-com/linux/wiki , any external RISCV support GPU will see the tunnel light too.

For any display like integrated GPU remains unresolved, thé best we can do will probably be a huge no-guarantee display related patch on top of the mainline kernel like We did in JH7110s Framework RISCV mainboard.

Many thanks 





From: "Blizzard Finnegan"<blizzardfinnegan@gmail.com>
Date:  2025年9月12日 (周五) 03:09
Subject:  Re: Deep Computing DC-ROMA ii won't boot
Hello again,
I'll explain below, but TLDR is between the accessibility requirements and the weird nature of the hardware, this is, in no uncertain terms, not the laptop for you. I would highly recommend waiting, at least until the rest of the K1 SOC is fully upstreamed; the wiki page for this I will link again here: https://github.com/spacemit-com/linux/wiki

Firstly, you ***cannot*** use a custom kernel for this device, at time of writing. The hardware developer has a custom kernel that you *must* use for this device, v6.6. While there is work in progress, a newer kernel that is not distributed by the hardware developer will not work. 

Next, let's talk u-boot vs UEFI. U-boot requires a lot more than UEFI, as has been mentioned previously. However, there is a lot more information hidden in that statement than you might think. For example, you can't just move the dtb file to the right location. The "dtb" extension stands for DeviceTree Binary, and is directly tied to the kernel version being run. Simply moving the binary into the right location will cause a version mis-match and cause the hardware to not boot properly. Also, with the version of U-boot the DC ROMA II uses, the entire boot stack is stored on the storage medium (be it SD card or NVMe). This is opposed to UEFI, where you just have flash on the motherboard that is smart enough to reach out to the storage to find your bootloader to get the process started. If you look in the installer ISO for Debian, in /boot/dtbs I believe, it lists all the compatible chips, and SpacemiT is not in there. Until it is, the Debian ISO will not work, and given the pace of the SpacemiT crew, I'd hesitantly say expect that to be added in Forky.

To reiterate, simply using Debian Trixie on this device at this point in time *will*. *not*. *work*. The standard Debian kernel does not support the hardware yet, and the SpacemiT kernel you will likely have to rebuild from scratch to get the modules you need for accessibility purposes running, which in my experience is *very* hit or miss getting it to boot afterwards. 

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.


On Thu, 11 Sept 2025 at 18:01, Kirk Reiser <kirk@reisers.ca> wrote:
Hello folks: Thank you for the responses.

 The laptop did infact come with ubuntu-24.04 installed, except it was
 a greatly reduced package, they say because it wasn't expected that a
 lot of people would login. It was kind of bogus in my mind.

 I upgraded the OS to their most recent version of 24.04.3 except it
 craps out when trying to upgrade to their idea of the latest kernel
 6.14.0. The distro as shipped has kernel 6.6.36 except with many
 kernel modules missing. The upgrade of the kernel dies while trying to
 copy the dtb files from a nonexistant spacemit directory in /boot. I
 have tried many things to attempt to spoof the new kernel from copying
 over the installed dtbs to a new 6.14.0 directory with no joy.

 Oh, and yes, it is using u-boot.

 Unfortunately Some of the kernel modules which are missing are the
 speakup modules which I must have to provide speech in text console
 mode. That has also made it much more difficult because it means I
 have to have a sighted person here to help me install/break/reinstall
 various packages.

 Upon examining the two debian images I tried to boot I realized that
 the netinst is grub based so wouldn't boot. The dvd however does
 appear to be u-boot based so I am still at a loss for the reason it
 won't boot.

 I don't really understand the booting mechanism of u-boot, even after
 reading what I've been able to find.

 Anyway, the spacemit is an 8-core SOC called K1X I believe. The
 processor is a M1-8571. Here is the cpu line from dmesg on the system:

 spacemit-socinfo soc:socinfo@0: Spacemit: CPU[M1-8571] REV[C] DRO[127] Detected

 So thank you and if you have any other recommendations I would
 appreciate them.

    Kirk

 
 On Thu, 11 Sep 2025, Greg Sterling wrote:

 > Hello!
 >
 > My boss thought I might be able to get you contact with the devboards community for help.  If you’re interested, you might be able to get some help by sending an email to devboard-community@riscv.org.  There are a lot of helpful people out there who may have experienced similar problems and may be able to offer some help or suggestions.
 >
 > Thanks and have a great day!
 >
 > Greg Sterling (RISC-V International)
 > Phone: +1 603 321 7320
 > E-mail: greg@riscv.org
 >
 >> On Sep 10, 2025, at 8:04 PM, Jeff Scheel <jeff@riscv.org> wrote:
 >>
 >> You might want to try and connect with Kirk with the DevBoard community to see  if someone can help here...
 >>
 >> --
 >> Jeff Scheel (he/him/his)
 >> Director of Technical Programs, RISC-V International
 >>
 >> Join me at RISC-V Summit NA (link <https://events.linuxfoundation.org/riscv-summit/>)
 >>
 >>
 >> ---------- Forwarded message ---------
 >> Date: Wed, Sep 10, 2025 at 4:40 PM
 >> Subject: Re: Deep Computing DC-ROMA ii won't boot
 >> To: Kirk Reiser <kirk@reisers.ca <mailto:kirk@reisers.ca>>
 >>
 >>
 >> Good evening Mr. Reiser,
 >>
 >> unfortunately, DeepComputing hasn't released any downloadable images, or documentation regarding the boot process.
 >>
 >> The description for your issue makes me believe that the FML13V03 board (your DC-ROMA gen II model) probably needs something like u-boot, similar to the FML13V01 board (the previous revision).
 >>
 >> That would explain why the two "generic" Debian images won't boot once flashed on any medium. AFAIK, the Gen II model is not supported by Debian yet either. Hopefully we can, once documentation and hardware is more readily available.
 >>
 >> Have you tried what distro DeepComputing shipped with the device (if they did)? If so, what CPU name is reported by fastfetch/neofetch/System Info under Settings?
 >>
 >> That info might possibly be able to clear up some stuff, and open the door to another port.
 >>
 >>
 >> Thanks and best regards,
 >> Lucy Mielke
 >>
 >>> Am 10.09.2025 um 22:03 schrieb Kirk Reiser <kirk@reisers.ca <mailto:kirk@reisers.ca>>:
 >>>
 >>> Hello folks: I have tried to boot with the CD image and the netinst
 >>> images on my dc-roma ii laptop computer with no luck. I would
 >>> certainly appreciate any clews or suggestions people could provide
 >>> me. In both cases the machine acts like the images are not even
 >>> there. I have dd'd the images to an sdcard because that seems to be
 >>> the only choice available other than the built-in nvme drive.
 >>>
 >>> The images I've attempted to boot from are:
 >>> debian-testing-riscv64-DVD-1.iso
 >>> debian-testing-riscv64-netinst.iso
 >>>
 >>> Thank you for your consideration.
 >>>  Kirk
 >>>
 >>
 >
 >

Reply to: