2025-08-01 11:08:13 <haesbaert> I can't get a starfive visionfive2 to boot with the image provided in: https://arvanta.net/alpine/alpine-on-visionfive/, it works fine with the provided debian image so at least I know the board is not bricked. Red led is on, green never comes up(I think it's the kernel that hearbeats it), no output on HDMI, haven't tried hooking up a serial
2025-08-01 11:08:26 <haesbaert> Am I missing something? Do I need to flash something else?
2025-08-01 11:26:42 <mps> haesbaert: kernels don't have hdmi drivers
2025-08-01 11:27:02 <mps> you should use serial console
2025-08-01 11:27:26 <mps> debian is patched to have hdmi
2025-08-01 11:28:38 <mps> we don't ship patched kernels, except for some small fixes
2025-08-01 11:28:45 <haesbaert> oh ok, but shouldn't the led blink green?
2025-08-01 11:29:36 <mps> it depends how it is configured, and I forgot how
2025-08-01 11:30:09 <mps> but I remember it have light on it
2025-08-01 11:30:29 <haesbaert> oh cool, so it might have been working all the time and I just didn't notice, do you happen to remember if it tries DHCP? I need to figure where my serial cable is
2025-08-01 11:32:18 <mps> no, it doesn't. it is simple alpine and have to be configured after boot, like other alpine install media
2025-08-01 11:33:16 <mps> best method is to use serial console
2025-08-01 11:34:33 <mps> but you can change some thing on flashed mmc card on another machine and then boot on board
2025-08-01 11:35:14 <haesbaert> do you happen to have one at hand? knowing if the green led blink would be helpful, but I'll find my serial adapter anyway
2025-08-01 11:36:30 <mps> "have one at hand"? what you mean to say
2025-08-01 11:38:20 <haesbaert> apologies, do you have a booted starfive2 board at hand? to check if the led blinks green
2025-08-01 11:41:27 <mps> i use it as home router but disabled led after boot
2025-08-01 11:43:31 <mps> it is annoying to me
2025-08-01 11:48:10 <haesbaert> meh I need to order a uart usb adapter
2025-08-01 11:48:48 <mps> it is cheap, 2-3 euro
2025-08-01 11:49:17 <haesbaert> ack, my adapter has is for those old rj45, I think last time I used was on a sun blade something
2025-08-01 11:49:22 <haesbaert> s/has//
2025-08-01 11:49:22 <mps> and nearly all electronic shop have them
2025-08-01 11:50:41 <mps> usb pl230x is everywhere
2025-08-01 11:51:40 <mps> pl2303
2025-08-01 11:52:11 <haesbaert> great, that's just the one I was about to order: https://www.berrybase.de/usb-ttl-uart-rs232-adapterkabel-mit-pl2303hx-chipsatz
2025-08-01 11:52:49 <mps> yes, i have dozens of them
2025-08-01 11:54:10 <haesbaert> hah, maybe that will motivate me to make a cu(1) port, is minicom still the standard in linux?
2025-08-01 11:54:37 <mps> i use screen mostly
2025-08-01 11:55:43 <mps> sreen is most comfortable for me
2025-08-01 11:56:05 <haesbaert> ack, I'm coming back to linux now, been using cu for the last decade or so
2025-08-01 11:56:24 <haesbaert> I remember minicom being a bit annoying
2025-08-01 11:56:26 <mps> #!/bin/sh
2025-08-01 11:56:26 <mps> tty=$(ls /dev/ | grep ttyUSB)
2025-08-01 11:56:26 <mps> screen -S rb -U -A -O -T screen-256color -fn /dev/${tty} 115200
2025-08-01 11:56:26 <mps> echo $tty
2025-08-01 11:56:38 <haesbaert> oh neat, I'll steal that
2025-08-01 11:59:27 <haesbaert> ordered the uart, will likely bother you again sometime next week.
2025-08-01 12:01:13 <mps> np, but maybe someone else also could help
2025-08-01 12:01:48 <haesbaert> sure, I think this will work out though, I wrongly assumed there would be a hdmi signal
2025-08-01 12:02:34 <mps> there is no hdmi in mainline kernel for jh7110 afaik
2025-08-01 12:02:57 <mps> nor GPU
2025-08-01 12:03:09 <ikke> I use tio nowadays for serial 
2025-08-01 12:03:31 <mps> though maybe simpledrm could work
2025-08-01 12:05:29 <haesbaert> so this board boots with mainline linux-lts?
2025-08-01 12:05:56 <mps> ncopa told so
2025-08-01 12:06:33 <mps> but I still use linux-starfive pkg
2025-08-01 12:06:43 <haesbaert> any special reason?
2025-08-01 12:07:27 <mps> it is 6.15 and trimmed little
2025-08-01 12:08:24 <mps> optimized somewhat for jh7110
2025-08-01 12:09:23 <mps> will be AFK some time
2025-08-01 12:11:38 <haesbaert> ikke: I'll give it a shot as well
2025-08-05 14:03:19 <haesbaert> mps: heya just to let you know it worked out :). I had to change the boot mode to emmc(perhaps worth adding a note to the article), and had to run fsck on root, it had one orphaned inode. 
2025-08-05 14:25:07 <mps> haesbaert: no, it boot by default from mmc. maybe u-boot env variables are changed in your board
2025-08-05 14:36:35 <haesbaert> when it was in SPI mode for me the ftdfile variable was at least incorrect, so you're likely right
2025-08-05 14:37:16 <haesbaert> but it was also booting an older uboot, does the board also store a boot in its own flash?
2025-08-05 15:21:29 <mps> haesbaert: i wrote short about u-boot on board https://arvanta.net/alpine/u-boot-visionfive2-alpine/
2025-08-05 15:23:40 <mps> u-boot for it mainlained before one year so on alpine it is aports, u-boot-starfive pkg
2025-08-05 15:24:00 <mps> i.e. apk add u-boot-starfive
2025-08-05 15:24:28 <mps> and flash it to SPI flash
2025-08-05 15:25:33 <mps> it is in /usr/share/u-boot/starfive_visionfive2/
2025-08-05 15:26:17 <mps> oh, I should update my guide
2025-08-05 15:28:21 <mps> it is written before all is mainlained for VF2
2025-08-05 15:37:25 <haesbaert> oh nice I'll have a read, I though the uboot env was stored in some internal flash?
2025-08-05 15:37:38 <haesbaert> when I changed the jumper to boot from emmc, I now hit the correct thing:
2025-08-05 15:37:52 <haesbaert> U-Boot SPL 2024.01 (Jan 20 2024 - 10:52:04 +0000)
2025-08-05 15:37:52 <haesbaert> Trying to boot from MMC2
2025-08-05 15:37:52 <haesbaert> U-Boot 2024.01 (Jan 20 2024 - 10:52:04 +0000)
2025-08-05 15:37:52 <haesbaert> DDR version: dc2e84f0.
2025-08-05 15:38:23 <haesbaert> this booting from a sdcard
2025-08-05 15:39:24 <haesbaert> but if I put the jumper back on SPI I get:
2025-08-05 15:39:25 <haesbaert> U-Boot SPL 2021.10 (Feb 28 2023 - 21:44:53 +0800)
2025-08-05 15:39:28 <haesbaert> Trying to boot from SPI
2025-08-05 15:39:31 <haesbaert> ...
2025-08-05 15:39:45 <haesbaert> U-Boot 2021.10 (Feb 28 2023 - 21:44:53 +0800), Build: jenkins-VF2_515_Branch_SDK_Release-31
2025-08-05 15:40:32 <haesbaert> ^ so that's the uboot on the spi flash I assume
2025-08-05 15:41:32 <haesbaert> and when I boot from spi, env is different:
2025-08-05 15:41:33 <mps> default u-boot on flash is old
2025-08-05 15:41:45 <haesbaert> StarFive # env print fdtfile
2025-08-05 15:41:45 <haesbaert> fdtfile=starfive/starfive_visionfive2.dtb
2025-08-05 15:41:58 <haesbaert> ack, but from what I understood from you, it should still boot on the old uboot?
2025-08-05 15:42:08 <mps> but you can update it on latest
2025-08-05 15:42:31 <haesbaert> I'm happy with the emmc boot, I'm just puzzled why I needed it
2025-08-05 15:42:55 <mps> yes, old works but it is not 'automatic'
2025-08-05 15:44:13 <mps> and has some problems
2025-08-05 15:45:13 <mps> first thing users of board to do is upgrade u-boot
2025-08-05 15:45:43 <mps> should*
2025-08-05 15:46:47 <mps> old doesn't set correctly RAM on boards with more than 4GB
2025-08-05 15:49:24 <mps> will be AFK for some time
2025-08-05 16:10:51 <haesbaert> got it, thanks for working on this again :)
2025-08-05 18:59:27 <mps> haesbaert: tbh I'm bad in helping because I don't know english well
2025-08-05 19:00:14 <mps> because this my 'guides' are short and basic, I'm bad writer
2025-08-05 20:08:12 <haesbaert> worked for me, and I know nothing of these small boards
2025-08-07 11:58:50 <mps> algitbot: retry master
2025-08-07 12:00:00 <ncopa> i bought a orangepi rv2. got board delivered yesterday and the case today. its really cute
2025-08-07 12:00:23 <ncopa> Now I need to figure out how to boot it. I suppose the spacemit kernel *should* work
2025-08-07 12:02:47 <mps> my local linux-k1x should. if you want to try i can upload it
2025-08-07 13:04:57 <achill> looks like rebuilding go on riscv64 fails now, probably because of gcc15: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1964148
2025-08-07 13:09:01 <achill> oh sweet, already known https://go-review.googlesource.com/c/go/+/668276
2025-08-07 15:59:34 <ncopa> mps: I am more intersted in figuring out how to build it myself. where do you get the sources from?
2025-08-07 16:00:17 <ncopa> i also wonder if we could have same kernel build for both banana pi bpi-f3 and orangepi rv2.
2025-08-07 16:00:25 <ncopa> would prefer not have more kernel flavors
2025-08-07 16:13:24 <mps> ncopa: https://github.com/jmontleon/linux-bianbu
2025-08-07 16:14:55 <ncopa> ok
2025-08-07 16:15:03 <mps> it have orangepi r2s dts so I guess it could work but i didn't tested because i don't have this board
2025-08-07 16:15:30 <mps> it work on bpif3 fine
2025-08-07 16:15:38 <ncopa> ok. its the same kernel I current am working with
2025-08-07 16:15:54 <ncopa> I have a weird build issue with missing sched_setscheduler
2025-08-07 16:17:47 <mps> i can post config and apkbuild if you want to see them
2025-08-07 16:18:08 <ncopa> config could be interesting
2025-08-07 16:20:27 <mps> pkg is here https://dev.alpinelinux.org/~mps/riscv64/linux-k1x-6.15.8-r0.apk
2025-08-07 16:20:45 <mps> you can extract config from it
2025-08-07 16:21:30 <ncopa> what is the kernel config based on? The config is a maze to get it compiled
2025-08-07 16:22:32 <ncopa> I have spent a few days on a config for tps://github.com/jmontleon/linux-bianbu that builds
2025-08-07 16:22:41 <mps> it is my 'try and error and fix' effort
2025-08-07 16:23:04 <ncopa> did you bump into sched_setscheduler missing symbol?
2025-08-07 16:23:46 <mps> but most is from my first try of linux-spacemit on which you based current in aports
2025-08-07 16:24:25 <mps> no, and idk if i enabled it
2025-08-07 16:26:02 <mps> i had one problem, reported it and upstream fixed it very fast https://github.com/jmontleon/linux-bianbu/issues/12 (mpstan is me)
2025-08-08 16:45:27 <ncopa> meh I broke my bananapi bpi-f3 with my linux-spacemit-6.15.9 kernel
2025-08-08 16:45:56 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88417
2025-08-08 16:47:10 <ncopa> ** File not found /boot/dtbs-spacemit/spacemit/k1-bananapi-f3.dtb **
2025-08-08 17:05:03 <ncopa> the ../arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts is there, but it was not installed for some reason
2025-08-08 17:19:12 <mps> ncopa: try 'fdt /dtbs-k1x/spacemit/k1-x_deb1.dtb'
2025-08-08 17:21:09 <mps> ok, adjust path to your
2025-08-08 17:28:12 <ncopa> i had one config missing
2025-08-08 17:28:49 <ncopa> ARCH_SPACEMIT something
2025-08-08 17:33:38 <ncopa> good thing I had the old image around
2025-08-08 18:20:00 <ncopa> mps: do you know how to boot a compressed kernel with u-boot?
2025-08-08 18:20:05 <ncopa> Retrieving file: /boot/dtbs-spacemit/spacemit/k1-bananapi-f3.dtb
2025-08-08 18:20:05 <ncopa> kernel_comp_addr_r or kernel_comp_size is not provided!
2025-08-08 18:35:38 <mps> isn't kernel_comp_addr_r set in u-boot
2025-08-08 18:37:38 <mps> I don't have access now to board to check
2025-08-08 18:38:43 <mps> oh wait
2025-08-08 18:39:31 <mps> iirc u-boot for bpif3 can't load compressed kernel
2025-08-08 18:40:15 <mps> ncopa: ^
2025-08-08 18:40:46 <mps> try to build non compressed kernel
2025-08-08 21:29:49 <ncopa> ok
2025-08-08 21:30:19 <ncopa> I got it booting now, but it does not find the SD card storage. I probably disabled the driver?
2025-08-09 12:10:50 <ncopa> the linux-spacemit 6.15.9 kernel works on orangepi rv2, kinda
2025-08-09 12:10:54 <ncopa> Linux localhost 6.15.9-0-spacemit #1-Alpine SMP PREEMPT_DYNAMIC 2025-08-08 18:23:51 riscv64 Linux
2025-08-09 12:10:54 <ncopa> ky x1 orangepi-rv2 board
2025-08-09 12:10:54 <ncopa> localhost:~# uname -a
2025-08-09 12:10:54 <ncopa> localhost:~# echo $(cat /proc/device-tree/model )
2025-08-09 12:18:58 <haesbaert> are the ethernet chips dwmac?
2025-08-09 12:33:54 <ncopa> [   61.521865] emac_phy_connect:  eth1: attached to PHY (UID 0x4f51e91b) Link = 0
2025-08-09 12:34:08 <ncopa> [   61.542282] k1x_emac cac81000.ethernet eth1: registered PTP clock
2025-08-09 12:34:08 <ncopa> [   61.547952] k1x_emac cac81000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
2025-08-09 12:56:43 <haesbaert> hm something else
2025-08-09 14:12:11 <mps> so, orangepi-rv2 boots. good to know
2025-08-09 15:21:13 <haesbaert> I was considering getting one, the sf2 chokes at routing 1gbit
2025-08-11 07:54:06 <ncopa> chokes?
2025-08-11 09:07:35 <haesbaert> I think it just doesn't have enough cpu power, ksoftirqd0 hogs cpu0 at 100%, and I get around 880mbit. This is when the cpu frequency is at 1.5ghz, before it goes up I'm stuck on half of that.
2025-08-11 09:11:33 <haesbaert> The ethernet chips seem to poll at 2000hz, I haven't checked the driver but maybe there are some gains to be had there.
2025-08-11 11:08:06 <ncopa> do you have iptables rules?
2025-08-11 11:28:32 <ncopa> bah. with 6.16.y kernel the MMC block device does not even show up in kernel
2025-08-11 11:28:53 <ncopa> with 6.15.9 it would show up after 10s
2025-08-11 11:33:51 <ncopa> on orangepi rv2
2025-08-11 12:08:22 <haesbaert> I have like 4 iptables rules and they're stateful
2025-08-11 12:08:44 <haesbaert> do you know which kernel canonical is shipping on the orangepi rv2?
2025-08-11 17:36:15 <Ariadne> haesbaert: have you tried irqbalance?  it can help with softirqs too
2025-08-12 09:53:15 <haesbaert> Ariadne: I gave it a shot, it wasn't changing anything so I manually changed the affinity of the incoming interface (where the load is supposed to be), this worked, all the load is now on cpu1 (where the incoming interface is pinned), and cpu0 is virtually idle, yet still getting interrupts to (likely) release the tx descriptors.
2025-08-12 12:14:07 <haesbaert> I might have some luck with rps though
2025-08-12 12:31:11 <haesbaert> running the network stack in another cpu with rps squeezed me a bit more (~40mbit/s+), but it seems really all the load is in popping the packets from the RX ring
2025-08-14 19:04:50 <ncopa> I have a kernel that boots orangepi rv2 now
2025-08-14 19:04:55 <ncopa> 6.16.0 kernel
2025-08-14 19:05:11 <ncopa> but it does not boot bananapi bpi-f3 fomr some reason :-/
2025-08-14 19:05:42 <ncopa> at least no from SD card
2025-08-20 11:22:15 <mps> algitbot: retry master
2025-08-20 11:37:44 <ncopa> mps: would you be ok with achill taking over linux-tools? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/87821
2025-08-20 12:02:43 <mps> ncopa: ok
2025-08-20 12:05:00 <ncopa> could you add a comment there or a thumbs up?
2025-08-20 12:07:18 <mps> ok
2025-08-20 12:07:29 <mps> will do later
2025-08-20 12:08:12 <mps> ncopa: you are not at #alpine-arm?
2025-08-20 12:12:45 <mps> dosbox-staging should be removed from distfiles to be refreshed with new upstream which changed checksum
2025-08-20 12:21:11 <mps> algitbot: retry master
2025-08-20 12:22:06 <achill> mps: just update the tarball name in the APKBUILD
2025-08-20 12:22:13 <achill> so the builder redownkloads it
2025-08-20 12:22:19 <achill> but please look at the changes first
2025-08-20 12:22:32 <achill> (with diffoscope or something works pretty well)
2025-08-20 12:23:39 <mps> what is wrong with $pkgname-$pkgver.tar.gz
2025-08-20 12:35:49 <ikke> mps: The issue is that that file is cached at distfiles.a.o, so the builders will keep using the old version
2025-08-20 12:35:55 <ikke> But I can rename it as well
2025-08-20 12:48:20 <mps> ikke: strange, on CI i had to refresh checksum because it failed but on builders it failed again. so CI don't use cached distfiles?
2025-08-20 12:48:31 <ikke> correct
2025-08-20 12:49:05 <mps> and how to 'work' with this?
2025-08-20 12:50:18 <ikke> I'll rename the file on distfiles
2025-08-20 12:50:55 <mps> thanks
2025-08-20 12:51:55 <ikke> wdone
2025-08-20 12:53:50 <mps> nice, it works now
2025-08-20 12:57:14 <achill> the draemy goal would be that upstreams stops to change tarballs
2025-08-20 12:57:27 <achill> but thats unrealistic especially with our package count
2025-08-20 12:58:54 <mps> or cache all of them (but not enough infrastructure and man power for this)
2025-08-20 12:59:15 <ikke> We _do_ want to catch when upstream has changed things though
2025-08-20 12:59:22 <achill> yeah
2025-08-20 12:59:40 <ikke> So, for that, and other reasons, CI does not use distfiles
2025-08-20 12:59:47 <mps> ikke: that is better imo
2025-08-20 13:00:28 <mps> I always clean my local cache 
2025-08-21 19:13:08 <mps> algitbot: retry master
2025-08-27 17:24:42 <ikke> mps: are we still using the custom visionfive-starfive kernel from https://gitlab.alpinelinux.org/nmeum/alpine-visionfive?
2025-08-27 18:17:03 <mps> ikke: i use it and iirc some other people. because this i hesitate to remove it
2025-08-27 18:17:28 <ikke> sure, then I'll move the container that builds those kernels
2025-08-27 18:18:01 <mps> no, i mean linux-starfive. sorry
2025-08-27 18:18:23 <mps> https://gitlab.alpinelinux.org/nmeum/alpine-visionfive is not needed imo
2025-08-27 18:19:02 <mps> sorry for misunderstanding 
2025-08-27 18:19:17 <ikke> No worry
2025-08-27 18:19:30 <ikke> So the kernel is now in aports, so we no longer need to build it separately
2025-08-27 18:19:48 <mps> yes, right
2025-08-27 18:25:12 <ikke> jj
2025-08-27 18:27:27 <mps> ikke: what 'jj' means?
2025-08-27 18:27:37 <ikke> nothing, was an accident
2025-08-27 18:27:45 <mps> ah :)
2025-08-30 18:35:11 <mps> linux-starfive 6.16.3 and linux-jh7100 6.16.4are pushed to builders
2025-08-30 18:35:37 <mps> /4are/4 are/