2026-07-01 10:47:39 <mps> gcc 17 - 'Add the spacemit-x100 processor to -mcpu/-mtune.'
2026-07-01 10:48:49 <mps> and 'Add the Spacemit-A100 processor to -mcpu/-mtune.'
2026-07-01 10:49:04 <mps> more at https://gcc.gnu.org/pipermail/gcc-patches/2026-June/722133.html
2026-07-01 15:54:15 <iggy> aren't they generally in the same cpu?
2026-07-01 15:56:01 <iggy> is the idea that you compile math/vector heavy stuff with a100 and everything else with x100 and hope the scheduler is smart enough to put them on the right cores? Or maybe you pin processes to cores?
2026-07-01 16:24:16 <mps> afaik not for now. maybe in future kernel will be 'teached' to do this
2026-07-01 16:25:42 <mps> currently A100 cpus does nothing in kernel space
2026-07-01 16:26:56 <mps> but anyway K3 X100 is faster option in riscv ecosystem
2026-07-02 18:27:56 <mps> upgraded main/opensbi to 1.9 and pushed u-boot-spacemit built with this mainline opensbi, waiting for builder to finish to test
2026-07-02 18:28:56 <mps> this have enabled some new features and extensions for K1 spacemit SoC
2026-07-02 18:29:37 <mps> tested on bpi-f3 and musebook
2026-07-02 18:31:23 <mps> I hope it will also work on orangepi rv2, so someone who have this board can test
2026-07-03 12:39:56 <mps> build-edge-riscv64 lost
2026-07-03 12:40:03 <mps> hung?
2026-07-04 10:22:03 <mps> can someone look why build-edge-riscv64 is hung
2026-07-04 10:42:20 <ikke> only ncopa can
2026-07-04 11:33:14 <mps> ufff
2026-07-05 08:36:16 <ncopa> the machine was rebooted
2026-07-05 09:12:03 <mps> thanks. hope it will stay
2026-07-06 04:15:02 <mps> algitbot: retry master
2026-07-06 07:30:59 <mps> algitbot: retry master
2026-07-06 11:28:25 <mps> just created !104949
2026-07-06 11:29:40 <mps> it is to try to get BXE-2-32 gpu work on K1 SoC, spacemit
2026-07-06 11:38:08 <mps> it builds but didn't found or activated on boot, tested on musebook
2026-07-06 11:39:16 <mps> maybe team/alpine-desktop can help to get it working on alpine
2026-07-06 15:14:55 <mps> ncopa: build-edge-riscv64 lost, again
2026-07-06 15:42:56 <ncopa> ugh. it is
2026-07-06 15:43:31 <ncopa> i think we need a better kernel for eswin7700, hifive premiere p550
2026-07-06 15:50:31 <mps> eswin is enabled by default in kernel 7.2
2026-07-06 15:51:26 <mps> though don't know if upstreamed all essential driver
2026-07-06 15:51:39 <mps> drivers*
2026-07-06 19:42:51 <mps> yet another kernel pkg in aports !104967
2026-07-07 06:41:30 <mps> alpine desperately needs better rv64 builder
2026-07-07 07:02:05 <ikke> Yes
2026-07-07 07:02:27 <ikke> We're trying to find something
2026-07-07 07:02:55 <ikke> And actually managing to obtain it
2026-07-07 22:09:48 <iggy> I know historically there's been some reticence to having more small boxes vs less bigger boxes, but maybe that's not really achievable yet
2026-07-08 04:11:03 <ikke> The current build architecture does not support multiple builders
2026-07-08 04:12:29 <ikke> And one that does would probably requires an orchestrator
2026-07-08 04:12:46 <ikke> One that knows about various types of dependencies
2026-07-08 04:29:08 <Guest9885> Have you considered using this? https://riseproject.dev/2026/05/12/rise-risc-v-runners-six-weeks-in/
2026-07-08 04:29:24 <Guest9885> Maybe I can ask them help you guys use this on other platforms 
2026-07-08 04:40:58 <ikke> We're not using github actions
2026-07-08 04:42:47 <ikke> And it's not for CI, but for actual builders, which are running in lxc containers
2026-07-08 05:39:59 <Guest9885> I see, btw it doesn't have to be github actions. If you need it you can use their infrastructure 
2026-07-08 05:40:14 <Guest9885> They will have spacemit K3 servers also soon
2026-07-08 07:08:51 <mps> iirc alpine policy is to use our machines for builder and CI
2026-07-08 07:36:35 <Guest9885> got it
2026-07-08 09:08:17 <mps> gitlab.a.o is slow today
2026-07-08 09:11:25 <ikke> Probably because we're getting hammered again
2026-07-09 17:52:41 <mps> algitbot: retry master
2026-07-09 17:53:31 <ikke> I restarted the builder earlier today
2026-07-09 18:01:17 <mps> ah, good
2026-07-09 18:02:48 <mps> but looks like rv64 hanging on onnxruntime
2026-07-09 18:03:40 <ikke> was just investigating
2026-07-09 18:06:47 <mps> I made mistake when i ordered musebook (K1) and after month K3 is announced. If I knew this i would wait and order K3
2026-07-10 11:07:19 <mps> `busybox time abuild -r` in testing/linux-k1` (MR draft) take real    2h 18m 03s
2026-07-10 11:08:04 <mps> abuild.conf have 'export JOBS=6'
2026-07-10 11:09:15 <mps> that is on K1 musebook with 16GB ram and FS on nvme
2026-07-10 20:05:41 <mps> algitbot: retry master
2026-07-13 08:27:40 <mps> added draft guide to install alpine on spacemit musebook https://arvanta.net/alpine/alpine-on-musebook/
2026-07-13 08:28:00 <mps> same can be used on bpi-f3
2026-07-13 08:52:42 <ncopa> nice!
2026-07-13 09:44:35 <mps> thanks. later I will add description what and how setup to get it as graphical workstation
2026-07-13 09:45:42 <mps> install on nvme and flash u-boot to mtd
2026-07-13 09:47:11 <mps> but soon is time for travel on vacation
2026-07-13 12:17:05 <mps> looks like build-edge-riscv64 is stuck again, building gcc from early morning
2026-07-13 12:19:32 <mps> algitbot: retry master
2026-07-13 14:14:59 <ikke> mps: could just take a long time, but I'll check 
2026-07-13 14:18:24 <mps> ikke: thanks
2026-07-13 15:14:05 <ikke> Yeah, it's still continuing
2026-07-13 15:40:32 <mps> ok, thanks for info
2026-07-14 07:21:18 <mps> I wonder do we really need big DE (kde, gnome) on riscv64, and similar which i doubt anyone use on this arch
2026-07-14 07:40:54 <ikke> Wondering the same at time
2026-07-14 13:46:16 <mps> algitbot: retry master
2026-07-14 21:03:49 <b88k66m> !list
2026-07-15 08:44:17 <mps> algitbot: retry master
2026-07-15 08:49:10 <ncopa> i have moved build-edge-riscv64 back to the pioneer machine. Hopefully it will build faster now
2026-07-15 08:50:51 <ncopa> i had a package on the doormat when I got home from Berlin the last Sunday. it had a Spacemit K3 pico itx box. I'm trying to boot the vendor kernel now
2026-07-15 08:50:56 <mps> lets see
2026-07-15 13:26:33 <mps> algitbot: retry master
2026-07-16 08:26:20 <ncopa> the spacemit K3 is an interesting machine. it has 2 cpus, one x100 with 8 cores, and one a100 with 8 cores
2026-07-16 08:26:48 <ncopa> CPU 0–7:   X100, 2.4 GHz
2026-07-16 08:26:48 <ncopa> CPU 8–15:  A100, 2.0 GHz
2026-07-16 08:26:56 <ncopa> nproc gives 8
2026-07-16 08:27:09 <ncopa> which means I can only compile kernel with make -j8
2026-07-16 08:27:27 <ncopa> what is interesting is that the vector length is different
2026-07-16 08:28:11 <ncopa> alpine-k3:~$ ./show-vlen
2026-07-16 08:28:11 <ncopa> VLEN: 256 bits
2026-07-16 08:28:44 <ncopa> alpine-k3:~$ sh -c 'echo $$ > /proc/set_ai_thread; exec ./show-vlen'
2026-07-16 08:28:44 <ncopa> VLEN: 1024 bits
2026-07-16 08:29:42 <ncopa> so I can run normal workloads on the a100 cores, which are a bit slower (2.0 GHz), but has 1024 vlen bits
2026-07-16 08:57:17 <ncopa> im not sure how we best use this for alpine builder. maybe we could use the X100 for builder lxc, and the A100 for CI in docker?
2026-07-16 09:17:11 <mps> there was a patch on lkml to enable A100 within kernel to be used as 'normal' cpus but it is rejected. And i think wrongly rejected
2026-07-16 09:19:21 <ncopa> i think the problem is that you cannot really move workloads across cpu cores with different vector lengths
2026-07-16 09:19:29 <ncopa> do you have a link to the lkml patch?
2026-07-16 09:19:35 <mps> A100 is intended to be used for AI (phew) and because this have big vector lenght
2026-07-16 09:20:33 <mps> > ncopa| do you have a link to the lkml patch? - no, but will try to find it
2026-07-16 09:28:33 <ncopa> yes, I understand the bigger vector length for AI purpose. But I think there are other workloads that may benefit, like compression, and crypto. maybe even memset (if we add rvv implementation to musl libc)
2026-07-16 09:29:00 <ncopa> image processing may also benefit from big vector length
2026-07-16 09:30:30 <mps> ofc, you are right
2026-07-16 09:31:00 <ncopa> in any case I have a vendor kernel working for k3, for now. I think we should use the linux-stable once 7.2 is out. there are only a handful of patches for k3 support
2026-07-16 09:31:21 <ncopa> at that point we have mainline kernel for k1 and k3
2026-07-16 09:31:26 <ncopa> which would be great
2026-07-16 09:31:30 <mps> but marketing say 'for AI' :)
2026-07-16 09:31:48 <ncopa> yeah, I figure that is what people what to use it for
2026-07-16 09:32:35 <mps> as wrote earlier K1 will be usable for builder with 7.2 imo
2026-07-16 09:32:44 <ncopa> yes, I saw that
2026-07-16 09:33:09 <ncopa> you also posted a kernel, which I havent been able to test yet
2026-07-16 09:33:44 <mps> for K3 there are patches on lkml by applying them probably 7.2 would work
2026-07-16 09:34:51 <ncopa> yes, those: https://github.com/spacemit-com/linux/wiki#k3-soc
2026-07-16 09:35:06 <mps> though maybe plain 7.2 could work. try to compile it and try to boot to see what works
2026-07-16 09:35:34 <mps> https://lore.kernel.org/spacemit/
2026-07-16 09:36:01 <mps> have patches mostly for K3
2026-07-16 09:37:24 <ncopa> UFS and PCIe are missing from the 7.2 kernel, so 7.2 will not work out-of-the-box
2026-07-16 09:37:58 <ncopa> we'd need the UFS and PCIe patches, so we can boot (from UFS) and run from  NVMe
2026-07-16 09:38:17 <ncopa> but I think the number of patches are manageable. which is nice
2026-07-16 09:38:47 <ncopa> btw, i took ~1 hour to build the 6.18 vendor kernel for k3 on k3
2026-07-16 10:03:54 <mps> pico-itx need ufs, milk-v jupiter 2 should be able to boot from flash
2026-07-16 10:04:33 <mps> 1 hour, not fast but also not slow. good
2026-07-16 13:49:53 <ncopa> mps: I tried to boot https://dev.alpinelinux.org/~mps/riscv64/spacemit-k1.img.xz on my orangepi rv1, but it just stopped after "Starting kernel ...  "
2026-07-16 13:56:07 <ncopa> same happens with the spacemit-rv2.img
2026-07-16 13:56:28 <ncopa> i wodner if the debug UART is the ttyS0 or if ther eis something else going on
2026-07-16 14:07:56 <mps> ncopa: nobody confirmed to me that it works on orangepi rv2 (i guess you mean this and not rv1), so i don't know what is problem
2026-07-16 14:09:59 <mps> my friend tried spacemit-rv2.img but he is not patient enough (i would say impatient) and didn't gave me useful feedback
2026-07-16 14:11:33 <mps> but spacemit-rv2.img is just quick try and i'm not sure if it works on RV2
2026-07-16 14:12:49 <mps> only sure that spacemit-k1.img works on banapi-f3 and musebook
2026-07-16 14:17:20 <mps> on RV2 problem could be in eeprom, i.e. maybe wrong DTB is in eeprom written
2026-07-16 14:19:02 <mps> if you break u-boot and look what is is there and add this as parameter to extlinux.conf to 'fdt' directive could help
2026-07-16 14:23:47 <mps> also, maybe this patch is needed to u-boot-spacemit https://github.com/pyavitz/debian-image-builder/blob/feature/patches/uboot/v2022.10/spacemit-k1/006-orangepi-rv2-r2s-fit.patch
2026-07-16 15:22:31 <ncopa> Retrieving file: /dtbs-k1x/spacemit/k1-x_orangepi-rv2.dtb
2026-07-16 15:23:26 <ncopa> could also be as simple as serial console driver missing
2026-07-16 16:21:45 <mps> uh, xunlong don't use same serial chip as other k1 boards?
2026-07-16 16:22:18 <mps> i thought serial interface is in SoC
2026-07-16 16:25:56 <ncopa> i have no idea. just a wild guess in the dark
2026-07-16 18:00:25 <mps> we have little feedback from users and not only for riscv64
2026-07-17 04:15:35 <Guest9885> It's bit known issue, some people used distcc to use both type of CPUs
2026-07-17 04:15:53 <Guest9885> this is bit useful
2026-07-17 04:15:55 <Guest9885> https://github.com/brucehoult/k3_ai
2026-07-17 04:18:04 <Guest9885> Problem is A100 RVV is sometimes even slower then X100 scalar
2026-07-17 04:18:20 <Guest9885> and A100 doesn't have H extension so it's not RVA23
2026-07-17 12:05:00 <ncopa> distcc is a nice idea
2026-07-17 12:08:25 <ncopa> k3_ai is a nice utility
2026-07-17 12:10:08 <ncopa> well, I suppose distcc is overkill
2026-07-17 12:12:06 <ncopa> a tiny CC wrapper for the k3_ai utility, which exec either `gcc` or `ai gcc`
2026-07-17 12:40:30 <ncopa> looks like current u-boot 2026.07 has support for bananapi-f3 board
2026-07-17 12:48:17 <mps> but still need FSBL from vendor u-boot or use external binary blob instead
2026-07-17 12:49:17 <mps> and is renamed from bananapi-f3 to k1-spacemit
2026-07-17 12:50:09 <mps> I compiled it two months ago using patches
2026-07-17 14:10:41 <mps> actually first version is merged in 2026.01
2026-07-18 04:42:33 <ikke> gst-plugins-bad is failing on riscv64 due to segfaults:
2026-07-18 04:42:35 <ikke> ninja: job terminated due to signal 11: /usr/bin/orcc --include glib.h --header -o gst/videofilters/gstscenechangeorc.h ../gst/videofilters/gstscenechangeorc.orc
2026-07-18 04:42:37 <ikke> ninja: job terminated due to signal 11: /usr/bin/orcc --include glib.h --implementation -o gst/videofilters/gstscenechangeorc.c ../gst/videofilters/gstscenechangeorc.orc
2026-07-18 15:28:44 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/work_items/18343
2026-07-24 08:21:19 <mps> algitbot: retry maste
2026-07-24 08:21:25 <mps> algitbot: retry master
2026-07-25 08:19:10 <mps> K3 patch for display driver https://lore.kernel.org/spacemit/20260725063628.3499-1-codykang.hk@gmail.com/T/#t
2026-07-25 08:19:18 <mps> \o/
2026-07-26 17:19:06 <mps> I cannot ssh to mps-edge-x86_64. probably sshd should be restarted.
2026-07-26 17:19:27 <mps> ikke: are you around to restart it
2026-07-26 21:01:18 <ikke> mps: I've restarted it
2026-07-27 06:32:51 <mps> ikke: thank you dear sir
2026-07-27 06:39:24 <mps> I think to use runit supervisor for sshd on alpine for my dev containers
2026-07-27 06:44:55 <mps> new binutils https://lists.gnu.org/archive/html/info-gnu/2026-07/msg00006.html have support for more riscv extensions
2026-07-27 06:57:38 <mps> huh, crystal cannot be built on X86_64 dev lxc https://tpaste.us/84eK
2026-07-27 06:57:56 <mps> 'Unhandled exception: Arithmetic overflow (OverflowError)'
2026-07-27 07:14:26 <mps> on my 'private' linode it builds
2026-07-28 10:58:51 <mps> where we install fish completions
2026-07-28 11:01:55 <mps>  /usr/share/fish/vendor_completions.d/?
2026-07-28 11:16:53 <ikke> You could check the default split function in abuild
2026-07-28 11:23:31 <mps> you mean this 'warning2 "fish completions for programs should be located in /usr/share/fish/vendor_completions.d"' 
2026-07-28 11:24:38 <mps> ok, got hint
2026-07-28 11:24:44 <mps> thanks
2026-07-28 18:44:15 <mps> algitbot: retry master
2026-07-29 14:49:07 <mps> testing/php82-8.2.32-r0 fails on tests on rv64 builder
2026-07-29 15:09:56 <ikke> yes
2026-07-29 17:41:50 <mps> 308 pkg needs rebuild with perl upgrade to 5.44.0
2026-07-29 18:32:04 <mps> can be abuild-rootbld used to build one merge request with multi commits
2026-07-29 18:32:44 <mps> want to test perl before push 300+ pkgs to CI
2026-07-29 18:52:05 <mps> `abuild rootbld` gives 'bwrap: Can't mount proc on /newroot/proc: Operation not permitted' on dev lxc
2026-07-29 18:54:29 <mps> so, push to and see what will happen?
2026-07-29 18:54:41 <mps> to CI*
2026-07-29 18:58:09 <mps> mhh, always can be stopped if something goes bad
2026-07-30 09:48:45 <iggy> when will perl die...
2026-07-30 09:51:14 <iggy> it's going to be cobol in 10 years... some randos are going to write articles about how nobody knows perl anymore, then people that know it are going to come out of the woodwork, then everybody is going to realize it's cheaper to replace it than deal with and pay the people that know it
2026-07-30 10:42:38 <mps> I hope python is die first, i.e. before perl
2026-07-30 10:42:45 <mps> :)
2026-07-30 10:54:26 <mps> hm, s/is/will/
2026-07-30 10:55:06 <mps> and all stupid langs ;)