| 25 May 2026 |
|  radex joined the room. | 12:11:10 |
| radex | 
Download 9D14A408-C4B6-44E9-B081-BD1121E0F7B3_1_102_a.jpeg | 12:12:01 |
| radex | hello 👋 hoping to run nixos on this thing soon(ish) :) | 12:12:32 |
| radex | (I'd get started on hacking today but they forgot to put a suitable power supply in the box lol) | 12:12:49 |
 implr | In reply to @grw00:matrix.org
nice, don't forget the NPU :) that NPU should be able to run normal linux processes too, these are regular rva23 cores with a fat vector unit | 12:25:11 |
| implr | but iirc spacemit did some scheduler crimes to isolate them for ai | 12:25:31 |
 Alex | Doesn't that mean you could patch the kernel to get them running as normal cores?
If they were kind, they might've even left it as a Linux kernel option (otherwise, nothing is stopping you from contributing one for that purpose :D) | 12:26:45 |
|  ari ❄ joined the room. | 12:28:32 |
| implr | I assume you could (or undo their patch). Still the endgame is to get proper mainline kernel support, vendor kernels suck | 12:29:12 |
 dramforever | their kernel was patched to get them running as normal cores | 12:39:39 |
| dramforever | there's some cpu mask weirdness you can do to throw a process onto the "other" 8 cores | 12:40:28 |
| dramforever | on mainline it doesn't work because nobody bothered adding support to handle isolating cores based on vlen (because it's not, in general, possible to migrate processes between vlen differing cpus) | 12:41:25 |
| dramforever | the main two things stopping you from contributing changes to spacemit vendor kernels are
- RoI
- i don't think there's anyone at spacemit to receive your contribution. they're probably all busy af working on their next and next next chips' sw
| 12:43:49 |
| dramforever | your patches would probably need to be Icenowy level for them to take it, like "make amd gpus working" | 12:45:10 |
| dramforever | * your patches would probably need to be Icenowy level for them to take it, like "get amd gpus working" | 12:45:22 |
 grw00 | hm interesting. do they provide sdk with vendor kernel that knows how to use these cores? | 17:24:19 |
| implr | the long term path should be mainline anyway | 18:01:19 |
| implr | if these actually ship widely and are the first proper rva23 devices, there might be enough momentum to fix all of that upstream | 18:01:49 |
| grw00 | yeah agree, was curious if theyre shipping it non-functional | 18:03:29 |
| 26 May 2026 |
 liberodark | 
Download image.png | 19:46:09 |
| liberodark | Hi, after K1 now K3 have finish put nixos 26.05 on it. | 19:46:55 |
| liberodark | * Hi, after K1 now K3 have finish to put nixos 26.05 on it. | 19:48:55 |
| grw00 | DVFS? | 20:29:18 |
| grw00 | (nice!) | 20:29:25 |
| liberodark | Next is to finish my hydra infra for give public cache for stable nixpkgs. | 20:38:39 |
| liberodark | Yep i need to work on DVFS but I still have quite a few things to do before that point. | 20:40:09 |
| radex | do you have your nix files for this posted anywhere yet? would love to replicate it | 20:40:30 |
| liberodark | Yes, it's planned. I did it for K1, but K3 was my main goal, but my board took a really long time to arrive... I'll give you the details as soon as I'm less in the alpha stage.
| 20:42:17 |
| radex | thanks. I'll be happy to follow along without a binary cache, I can borrow a few hundred cores to build the world | 20:44:49 |
| liberodark | I already offer several caches for arm x86_64, it seems normal to do the same for riscv, but in addition it allows me to work on hydra, I've wanted to set it up for a while. | 20:46:54 |
