From: yuning.liang@deepcomputing.io
--9b2024c9a85794a8b3892e24a92f9df5afd3d1d3809827b576e71e29c9a5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
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"
> Date: 2025912 () 03:09
> Subject: Re: Deep Computing DC-ROMA ii won't boot
> To: ,
> 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.
>
>
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|