2024-09-01 11:18:38 last evening I fixed my BPI-F3 with 2GB RAM, now it can boot from mmc (sd card) 2024-09-01 13:19:32 What did you do to fix it? i remember you said the software is only available for windows and x86_64 glibc 2024-09-01 13:39:59 cely: right. Last evening husband of daughter gave me his windows machine and I installed this software (titantools for win) on it and with 'try and error' method I've got flash needed parameter (ddr_num_cs) to work 2024-09-01 13:40:54 previous tries with debian didn't worked 2024-09-01 13:41:41 Ok, thanks for the info. Is the software still in Chinese with no English translation? 2024-09-01 13:45:51 only Chinese 2024-09-01 13:46:31 maybe there is English (or other langs version) but I can't find it 2024-09-01 13:48:51 Ok 2024-09-02 07:13:53 last night with armbian kernel and u-boot I've booted alpine userspace on bpi-f3 2024-09-02 07:14:14 so some progress on this strange SoC/SBC 2024-09-02 07:16:16 That's good news 2024-09-02 07:16:27 Just wondering, how is it strange? 2024-09-02 07:18:41 partition table layout is something I don't understand yet. And flashing u-boot, opensbi and some essential boot files is not documented well 2024-09-02 07:19:14 Ok 2024-09-02 07:19:37 their u-boot is 2022.10, so very outdated 2024-09-02 07:21:54 right now I'm trying to build kernel (alpine apk) for it 2024-09-02 07:25:39 Thanks for working on this 2024-09-02 07:26:56 cely: you have this board? 2024-09-02 07:29:18 Yes, but i'm a bit worried after seeing how much trouble you're going through to get it working 2024-09-02 07:31:14 if you have version with 4 or 8 GB RAM it should go easier. Armbian and their bianbu images boots fine 'out-of-the-box' 2024-09-02 07:31:51 but I want to get all tools and boot things build on alpine 2024-09-02 07:32:07 Ok 2024-09-02 07:32:14 in my test alpine userspace also works fine 2024-09-02 07:34:19 main problem is that the documentation is sparse 2024-09-02 07:40:18 I bought a 4GB ver last week. 2024-09-02 07:40:20 I found someone is working at booting 6.6 kernel in Gentoo, their experience might be helpful: https://forum.banana-pi.org/t/gentoo-on-bpi-f3/18389 2024-09-02 07:44:06 Also a spacemit bianbu image build guide: https://bianbu-linux.spacemit.com/en/development_guide/boot/ (chinese only) 2024-09-02 07:45:47 lindsay: thanks for gentoo url 2024-09-02 07:45:57 mps: If you have any problem about Chinese, be free to contact me. 2024-09-02 07:46:12 I looked bianbu guide but don't understand chinese 2024-09-02 07:46:31 lindsay: you read chinese? 2024-09-02 07:48:52 yes, I and qaqland are Chinese, I am sure he is also willing to help you. 2024-09-02 07:53:07 nice 2024-09-02 08:00:53 I am working at licheepi 4a currently, and have booted alpine linux 5.10. 2024-09-02 08:00:55 https://moe.reisen/@lindsay/statuses/01J44NZCW0CWRM0AZAMBN30NAH 2024-09-02 08:00:57 Maybe I could publish a linux 6.6 image for licheepi4a days later 2024-09-02 08:01:42 licheepi4a is jh7110? 2024-09-02 08:02:06 no, th1520 2024-09-02 08:03:05 oh, my memory is fading 2024-09-02 08:12:50 I heard k1's out-of-tree kernel is awful. They put all changes in one commit. 2024-09-02 08:12:53 https://github.com/BPI-SINOVOIP/pi-linux/commits/linux-6.1.15-k1/ 2024-09-02 08:25:39 I've built their 6.6.36 but armbian u-boot can't boot it 2024-09-02 10:19:07 lindsay: ah, now remember that I already read earlier https://forum.banana-pi.org/t/gentoo-on-bpi-f3/18389 2024-09-02 10:21:01 I've to this, Starting kernel ... => [ 0.000000] Linux version 6.6.36-0-bpi-f3 (mps@mps-edge-riscv64) (gcc (Alpine 14.2.0) 14.2.0, GNU ld (GNU Binutils) 2.43.1) #1-Alpine SMP PREEMPT Mon, 02 Sep 2024 07:00:53 +0000 2024-09-02 10:21:13 but some drivers crashes 2024-09-02 11:36:47 fJnGEDNIEBRgCueGRdCkJbk 2024-09-02 11:37:18 sorry, I touched my yubikey by mistake 2024-09-02 11:38:41 oh nice, I thought your cat walked on keyboard :) 2024-09-02 11:38:42 right, it doesnt make sense in any language i know. 2024-09-02 11:39:05 clandmeter: yubikey lang? 2024-09-02 18:41:18 fastfetch on bpi-f3 https://tpaste.us/5XOM 2024-09-02 23:07:48 \o/ 2024-09-03 05:53:41 it is with armbian kernel 2024-09-03 05:55:25 vendor kernel is buggy and build often fails if some options/drivers not set or in some cases if they set 2024-09-03 05:56:01 have to find how is armbian kernel built 2024-09-03 05:57:36 but, ethernet, wifi, sensors, usb works. I didn't tried sound and hdmi 2024-09-04 16:30:19 for test I made access point with bpi-f3. works but not so fast as I expected 2024-09-09 19:32:42 got kernel apk pkg for bananapi-f3 => Linux localhost 6.6.36-0-bpi-f3 #1-Alpine SMP Mon, 09 Sep 2024 19:18:37 +0000 riscv64 Linux 2024-09-09 19:33:04 very hackish but it works 2024-09-09 19:54:13 how we can force mkinitfs to add firmware to initramfs 2024-09-09 19:56:30 Do you know what firmware? 2024-09-09 19:57:25 You can add a *.file file in there listing the paths to the firmware, then add that feature to the config 2024-09-09 20:04:09 ikke: it is not packaged for alpine, it is remote processor firmware for spacemit (bpi-f3), esos.elf 2024-09-09 20:04:29 and not sure is it free to download 2024-09-09 20:04:59 ikke: could you point me to example if we have it somewhere for alpine 2024-09-09 20:05:49 Example of what? 2024-09-09 20:06:05 The features.d directory contains plenty if examples 2024-09-09 20:06:16 example of mkinitfs.conf with firmware 2024-09-09 20:06:38 yes, but all these are drivers 2024-09-10 08:26:13 now I created image for bpi-f3 which boots alpine. If someone wants to test it I can upload it to dev.a.o 2024-09-10 08:26:38 also I can put shell script which builds image 2024-09-10 08:27:39 put on net* 2024-09-10 20:05:57 hm, why mkinitfs don't want to install anything from /lib/firmware 2024-09-10 20:06:14 add to initramfs 2024-09-10 20:09:32 I guess you're right: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/mkinitfs.in#L138 2024-09-10 20:10:02 It seems to only include firmware that is in used by modules 2024-09-10 20:10:46 right, just reading local /sbin/mkinitfs 2024-09-10 20:10:58 this is bug I think 2024-09-10 20:11:42 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/155c5fa5816cc6d942e531d525493318ceae8fd6 2024-09-10 20:11:44 added 8 years ago 2024-09-10 20:12:02 and no one reported till now 2024-09-10 20:13:17 I guess because the autodetection works for most situations 2024-09-10 20:14:05 this should be reverted, at least 2024-09-10 20:14:52 Possibly only the `rm` line 2024-09-10 20:16:44 all 2024-09-10 20:16:53 to be safe 2024-09-10 20:17:53 this https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/155c5fa5816cc6d942e531d525493318ceae8fd6#dd2b8c5dc33fed21db477032ff4754c998dc6e5b_127_130 2024-09-10 20:17:59 And breaking existing setups that rely on auto detection? 2024-09-10 20:18:27 looks like it install firmware only checking modinfo results 2024-09-10 20:19:07 what if no one module have desired firmware in modinfo 2024-09-10 20:19:41 I lost two hours to find what could be issue 2024-09-10 20:20:02 If the directory is not removed, it should keep it if you manually specify it 2024-09-10 20:22:04 well, not sure because of 'for fname in "$FW" "$FW.zst" "$FW.xz"; do' 2024-09-10 20:22:32 and FW is set by modinfo 2024-09-10 20:23:33 It installs additional files returned by modinfo 2024-09-10 20:23:55 But that should not exclude you from manually specifying files, except, because of the `rm` line, they are removed 2024-09-10 20:24:55 I doubt but still didn't tested 2024-09-10 20:25:13 rm must be removed for sure 2024-09-10 20:42:26 ikke: you are right, remove rm line is enough 2024-09-10 20:46:56 but didn't helped me for problem I'm trying to solve 2024-09-10 20:47:48 can we use wget in APKBUILD to fetch firmware 2024-09-10 20:48:07 we can, but is it allowed 2024-09-11 12:51:40 ncopa: should we fix mkinitfs according to discussion above 2024-09-11 13:42:47 ok. please create an issue so i find the details when I look at it 2024-09-11 13:53:17 I already crated local fix, can create MR from it 2024-09-11 13:53:46 but I guess you want to change it in source 2024-09-11 13:53:59 so, probably issue is ok 2024-09-17 20:53:47 I've received my bananapi bpi-f3 development board 2024-09-17 20:53:53 https://docs.banana-pi.org/en/BPI-F3/Photo_BPI-F3 2024-09-17 20:59:40 ikke: nice. enjoy 2024-09-17 21:00:08 how much RAM it has 2024-09-17 21:00:30 16G 2024-09-17 21:00:57 my have only 2GB 2024-09-17 21:01:06 I haven't booted it yet 2024-09-17 21:01:12 Seems you have to flash it 2024-09-17 21:01:32 yes, I have image for sd card 2024-09-17 21:01:53 alpine ofc 2024-09-17 21:02:23 I'm using it as wifi access point for about one week 2024-09-17 21:03:12 also I have APKBUILD for kernel 2024-09-17 21:04:21 you can find it on my lxc on pioneer under /home/mps/aports-local/linux-bpi-f3 2024-09-17 21:05:19 tomorrow I can post all these if you want to try 2024-09-17 21:06:31 good night now 2024-09-18 06:43:27 is there some way to build a generic risc-v kernel? that works for starfive 2, bpi-3, and pioneer? 2024-09-18 06:47:58 pioneer is not upstream 2024-09-18 06:59:17 also, bpi-f3 is not and I guess will not be soon upstreamed 2024-09-18 07:00:12 for starfive V2 yesterday I enabled it in linux-edge, but didn't yet tested seriously 2024-09-18 07:03:04 btw, yesterday I also added loongarch64 flavor to linux-edge 2024-09-18 07:06:10 milk-v and spacemit vendors are not much active in upstreaming patches, while starfive was/is very good at this 2024-09-18 08:33:49 sophgo is active, which is what the pioneer is using (milkv) 2024-09-18 10:42:52 i got the banana pi board 2024-09-18 10:42:57 it is really cute 2024-09-18 10:43:36 16G mem 128G emmc? 2024-09-18 10:47:30 correct 2024-09-18 10:47:44 Did you get it to boot already? 2024-09-18 10:48:10 im assembling it. trying to find out where to connect the fan 2024-09-18 10:48:20 It goes on the list 2024-09-18 10:48:22 lid 2024-09-18 10:48:35 There are 4 screw holes there 2024-09-18 10:49:07 yes, but I was thinking where to plug it 2024-09-18 10:49:13 there is a 3 pin socket on the board 2024-09-18 10:49:23 a 2 pin-connector with fan next to it 2024-09-18 10:49:26 but the connector is only 2 pin 2024-09-18 10:50:30 I think you only need the left 2 pinds 2024-09-18 10:50:35 vcc and gnd 2024-09-18 10:59:46 looks like it can take power from usb-c 2024-09-18 11:04:08 what happens if I boot it? 2024-09-18 11:04:14 i suppose I need to flash it first? 2024-09-18 11:30:01 ncopa: if you want to boot straight to alpine I can upload image to dev.a.o 2024-09-18 11:32:45 what happens if I boot it without flashing anything? 2024-09-18 11:33:06 mps: how did you build the image? 2024-09-18 11:34:55 if not flashed it start flashing mode which you can use to manipulate eeprom data or flash emmc with fastboot 2024-09-18 11:35:34 you need to connect it via usb-c to do these things 2024-09-18 11:36:01 for image I've built I can post script 2024-09-18 11:36:19 also for kernel I can post APKBUILD 2024-09-18 11:36:51 I didn't yet got opensbi+u-boot built on alpine to boot 2024-09-18 11:37:31 my plan to work on these maybe on weekend if I find free time 2024-09-18 11:43:44 here is link to script I used to build image https://dev.alpinelinux.org/~mps/riscv64/create-bpi-f3-img.sh 2024-09-18 11:44:03 also kernel https://dev.alpinelinux.org/~mps/riscv64/linux-bpi-f3-6.6.36-r2.apk 2024-09-18 11:44:39 aport for kernel could upload later 2024-09-18 11:45:31 to build kernel I used their git repo and created linux tarball with 'git archive ...' 2024-09-18 11:50:21 ok, kernel aport is here https://dev.alpinelinux.org/~mps/riscv64/aport-linux-bpi-f3/ 2024-09-18 11:52:50 syslinux (opensbi+u-boot) is built by author of the https://github.com/pyavitz/debian-image-builder.git 2024-09-18 11:53:46 this is where I reached with this board 2024-09-18 12:13:05 and ready made image to dd to mmc and boot https://dev.alpinelinux.org/~mps/riscv64/bpi-f3-mmc.img.xz 2024-09-18 12:13:16 for those who trust me 2024-09-18 12:34:38 where does the patches come from? https://dev.alpinelinux.org/~mps/riscv64/aport-linux-bpi-f3/ 2024-09-18 12:35:31 https://github.com/pyavitz/debian-image-builder.git 2024-09-18 12:35:42 thanks 2024-09-18 12:36:04 same patches are also in armbian 2024-09-18 12:36:53 but I prefer what Patrick of https://github.com/pyavitz/debian-image-builder.git work 2024-09-18 12:37:19 nothing comes on hdmi when powered on, without flashing anything 2024-09-18 12:38:17 I didn't tested hdmi, work only with serial console 2024-09-18 12:38:24 👍 2024-09-18 12:38:35 so I'll have to find the UART pins 2024-09-18 12:39:01 yes, they are near GPIO header 2024-09-18 12:49:29 alright, i got the UART working 2024-09-18 12:49:32 ERROR: sd f! l:76 2024-09-18 12:49:32 sys: 0x0 2024-09-18 12:49:32 ERROR: CMD8 2024-09-18 12:49:32 try sd... 2024-09-18 12:49:32 bm:3 2024-09-18 12:49:55 ERROR: entering download mode. 2024-09-18 12:49:55 usb2d_initialize : enter 2024-09-18 12:49:55 ROM: usb download handler 2024-09-18 12:50:07 how does the ROM usb download handler work? 2024-09-18 12:51:41 you need fastboot to flash something on emmc 2024-09-18 12:53:08 here is forum https://forum.banana-pi.org/c/risc-v/85 and you can search for some things there 2024-09-18 13:33:51 Here is some documentation https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3 in case you did not find it yet 2024-09-18 13:40:36 ncopa: I see I forgot to enable SPACEMIT_HDMI 2024-09-18 14:19:37 yeah, i foudn that docs page. it is just not very much there 2024-09-18 14:23:33 mps: I booted your sdcard 2024-09-18 14:24:28 nice 2024-09-18 14:27:22 there is a green led blinking 2024-09-18 14:28:17 yes, annoying. I disabled it in my working image 2024-09-18 14:28:27 why is it blinking? 2024-09-18 14:28:40 echo none > /sys/class/leds/sys-led/trigger 2024-09-18 14:29:06 default is something which works, but I forgot what 2024-09-18 14:29:25 you can see by `cat /sys/class/leds/sys-led/trigger` 2024-09-18 14:30:02 red led cannot be disabled 2024-09-18 14:30:40 except if you have soldering tool and remove it :-) 2024-09-18 14:31:39 but maybe I should look at schematic of board, maybe it can be disabled programatically 2024-09-18 14:42:52 unplug power will disable all leds :p 2024-09-18 14:48:39 :D 2024-09-18 15:27:20 it did! 2024-09-18 15:27:22 :D 2024-09-18 15:53:53 ok, hdmi works with new kernel I've built. even X works 2024-09-18 15:54:49 thats awesome 2024-09-18 15:55:06 i really like this banana pi 2024-09-18 15:55:41 I still need to power it up 2024-09-18 15:56:16 this one with same SoC looks better https://milkv.io/jupiter 2024-09-18 15:56:53 and there is musebook laptop with same SoC for about 300 euros 2024-09-18 15:57:43 I would buy it if possible on local market 2024-09-18 15:59:39 i just realized i can remove the plastic film on the cover 2024-09-18 15:59:55 and also on the starfive 2 ! 2024-09-18 16:02:54 ncopa: OT here, but I really have no idea how to refactor qemu patch for qemu-agent 2024-09-18 16:03:16 yeah, it is non-trivial 2024-09-18 16:03:29 never used qemu-agent and don't know how to test it 2024-09-18 16:04:19 (I didn't forgot this issue) 2024-09-18 16:04:44 thinking of it nearly every day 2024-09-18 16:05:15 i dont know how relevant qemu-guest-agent is nowadays 2024-09-18 16:05:28 also I don't know 2024-09-18 16:05:35 you can send acpi signal for shutdown 2024-09-18 16:05:40 yes 2024-09-18 16:31:09 I have one old monitor and with some machines hdmi and with some it don't 2024-09-18 16:31:55 it works with loongarch desktop but not with bpi F3 2024-09-18 16:32:18 had to test on son's monitor 2024-09-18 16:36:53 can the bpi f3 boot from nvme? 2024-09-18 16:37:05 afaik no 2024-09-18 16:37:45 it has switches to select boot media but I don't see nvme in list 2024-09-18 16:38:13 maybe if u-boot can be built with it and flashed to SPI NOR 2024-09-18 16:39:02 I've uploaded kernel and mmc image with hdmi support, same versions as before 2024-09-18 16:39:14 same urls 2024-09-18 18:36:47 is reiscv.org on fediverse? 2024-09-18 18:36:54 *riscv.org 2024-09-18 18:40:03 Don't think so 2024-09-18 18:40:09 At least, cannot find them 2024-09-19 08:37:21 what should be "root=" parameter to boot initramfs as root media 2024-09-19 08:40:54 you dont need the "root=" param for that 2024-09-19 08:43:56 aha, thanks 2024-09-19 08:44:52 we don't have iso image for riscv64 2024-09-19 08:45:07 setting root will do the opposite 2024-09-19 08:46:07 would be nice to have something with some important system tools in initram 2024-09-19 08:46:26 what do you mean? 2024-09-19 08:49:01 something like alpine installation media, iso image 2024-09-19 08:49:42 i think iso does not make much sense nowadays 2024-09-19 08:49:55 we could do a vfat disk image 2024-09-19 08:50:21 question is what kernel we should ship it with 2024-09-19 08:50:36 agree, but why vfat? ext4 works fine 2024-09-19 08:50:59 because that is what we use for iso-like systems, for rpi etc 2024-09-19 08:51:17 also vfat is easy to create without needing root permissions 2024-09-19 08:51:41 historically we have done "diskless" usb with vfat 2024-09-19 08:52:06 it also allows us to have a single partition for UEFI 2024-09-19 08:52:28 depends a bit on how we want it to work 2024-09-19 08:52:43 i wonder if we should start doing ext disk images, with tiny-cloud as the standard 2024-09-19 08:52:56 instead of from tmpfs 2024-09-19 08:53:27 vfat is not so nice. you cannot extend it (without delete and recreate) 2024-09-19 08:54:17 could be exfat used instead of vfat? 2024-09-19 08:54:59 it could but what would be the benefit? 2024-09-19 08:55:05 can you extend exfat? 2024-09-19 08:55:26 can you use exfat for ESP partition? 2024-09-19 08:55:28 I think no 2024-09-19 08:56:03 I thought it could maybe be ESP FS, but don't know 2024-09-19 08:56:03 the only benefit with exfat is that it supports bigger partitions 2024-09-19 08:56:34 and I dont think we want build huge disk images 2024-09-19 08:57:56 i think main question is: do we want "diskless" images? with tmpfs root as the default 2024-09-19 08:58:10 users will have to install to disk after boot 2024-09-19 08:58:48 or do we want cloud style disk images, where the OS is already "installed" and you only have to customize (add your ssh keys, create users) 2024-09-19 08:59:08 via cloud-config 2024-09-19 08:59:28 I already have such image for qemu 2024-09-19 08:59:42 and we have cloud images 2024-09-19 08:59:53 what would be the difference? kernel? 2024-09-19 09:00:27 no. difference is that when you boot it up, it is already pre-installed 2024-09-19 09:00:58 the iso style we currently use boots up with tmpfs root, you have to install it to disk 2024-09-19 09:01:00 yes, but cloud needs diff kernel right? 2024-09-19 09:01:16 not really, it uses the -virt and -lts kernels 2024-09-19 09:01:39 you want to install both on the image? 2024-09-19 09:01:44 no 2024-09-19 09:01:51 im not following :) 2024-09-19 09:01:52 hm, I'm not sure virt flavor is needed nowadays 2024-09-19 09:02:04 it would be linux-lts for bare-metal 2024-09-19 09:02:26 mps: it is not needed. it is just convenient with a smaller kernel 2024-09-19 09:02:37 and for rpi it would be linux-rpi kernel 2024-09-19 09:02:48 and more burden on you :) 2024-09-19 09:02:53 and virt for cloud image 2024-09-19 09:03:02 yes 2024-09-19 09:03:10 so only the kernel is different? 2024-09-19 09:03:15 no 2024-09-19 09:03:42 alpine-*.iso: you write a disk image (or burn a cdrom) and boot it 2024-09-19 09:03:48 after boot you have to install it to disk 2024-09-19 09:04:01 with the "cloud" style images you get a pre-installed disk image 2024-09-19 09:04:21 you dont need to run setup-alpine with the "cloud" style images 2024-09-19 09:04:26 nod 2024-09-19 09:04:40 but you could install it also on baremetal like this 2024-09-19 09:04:50 that is my point here 2024-09-19 09:04:54 do we want that 2024-09-19 09:05:02 except if you need specific disk setup 2024-09-19 09:05:03 im thinking for rpi, and riscv64 boards 2024-09-19 09:05:12 correct 2024-09-19 09:05:33 if you need specific disk setup you may have a problem 2024-09-19 09:05:38 for riscv boards I've created images to be 'flashed' to media 2024-09-19 09:06:04 run some setup-* commands and extend root FS 2024-09-19 09:06:11 thats what I'm asking, do we want to do that for the the official alpine images 2024-09-19 09:06:27 so we could have diskimage-cloud diskimage-metal and diskimage-installer 2024-09-19 09:06:55 I think one image would be good 2024-09-19 09:07:06 the cloud images may need cloud specific tiny-cloud drivers 2024-09-19 09:07:23 we may need different image for aws vs azure 2024-09-19 09:08:02 right, cloud would have genres like it has now 2024-09-19 09:08:09 so it would be diskimage-virt diskimage-metal and diskimage-installer 2024-09-19 09:08:16 or something like that 2024-09-19 09:08:24 but 2024-09-19 09:08:43 we could start with the metal images for rpi and riscv64 2024-09-19 09:08:46 or only riscv64 2024-09-19 09:08:54 too much duplicated work 2024-09-19 09:08:57 and then extend to x86_64 images 2024-09-19 09:09:11 where diskimage-installer is like the iso, but we could have a fat partition so we could store ovl 2024-09-19 09:09:15 mps: thats why I'm asking do we want replace the iso images we currently use 2024-09-19 09:09:28 do we need iso nowadays? 2024-09-19 09:09:34 no 2024-09-19 09:09:34 who burns a cdrom? 2024-09-19 09:09:37 no 2024-09-19 09:09:39 imo 2024-09-19 09:09:48 actually 2024-09-19 09:09:51 maybe yes 2024-09-19 09:10:09 there are these kvm tools that want to mount iso images 2024-09-19 09:10:25 most servers work like this 2024-09-19 09:10:27 the cdrom image is convenien because you can boot a readonly media 2024-09-19 09:11:04 i think the .iso as a bootable tar archive 2024-09-19 09:11:40 what about qemu, do we need iso for qemu? 2024-09-19 09:11:50 we have the alpine-virt iso 2024-09-19 09:11:51 last bootable is image I created about 15 years ago 2024-09-19 09:11:55 which is for qemu 2024-09-19 09:12:07 i mean iso images in general 2024-09-19 09:12:16 if we really need it or can skip it completely 2024-09-19 09:12:25 but i guess the answer is already here 2024-09-19 09:12:36 qemu can boot normal image 2024-09-19 09:12:37 also, do we need the extended iso? 2024-09-19 09:13:05 i dont use it a lot 2024-09-19 09:13:15 neither do i 2024-09-19 09:13:23 nor do I 2024-09-19 09:13:25 in a controlled env it is nice 2024-09-19 09:13:34 enterprise kind of lets say 2024-09-19 09:13:53 its useful for airgap 2024-09-19 09:14:07 install alpine without internet access 2024-09-19 09:14:31 its the only reason i guess 2024-09-19 09:14:40 and in outer space 2024-09-19 09:14:45 then would be more pkgs added to extended image 2024-09-19 09:15:38 could we replace extended image with diskimage-metal? 2024-09-19 09:15:41 i dont know 2024-09-19 09:17:31 I'm for 'simple, small' 2024-09-19 09:19:52 the metal would be based on which fs? 2024-09-19 09:21:12 ext4 imo 2024-09-19 09:21:59 I use f2fs for some e/mmc and ssd but ext4 is safest 2024-09-19 09:24:52 i would say ext4 2024-09-19 09:25:45 so it will be harder to create by a regular user 2024-09-19 09:28:01 yeah 2024-09-19 09:28:45 there are tools to create ext4 file systems images with a list of the permissions for the files 2024-09-19 09:29:29 but it would be nice if we could apk add, so the triggers are run 2024-09-19 09:29:38 we also want the installed apk db 2024-09-19 10:03:30 mps: where do I get the bpi-f3 kernel from? 2024-09-19 10:03:40 your APKBUILD says I get it from https://localhost 2024-09-19 10:04:03 oh, maybe it have line above commented 2024-09-19 10:04:34 there is a link to https://gitee.com/bianbu-linux/linux-6.6.git 2024-09-19 10:04:46 source="https://dev.alpinelinux.org/~mps/riscv64/linux-spacemit-6.6.36.tar.gz 2024-09-19 10:05:21 where is the git repository for linux-spacemit? 2024-09-19 10:05:44 yes, used https://gitee.com/bianbu-linux/linux-6.6.git for creating linux-spacemit by 'git archive ...' 2024-09-19 10:06:19 on their site doesn't exit tarball of kernel 2024-09-19 10:06:34 is that a fork of linux-6.6.y? the web interface says there are 9 commits 2024-09-19 10:06:55 you can build cloning their repo if you like 2024-09-19 10:07:43 I used git old about one week ago to have 'stable' source 2024-09-19 10:07:59 stable in meaning not changed 2024-09-19 10:08:55 that git repository is more or less useless 2024-09-19 10:09:06 there are 6 commits there only 2024-09-19 10:09:50 fine, last commit there is: Date: Tue Sep 10 17:47:09 2024 +0800 2024-09-19 10:10:27 Update for v2.0rc3 2024-09-19 10:10:32 Update for v2.0rc4 2024-09-19 10:10:34 yes, very strange how they do this 2024-09-19 10:10:48 and first commit is Initial commit of v6.6.36 2024-09-19 10:10:56 'git log -p' is more informative 2024-09-19 10:11:10 how on earth am i supposed to rebase this against linux-6.6.y? 2024-09-19 10:11:33 heh 2024-09-19 10:11:40 good question 2024-09-19 10:12:35 I did all this as I understand how they work, by guessing 2024-09-19 10:12:55 oh man, this is insane 2024-09-19 10:13:04 wanted to get alpine apk only to test board 2024-09-19 10:13:21 the first commit (After initlal commit) is: 2024-09-19 10:13:27 3330 files changed, 3265138 insertions(+), 6467 deletions(-) 2024-09-19 10:13:32 one *huge* commit 2024-09-19 10:13:37 when they upstream more then we can add some things to aports 2024-09-19 10:14:13 this is just insame 2024-09-19 10:14:21 second commit: 297 files changed, 197783 insertions(+), 197091 deletions(-) 2024-09-19 10:14:30 how can anybody review that? 2024-09-19 10:14:42 agree, but board works somehow, and this is important 2024-09-19 10:14:51 sure, board works 2024-09-19 10:15:08 but how can *alpine* ship anything if we cannot provide security fixes for kernel? 2024-09-19 10:15:44 I noticed they started to sending some patches upstream so maybe it will be better with linux 6.13 2024-09-19 10:16:26 I don't think we should make board official yet for alpine 2024-09-19 10:17:27 so why do they send us those boards then? 2024-09-19 10:17:36 what are we supposed to do with them? 2024-09-19 10:17:39 run fedora? 2024-09-19 10:17:41 for now I work with some people (not related to alpine) to get things better 2024-09-19 10:18:02 i wanted to build a kernel for alpine so I can boot it 2024-09-19 10:18:08 but this is sort of a nightmare 2024-09-19 10:18:22 i want to track the work they do against the official linux kernel 2024-09-19 10:18:36 not some random snapshot of linux 6.6.32 2024-09-19 10:18:42 well, that is how we started with starfive, though starfive was lot better 2024-09-19 10:19:11 the starfive has a git repo that is branched against upstream linux kernel 2024-09-19 10:19:21 for now we can run alpine unofficially 2024-09-19 10:19:47 how do I merge in v6.6.52 into the bpi-f3 kernel? 2024-09-19 10:19:51 answer: i dont 2024-09-19 10:19:54 simple as that 2024-09-19 10:19:59 right 2024-09-19 10:20:23 how do I verify that they didnt sneak in any backdoors in the 6.6.32 import? 2024-09-19 10:20:25 answer I dont 2024-09-19 10:20:35 we are in playgarden with this board, for now 2024-09-19 10:20:51 i was hoping we could use it for CI 2024-09-19 10:21:01 but this is ridicoulous 2024-09-19 10:21:26 but with it you live 'on the edge' :) 2024-09-19 10:21:34 yeah, i can build a random kernel from a random guy and hope for the best, but there is absolutely no way to work on it 2024-09-19 10:22:27 for me even Linus and Greg KH are random people 2024-09-19 10:23:16 only clandmeter is not random 'people' for me 2024-09-19 10:23:54 in open source field, I mean 2024-09-19 10:24:19 but that's a life 2024-09-19 10:24:27 just dissapointed 2024-09-19 10:24:48 i was hoping i could merge 6.6.52 into the bpi-f3 branch 2024-09-19 10:24:50 I still trust more to spacemit than to big companies 2024-09-19 10:24:54 but its not a branch 2024-09-19 10:25:42 also I was (and still) disappointed when I saw their repos, docs, support 2024-09-19 10:26:08 it means we have no option but run old vulnerable kernel 2024-09-19 10:26:14 oof 2024-09-19 10:26:15 if we want use this 2024-09-19 10:26:16 sad 2024-09-19 10:26:31 this is the worst kernel i ever seen 2024-09-19 10:27:32 when I see similar things I take glass of red wine and roll cigarette to calm down 2024-09-19 10:29:17 imagine how much glasses of wine and cigarettes needed with apple silicon :) 2024-09-19 10:33:08 well, at least you can use git bisect if ever needed 2024-09-19 10:34:40 reading forum, bug reports and other I can find I don't expect this SoC will be upstream soon, maybe second half of next year 2024-09-19 10:35:35 problem is not with leemaker but vendor of SoC 2024-09-19 10:37:08 leemaker (vendor of bpi-f3) make public everything for board, schematic and other things 2024-09-19 11:29:27 i was able to rebase it finally 2024-09-19 11:29:39 or merge in 6.6.52 2024-09-19 11:30:02 mps: i see you prefer to set configs to 'y' instead of 'm' 2024-09-19 11:51:38 Could make sense for a very targetted kernel 2024-09-19 11:53:38 ncopa: I used armbian config for 6.1.15 as base for config and changed just few 2024-09-19 11:54:27 and when working with new devices I prefer to set 'y' for basic drivers/options 2024-09-19 11:55:06 after it become stable then I prefer 'm' for most except ext4 and console 2024-09-19 11:55:39 ikke: yes, you are right 2024-09-19 12:28:41 i would love to build a kernel that could work as a generic riscv64 kernel, so we dont need to ship separate disk images for each board 2024-09-19 12:28:58 but I suppose we dont have any option 2024-09-19 12:47:55 this is the glory of riscv 2024-09-19 12:48:17 and to some extent also arm 2024-09-19 12:55:29 ncopa: but you keep separate kernel for rpi for years 2024-09-19 12:56:07 as it was very popular 2024-09-19 12:56:13 and well managed project 2024-09-19 12:56:25 I would like to have one kernel (same) for all arches :) 2024-09-19 12:57:11 I use mainline kernel for rpi w zero 2024-09-19 12:57:18 s/use/used/ 2024-09-19 12:58:05 long ago I wrote that riscv will jungle as it is arm 2024-09-19 13:16:30 the rpi kernel is for a number of different rpis 2024-09-19 13:16:46 my riscv kernel does not build :-( 2024-09-19 13:16:51 :( 2024-09-19 13:18:11 some things can't be compiled as modules though they can be set in config as 'm' 2024-09-19 13:18:38 because this I mostly followed armbian config 2024-09-19 13:19:37 oh, btw, new linux-edge 6.11.0 have visionfive V2 enabled in it 2024-09-19 13:20:02 and i guess we don't need linux-starfive anymore 2024-09-19 13:20:21 perhaps still for the v1? Or are we dropping that? 2024-09-19 13:21:47 does linux-starfive support the v1? 2024-09-19 13:22:36 ikke: Esmil told earlier that he will later try to upstream also V1, for now we can build it for alpine or as we do usually - package on dev.a.o/~mps/ 2024-09-19 13:25:56 ikke: mainline kernel commit 43528789a0b9df73b318e9e8cbab3138d0187f2c 2024-09-19 13:26:21 Enable most of the options needed for the jh7100 based boards to be properly testable with defconfig. 2024-09-19 13:26:29 so, there is hope 2024-09-19 13:26:35 nice to hear 2024-09-19 13:27:15 I wait 5.11-rc to check 2024-09-19 13:27:30 hm, 6.11-rc 2024-09-19 13:39:21 i think the smacemit kernel does not build out of source 2024-09-19 13:43:08 the rtl8852bs driver does not build out of soruce 2024-09-19 13:44:27 some dependencies and options in Kconfig are wrong or not set at all 2024-09-19 13:45:48 I tried to modularize kernel to some degree but gave up 2024-09-19 13:46:34 my problem is that i cannot have a separate build directory 2024-09-19 13:46:45 make O=builddir 2024-09-19 13:47:14 and I think I have a fix already 2024-09-19 13:48:02 https://tpaste.us/zPW5 2024-09-19 14:21:12 mps: have you seen this error: 2024-09-19 14:21:14 ITB arch/riscv/boot/Image.gz.itb 2024-09-19 14:21:14 "mkimage" command not found - U-Boot images will not be built 2024-09-19 14:21:14 make[2]: *** [/home/ncopa/aports/testing/linux-spacemit/src/linux-6.6/arch/riscv/boot/Makefile:121: arch/riscv/boot/Image.gz.itb] Error 1 2024-09-19 14:21:58 maybe that is what DTC_FLAGS="-@" is for? 2024-09-19 14:22:11 or install dtc 2024-09-19 14:22:40 I'm not now at my 'working' machine and can't look 2024-09-19 14:22:50 do you rmeember what DTC_FLAGS="-@" was for? 2024-09-19 14:23:15 I use same makedepends as for linux-edge 2024-09-19 14:23:42 this flag allows to DTB overlays 2024-09-19 14:24:04 to use* 2024-09-19 14:32:25 installing u-boot-tools solved it 2024-09-19 14:32:30 so I added that to makedepends 2024-09-19 14:37:27 allright new kernel installed 2024-09-19 14:37:32 how do I update the bootloader? 2024-09-19 14:47:17 I edited the /boot/extlinux/extlinux.conf with my own kernel 2024-09-19 14:47:38 however, it does not boot 2024-09-19 14:48:18 Retrieving file: /initramfs-spacemit 2024-09-19 14:48:18 Retrieving file: /dtbs-spacemit/spacemit/k1-bananapi-f3.dtb 2024-09-19 14:48:18 append: earlycon=sbi rw root=UUID=10456777-a933-4ff1-b801-fe970c7d66d1 rootfstype=ext4 rootwait console=ttyS0,115200 console=tty0 clk_ignore_unused swiotlb=65536 2024-09-19 14:48:18 kernel_comp_addr_r or kernel_comp_size is not provided! 2024-09-19 14:48:18 Retrieving file: /vmlinuz-spacemit 2024-09-19 14:49:16 maybe i cannot use a compressed kernel 2024-09-19 14:59:22 right, kernel can't be compressed 2024-09-19 14:59:51 u-boot don't have option to uncompress it 2024-09-19 15:00:27 this is why I want to try to build u-boot with this enabled 2024-09-19 15:05:43 Linux alpine-bpif3 6.6.52-0-spacemit #1-Alpine SMP 2024-09-19 14:24:18 riscv64 Linux 2024-09-19 15:05:48 it boots \o/ 2024-09-19 15:05:52 thanks a lot mps 2024-09-19 15:06:05 im following in your footsteps 2024-09-19 15:07:45 ncopa: np, and nice that you got 6.6.52 2024-09-19 15:08:51 as I see looks like they follow linux LTS for kernel development 2024-09-19 15:13:19 so this kernel is patched or vanilla? 2024-09-19 15:13:45 patched 2024-09-19 15:14:05 heavily patched 2024-09-19 15:14:18 patch is bigger than source :) 2024-09-19 15:14:29 3 million lines 2024-09-19 15:14:44 im pushing testing/linux-spacemit 2024-09-19 15:15:07 this is the 2 commit patch? 2024-09-19 15:15:15 mps: no i need to figure out how you created the image 2024-09-19 15:15:20 sort of 2024-09-19 15:15:39 he has a script iirc 2024-09-19 15:15:56 I added the 4 commits to https://github.com/ncopa/linux/commits/spacemit-6.6.y/ 2024-09-19 15:16:17 branched of upstream linux v6.6.36 2024-09-19 15:16:17 ncopa: https://dev.alpinelinux.org/~mps/riscv64/create-bpi-f3-img.sh 2024-09-19 15:16:27 mps: thank you sir! 2024-09-19 15:16:44 pleasure is mine, sir :) 2024-09-19 15:17:20 maybe it need some tweaks and/or improvments 2024-09-19 15:17:52 feel free to share changes back 2024-09-19 15:18:39 all in one commit ;-) 2024-09-19 15:19:02 mps: do you run this from a riscv64 machine? 2024-09-19 15:19:21 no, m1pro with qemu-user 2024-09-19 15:19:39 qemu-user is amazing :) 2024-09-19 15:20:30 here is quick script to flash u-boot+opensbi to emmc https://tpaste.us/Lyk4 2024-09-19 15:24:15 ncopa: very good work, congrats 2024-09-19 15:27:31 may I ask how you run qemu-user? 2024-09-19 15:27:56 qemu openrc 2024-09-19 15:28:09 its automatic 2024-09-19 15:28:15 oh 2024-09-19 15:28:28 like the rv builder we had 2024-09-19 15:30:12 /etc/init.d/qemu-binfmt start 2024-09-19 15:30:19 got it 2024-09-19 15:30:24 awesome 2024-09-19 15:30:44 this is beautiful 2024-09-19 15:31:06 loop module also needs to be loaded 2024-09-19 15:44:41 btw, someone who has nvme disk told me that it is not stable, but I didn't tested 2024-09-19 15:45:17 from sd card and emmc it works fine 2024-09-19 15:47:00 and power supply should be good else kernel could crash randomly (which is normal) 2024-09-19 16:01:57 do we need to have separate /boot partition? 2024-09-19 16:06:40 no. one is ok. then you should create /boot directory 2024-09-19 16:07:02 and /boot/extlinux directory? 2024-09-19 16:07:27 and not sure how big partition can read current u-boot 2024-09-19 16:08:10 tiny-cloud is nice 2024-09-19 16:08:21 a side effect is that it sets up network 2024-09-19 16:08:38 it will autodetect which port is plugged in 2024-09-19 16:08:41 and configure network 2024-09-19 16:08:44 dhcp 2024-09-19 16:09:01 actually u-boot could read extlinux.conf from /boot directory (in 'theory') but safest is to use /boot/extlinux/extlinux.conf 2024-09-19 16:22:46 it was able to boot from the single partition 2024-09-19 16:22:48 but.. 2024-09-19 16:23:23 [ 5.239727] Disabling rootwait; root= is invalid. 2024-09-19 16:23:23 [ 5.260217] Please append a correct "root=" boot option; here are the available partitions: 2024-09-19 16:23:23 [ 5.245344] /dev/root: Can't open blockdev 2024-09-19 16:23:23 [ 5.249564] VFS: Cannot open root device "UUID=d3000104-11eb-4ece-993f-762f327e5db2" or unknown-block(0,0): error -6 2024-09-19 16:23:25 ... 2024-09-19 16:38:54 seems like the wlan interface is missing? 2024-09-19 16:50:12 `ip a | tpaste` => https://tpaste.us/lban 2024-09-19 17:02:41 ncopa: run 'modprobe 8852bs' or put it in /etc/modules if you don't see wlan interface 2024-09-19 17:09:44 Linux F3 6.6.52-0-spacemit #1-Alpine SMP 2024-09-19 15:13:50 riscv64 Linux 2024-09-19 17:10:04 and works fine 2024-09-19 17:11:22 should we tell about it on #riscv channel? 2024-09-19 17:12:57 there are people who works on it to improve and fix things 2024-09-19 17:13:53 I wonder who was idiot to design notebooks to have touchpad where it is most annoying :/ 2024-09-19 19:05:47 maybe we should 2024-09-19 20:02:47 the disk image for bananapi bpi-f3 https://dev.alpinelinux.org/~ncopa/riscv/alpine-bpi-f3-mmc.img.xz 2024-09-19 20:03:00 cool 2024-09-19 20:03:02 it works pretty well 2024-09-19 20:03:11 with tiny-cloud 2024-09-19 20:03:29 so you can create an usb vfat, with LABEL=cidata 2024-09-19 20:03:56 echo "hostname: alpine-bpi-f3" > meta-data 2024-09-19 20:04:55 echo "#alpine-config" > user-data; echo "ssh_authorized_keys:" >> user-data ; echo " - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOIiHcbg/7ytfLFHUNLRgEAubFz/13SwXBOM/05GNZe4 ncopa@ncopa-desktop" >> user-data 2024-09-19 20:05:16 plug it in and boot the sdcard 2024-09-19 20:05:41 and it will set up network, sshd and add your ssh key to `alpine` user 2024-09-19 20:05:52 so you can boot it headless 2024-09-19 20:05:59 where do you put the image? 2024-09-19 20:06:10 to the sdcard 2024-09-19 20:06:41 and the CIDATA partiation on the same sdcard? 2024-09-19 20:09:39 this one is simpler https://dev.alpinelinux.org/~mps/riscv64/bpi-f3-mmc.img.xz 2024-09-19 20:10:00 just 'dd' and boot 2024-09-19 20:17:41 you can have cidata on same sdcard, but I use a separate USB mem for that 2024-09-19 20:18:07 you dont need the CIDATA partition 2024-09-19 20:18:17 mps: did you test my image? 2024-09-19 20:18:27 it will resize the root partition on first boot 2024-09-19 20:18:33 ncopa: I simply copied sdcard to emmc and flashed u-boot+opensbi, thats all 2024-09-19 20:19:07 ncopa: no, I didn't tested your image 2024-09-19 20:19:24 don't have time, too much babbling around 2024-09-19 20:19:30 i cant cause i didnt get mine :( 2024-09-19 20:19:36 i only have the 2G versions 2024-09-19 20:19:42 which needs hacking 2024-09-19 20:20:31 what kinda hacking does the 2G version need? 2024-09-19 20:21:13 mps knows 2024-09-19 20:21:14 i would expect https://dev.alpinelinux.org/~ncopa/riscv/alpine-bpi-f3-mmc.img.xz work with 2GB version as well 2024-09-19 20:21:18 some nvram setting or related 2024-09-19 20:21:18 clandmeter: for such work you must be stubborn, I've managed to fix with 10-15th try 2024-09-19 20:21:44 and i dont have a case like you guys do :) 2024-09-19 20:21:45 for the 16GB version i just dd the sdcard and it booted on first try 2024-09-19 20:22:10 ncopa: 2GB version will not boot from sdcard, needs one parameter change in eeprom 2024-09-19 20:22:17 sounds fun 2024-09-19 20:22:27 yes 2024-09-19 20:23:15 and only way to change this is program which works only on windows and program interface in chinese 2024-09-19 20:46:15 mps: so I could dd bootinfo_emmc.bin, FSBL.bin (x2) to mmcblk2boot0, and then dd the https://dev.alpinelinux.org/~ncopa/riscv/alpine-bpi-f3-mmc.img.xz to mmcblk2? 2024-09-19 20:47:01 no 2024-09-19 20:47:35 alpine-bpi-f3-mmc.img.xz have u-boot+opensbi in boot sectors 2024-09-19 20:48:44 you can boot alpine-bpi-f3-mmc.img.xz and then partition mmcblk2, mkfs on partition and rsync rootFS from sdcard 2024-09-19 20:49:07 this is safe method though have some manual works 2024-09-19 20:49:26 and if emmc does not boot, can i then boot from sdcard? 2024-09-19 20:49:37 other option is to create script to do all automatically 2024-09-19 20:50:00 yes, boot order is sdcard then emmc, by default 2024-09-19 20:50:09 ok. good 2024-09-19 20:50:21 if you didn't changed boot switches, ofc 2024-09-19 20:51:05 I planed later to create script to install on emmc from running system on sdcard but you are too fast 2024-09-19 20:51:42 so I will try tomorrow to create such script and put it in sdcard image 2024-09-19 20:52:22 I did same for apple M1 with first images to install alpine on them 2024-09-19 20:54:06 and now is time for another glass of red wine and after that go to bed 2024-09-19 20:54:40 it worked to do: dd if=alpine-bpi-f3-mmc.img of=/dev/mmcblk2 bs=1M 2024-09-19 20:54:49 it booted up properly 2024-09-19 20:54:52 very nice 2024-09-19 20:55:47 looks like dirty solution 2024-09-19 20:55:59 but ok 2024-09-19 20:56:06 makes sense 2024-09-19 20:56:32 the files and seek options are the same as when creating the sdcard 2024-09-19 20:56:33 you discovered something about which I didn't thought 2024-09-19 20:56:38 :) 2024-09-19 20:56:40 right 2024-09-19 20:56:56 so the expeted data should be on the correct offsets 2024-09-19 20:56:56 but I didn't thought about that 2024-09-19 20:57:35 hehe, very nice 2024-09-19 20:58:20 104.7G available now 2024-09-19 20:58:25 this is nice 2024-09-19 20:59:55 and you have FSBL duplicated on emmc :) 2024-09-22 13:23:13 anyone tried linux-edge on visionfive V2? 2024-09-23 10:35:22 mps: just tried linux-edge on visionfive v2 2024-09-23 10:35:37 [ 0.000000] Linux version 6.11.0-0-edge (buildozer@build-edge-riscv64) (gcc (Alpine 14.2.0) 14.20 2024-09-23 10:35:37 [ 0.000000] Machine model: StarFive VisionFive 2 v1.3B 2024-09-23 10:36:04 ... 2024-09-23 10:36:04 [ 1.036681] clk: Disabling unused clocks 2024-09-23 10:36:04 [ 1.030454] dwmmc_starfive 16020000.mmc: IDMAC supports 32-bit address mode. 2024-09-23 10:36:16 and there it hangs 2024-09-23 10:37:29 ncopa: yes, I had the same 2024-09-23 10:38:19 have to find what must be changed in kernel config to boot it properly 2024-09-23 10:39:53 the linux-starfive boots though 2024-09-23 10:40:45 linux-starfive is 6.10.6 iirc 2024-09-23 10:40:55 yup 2024-09-23 10:41:05 edge is 6.11 2024-09-23 10:41:32 all drivers should be now in 6.11 for VF2 2024-09-23 10:41:39 ok, nice 2024-09-23 10:42:07 does edge kernel support DMVPN and other standard alpine stuff? 2024-09-23 10:42:17 have to make diff between 6.10.6 linux-starfive and 6.11 linux-edge 2024-09-23 10:42:47 im thinking of using the starfive as my home router 2024-09-23 10:43:24 to replace my APU2 machines 2024-09-23 10:43:42 DMVPN? 2024-09-23 10:44:06 I'm using it as home router for about 5-6 months 2024-09-23 10:44:23 ipsec and opennhrp 2024-09-23 10:44:58 iirc ipsec is enabled on all arches in linux-edge 2024-09-23 10:45:17 forgot is it enabled on linux-starfive 2024-09-23 10:45:31 but this will be easy fix 2024-09-23 10:47:13 wasn't there also something that allowed a single gre interface connect to multiple endpoints? 2024-09-23 10:48:48 GRE emcapsulation? 2024-09-23 10:52:00 multipoint GRE 2024-09-23 10:53:48 not sure, have to check 2024-09-23 10:55:56 https://www.pluralsight.com/blog/it-ops/multipoint-gre-tunnel-introduction 2024-09-23 10:56:56 https://wiki.alpinelinux.org/wiki/Setup_of_DMVPN_on_Alpine_linux#Setting_up_mGRE_tunnel 2024-09-23 10:58:34 ikke: it should work 2024-09-23 10:59:11 but, who uses ipsec novadays 2024-09-23 10:59:37 M 2024-09-23 10:59:42 wireguard! 2024-09-23 11:00:07 :) 2024-09-23 11:27:59 ok i have an image for starfive v2 without separate /boot partition 2024-09-23 11:28:30 i wonder if I should create a traditional iso-like image for "diskless" 2024-09-23 11:33:01 disk-image or iso-image 2024-09-23 11:33:15 vfat disk image 2024-09-23 11:33:27 I doubt there is riscv machine with cdrom 2024-09-23 11:33:54 a disk image with apks/ directory 2024-09-23 11:34:00 for tmpfs root 2024-09-23 11:34:07 I uploaded such image long ago on dev.a.o 2024-09-23 11:34:38 but not with apks dir 2024-09-23 11:35:47 maybe we should do this when linux-edge boots on VF2 so it possibly can be used for some other boards 2024-09-23 11:36:44 I hope I will find cause of problem this week, and maybe someone will be faster 2024-09-23 11:37:20 so, everything will be ready for next linux-lts 2024-09-23 11:59:18 so everything in the esmil patches is upstreamed? 2024-09-23 12:00:00 so I could update the linux-starfive kernel to 6.11 and drop the esmil patch? 2024-09-23 12:08:47 ncopa: I already did, and thought to push it later when finish some important work at home 2024-09-23 12:10:31 and no, not all Esmil's patches upstreamed, because this I didn't pushed it yet, want to test it more 2024-09-23 12:10:51 I think I will add few patches 2024-09-23 12:11:16 if you don't have urgent need please don't push it yet 2024-09-23 12:31:27 I don’t think many use cdrom. But iso is a generic image format used in more than just burning it to cd and insert it into a cdrom drive. 2024-09-23 13:14:24 GCC takes more than 8 hours to build on riscv64, i think we have to try not to bump pkgrel for it too often 2024-09-23 13:17:08 8 hours is painful 2024-09-23 13:17:11 All 3 pkgrel bumps since 14.2.0 have been to fix other archs, first AArch64, then 2 times Loongarch 2024-09-23 13:23:41 https://frame.work/blog/introducing-a-new-risc-v-mainboard-from-deepcomputing 2024-09-23 13:23:52 hm, outdated imo 2024-09-23 14:39:39 what is with riscv64 builder, too long build gcc 2024-09-23 15:13:59 It takes 8.5 hours 2024-09-23 15:14:00 yeah, companies need to stop making new boards with JH7110 2024-09-23 15:14:04 Only around 6 hours have passed 2024-09-23 15:14:21 That's why i suggested thta we need to be careful with GCC pkgrel bumps 2024-09-23 15:14:29 s/thta/that/ 2024-09-23 15:14:57 The previous 3 bumps fixed something, but i think there are a few MRs that want to apply "cosmetic" changes 2024-09-23 15:15:10 Not sure if the people opening those MRs are aware, that they're going to waste 8.5 hours of the riscv64 builder's time 2024-09-23 15:23:44 cherry pick them all into one branch and do it once maybe? 2024-09-23 15:29:24 I think we may also have to avoid making overly big changes (that are potentially error-prone) to main/gcc, as correcting that will be costly 2024-09-23 15:31:26 While working on GCC 14.2.0, i tried a GCC 15 snapshot in CI, and the build time for that is even worse, almost reaching 12 hours (i've mentioned that before) 2024-09-23 19:40:06 ncopa: and all: linux-starfive 6.11.0 passed builder so it is probably ready for upgrade 2024-09-23 19:41:52 thank you sir! 2024-09-23 19:42:04 i will test it tomorrow 2024-09-23 19:42:25 it has four patches 2024-09-23 19:42:58 they are not strictly needed but I think they are useful 2024-09-23 19:43:40 also, linux-asahi is upgraded to 6.11 2024-09-23 19:43:48 awesome! thanks 2024-09-23 19:43:57 i wonder if 6.12 will be the next LTS 2024-09-23 19:44:23 I guess it will be, but we will see 2024-09-23 19:45:13 two month cycle for new stable means beggining of december 2024-09-23 19:45:28 beginning* 2024-09-23 19:45:46 hopefully it gets out in november? 2024-09-23 19:45:49 i dunno 2024-09-23 19:46:05 maybe end of november 2024-09-23 19:47:20 hope there will not be 6.12-rc8 and -rc7 will be last before release 2024-09-23 19:48:56 ncopa: btw, bananapi f3 could be also fine home router 2024-09-23 20:29:52 it would. but I want use it for CI, so I can stop pay for the scaleway instances 2024-09-23 20:50:05 Phoronix seems pretty convinced that 6.12 will be an LTS 2024-09-24 12:50:40 Tried https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166#c24 in CI, that shortens GCC's build time to around 6 hours, which i think was how long GCC 13 took 2024-09-26 11:31:36 mps: the linux-starfive appears to work 2024-09-26 11:31:38 Linux alpine-visionfive2 6.11.0-0-starfive #1-Alpine SMP PREEMPT_DYNAMIC Mon, 23 Sep 2024 13:31:52 2024-09-26 11:32:27 yes, uptime => 13:32:07 up 2 days, 22:19, 0 user, load average: 0.00, 0.00, 0.00 2024-09-27 14:32:19 ncopa: btw, can i use the spacemit titan flasher to flash the rv-alpine img you provided on my lpi3a board? or other suggest tool 2024-09-27 14:50:00 i just used dd 2024-09-27 14:51:31 i think any disk image writer tool works 2024-09-27 14:56:49 ok 2024-09-27 14:57:17 this board have same SoC as bananapi f3? 2024-09-27 15:00:53 it seems so 2024-09-27 15:02:50 pericycle: you want to flash to emmc? 2024-09-27 15:03:35 yes 2024-09-27 15:05:31 then 'dd' will not flash all needed things 2024-09-27 15:05:57 and also not sure will titantools could 2024-09-27 15:06:09 maybe i will try fastboot 2024-09-27 15:06:52 i've flash lpi4a before 2024-09-27 15:06:56 fastboot can but you have to prepare things for /dev/mmcblk2boot0 2024-09-27 15:09:22 ohhh, i never notice that 2024-09-27 15:10:24 i just turn on the flash mode on the board and everytime i flash, the process lgtm 2024-09-27 15:10:34 maybe cause i run windows? 2024-09-27 15:11:00 this works because you use image made for emmc, I guess 2024-09-27 15:11:36 titantools need image for emmc, and then it works 2024-09-27 15:12:53 i'll try it tomorrow 2024-09-27 15:13:36 afaik ncopa prepared image only for sd card 2024-09-27 15:15:12 ohh thanks for mention that 2024-09-27 15:15:16 i dd'ed the very same image to emmc and it worked 2024-09-27 15:15:58 ncopa: iirc you first flashed FSBL.bin to /dev/mmcblk2boot0? 2024-09-27 15:16:04 after flashing the mmcblk2boot0, yes 2024-09-27 15:16:25 that's the "trick" 2024-09-27 15:18:19 pericycle: this is script to flash /dev/mmcblk2boot0 https://tpaste.us/vorL 2024-09-27 15:19:57 nice, thanks a lot 2024-09-27 15:19:58 I don't have time to write complete guide, wasting free time on other things which are important to alpine 2024-09-27 15:21:19 pericycle: here is script for creating sd card image 2024-09-27 15:21:22 https://tpaste.us/QKoE 2024-09-27 15:22:09 it is not perfect but you can see in it some important steps 2024-09-27 15:22:24 and adapt for emmc even 2024-09-27 15:22:58 that script was also the base for my image 2024-09-27 15:23:36 ok 2024-09-27 15:24:26 mps: my version of the same script: https://tpaste.us/KxOb 2024-09-27 15:24:56 this script is what I made for some numbers of new machines, and I simply copy and adapt for new ones 2024-09-27 15:25:23 actually, original author years ago was clandmeter 2024-09-27 15:25:25 i added tiny-cloud for CIDATA support, cloud-init style 2024-09-27 15:26:17 ncopa: yes, I remember you told me, but I don't have idea how to use tiny-cloud for boards 2024-09-27 15:26:58 mps: add an extra usb stick with a partition labeled CIDATA 2024-09-27 15:29:02 add a file named `user-data` on vfat (or iso9660) partition labeled CIDATA 2024-09-27 15:29:18 the content can be something like: 2024-09-27 15:29:35 do we have some docs about this somewhere 2024-09-27 15:29:54 #alpine-config 2024-09-27 15:29:54 ssh_authorized_keys: [ "" ] 2024-09-27 15:30:09 docs are workin in progress 2024-09-27 15:30:19 aha, ok 2024-09-27 15:31:05 probably you all know that I like KISS principle 2024-09-27 15:31:12 yeah 2024-09-27 15:31:36 tiny-cloud is a tool to provision alpine installs 2024-09-27 15:31:44 to do unattended installs 2024-09-27 15:32:00 on clouds? 2024-09-27 15:32:26 cloud or nocloud 2024-09-27 15:32:32 yes, but the same technique can be used for local machines 2024-09-27 15:32:57 interesting 2024-09-27 15:33:12 mps: try create an usb with vfat with label CIDATA 2024-09-27 15:33:34 add a file `user-data`, a #!/bin/sh script 2024-09-27 15:33:42 this script will be executed if found 2024-09-27 15:34:34 what tiny-cloud does during first boot: if filesystem with label CIDATA is found, mount and copy the files meta-data, user-data 2024-09-27 15:34:51 but how will machine execute this if it can't boot usb 2024-09-27 15:35:02 no, you boot from sdcard 2024-09-27 15:35:23 It's the OS that boots that reads the data from the usb drive 2024-09-27 15:35:24 and add an additional usb stick 2024-09-27 15:35:28 ah, so we need first simple image on sd card 2024-09-27 15:35:47 now I understand better 2024-09-27 15:35:54 you need a tiny-cloud enabled sd card boot media 2024-09-27 15:36:19 also, tiny-cloud will expand the ext4 root file system 2024-09-27 15:36:52 if first line in user-data is #!/bin/sh it will execute it 2024-09-27 15:37:21 if it is #alpine-config it will parse it as yaml, very similar to cloud-init 2024-09-27 15:37:59 tiny cloud will also auto configure network for you 2024-09-27 15:38:05 does the first line have to be exactly that or just start with that? I have a (maybe bad) habit of using `#!/bin/sh -x` 2024-09-27 15:38:06 the port it detects link on 2024-09-27 15:38:23 iggy: good question, let me check 2024-09-27 15:38:47 hmhm, will try to find time to read more about all this 2024-09-27 15:39:31 mps: it is a convenient way to do unattended installs, using generic boot images 2024-09-27 15:40:44 iggy: it will execute anything that start with '#!' 2024-09-27 15:41:33 https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/blob/main/lib/tiny-cloud/init?ref_type=heads#L337 2024-09-27 15:47:41 mps: you can try tiny-cloud in qemu 2024-09-27 15:48:29 echo "hostname: my-alpine-machine" > meta-data && xorrisofs -R -J -V "cidata" -o seed.iso meta-data && qemu-system-x86_64 --enable-kvm -m 1024 -hda seed.iso 2024-09-27 15:48:29 -cdrom https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-virt-3.20.3-x86_64.iso 2024-09-27 15:49:04 will set the hostname during boot and configure the network 2024-09-27 15:49:30 what is more interesting is setting ssh_authorized_keys 2024-09-27 15:50:09 tiny-cloud will create a user named 'alpine' with doas permissions, add your ssh key, configure network and start sshd 2024-09-27 15:50:12 so you can do headless install 2024-09-27 15:50:18 i should write about it 2024-09-27 15:59:13 sorry, was afk 2024-09-27 15:59:30 ncopa: thanks. will look 2024-09-28 02:00:45 ncopa: btw the image your provide yesterday only contain the rootfs right? 2024-09-28 02:02:06 im considering: if the bianbu linux can easily run on bpi-f3, if i change the rootfs and the bootfs to alpine, it should work right as well 2024-09-28 02:02:18 on lpi3a 2024-09-28 06:27:39 It contains a partirtition table and rootfs yes 2024-09-28 07:52:55 pericycle is offline but that was how I firstly run alpine. I used armbian, preserved /boot and /lib/modules dir, and copied VF2 root filesystem there, with some small tweaks 2024-09-28 12:07:12 jez, my computer can't even read the emmc partition:( 2024-09-30 05:56:48 ncopa: 2024-09-30 05:56:56 actually it works on lpi3a 2024-09-30 05:57:16 what's the root password of the system? 2024-09-30 05:59:55 im login 2024-09-30 06:02:18 it works! 2024-09-30 06:06:58 so we can add lpi3a to list of riscv boards which works with alpine 2024-09-30 06:07:07 yep 2024-09-30 06:07:09 btw 2024-09-30 06:07:16 there's some problem with network 2024-09-30 06:08:01 is there any telegram group so i can share the picture with you guys 2024-09-30 06:08:48 there are few but I forgot urls. try search 'alpine linux' 2024-09-30 06:09:48 https://t.me/alpine_linux_english 2024-09-30 06:10:28 https://t.me/alpine_linux 2024-09-30 06:13:36 ok, im in 2024-09-30 06:19:23 but the ethernet just not work:( 2024-09-30 06:24:59 does wifi works? 2024-09-30 06:30:15 im trying 2024-09-30 06:34:33 idk if ncopa add iwd by default to image 2024-09-30 06:37:39 pericycle: btw, could you post official url for lpi3a guides/docs 2024-09-30 06:38:58 want to compare with bpi-f3 and see if something else needed for it (I don't have lpi3a) 2024-09-30 06:41:06 lpi3a official doc: https://wiki.sipeed.com/hardware/en/lichee/K1/lpi3a/1_intro.html 2024-09-30 06:41:13 spacemit official doc: https://developer.spacemit.com/documentation 2024-09-30 06:42:45 thanks 2024-09-30 06:43:12 yw 2024-09-30 08:13:31 the wifi not work at all too:( 2024-09-30 08:15:15 pericycle: are devices detected by kernel? are driver modules loaded? 2024-09-30 08:16:27 how to check it? 2024-09-30 08:19:26 lsmod 2024-09-30 08:20:20 do you have any wlan0 interface? 2024-09-30 08:21:04 no 2024-09-30 08:21:11 https://gist.github.com/per1cycle/0f625e40b070fc38bad242b1dc927597 2024-09-30 08:21:18 i've share the full log on gist 2024-09-30 08:22:40 i suspect my network cable is broken 2024-09-30 08:22:58 but when i switch to bianbu linux the wlan is OK 2024-09-30 08:38:15 do you think you could help get the kernel config from bianbu? 2024-09-30 08:38:38 maybe from /proc/configs.gz (after modprobe configs) 2024-09-30 08:38:47 or from /boot/config- 2024-09-30 08:41:27 `ethtool eth0`will show if cable is plugged and it works 2024-09-30 08:42:08 also, I see that wifi driver is loaded, 8852bs module 2024-09-30 08:43:32 udhcpc is started but can't obtain lease 2024-09-30 09:22:50 here's the bianbu linux kernel configuration: https://gist.github.com/per1cycle/2ecb475ec0b5399e240e13acd227fd5d 2024-09-30 09:25:56 I actually based alpine kernel config on this 2024-09-30 09:26:23 mps: actually the wireless function is fine running on bianbu linux 2024-09-30 09:26:28 but I changed some things and ncopa also changed some later 2024-09-30 09:26:57 pericycle: You are using dtb file of bpif3, there is an another file for lpi3a 2024-09-30 09:27:00 pericycle: `ip link show` 2024-09-30 09:27:37 lindsay: ohhh that make sense 2024-09-30 09:27:51 lindsay: ah, good catch 2024-09-30 09:28:35 but why the bianbu linux doesn't have the bpif3 dtb but also works fine on bpif3 2024-09-30 09:29:02 maybe they merged few dtbs to one 2024-09-30 09:29:59 if is the dtb problem, it shouldn't boot at all during the uboot step? 2024-09-30 09:30:09 im not sure 2024-09-30 09:30:59 some configs are shared between boards in dts, they are based on same SoC 2024-09-30 09:31:13 and because this it boots 2024-09-30 09:32:43 right solution will be to make u-boot to detect board and then select proper dtb from dtbs dir 2024-09-30 09:32:55 ohhh, seems reasonable 2024-09-30 09:33:58 that is how we fixed starfive JH7110 2024-09-30 09:35:11 localhost:~# ip link show 2024-09-30 09:35:12 if spacemit uses new u-boot I would try to make fix for it, but I'm to lazy to do this for so old u-boot 2024-09-30 09:35:13 1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 2024-09-30 09:35:15 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2024-09-30 09:35:17 2: eth0: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 2024-09-30 09:35:19 link/ether 48:da:35:68:00:4c brd ff:ff:ff:ff:ff:ff 2024-09-30 09:35:21 3: eth1: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 2024-09-30 09:35:23 link/ether 48:da:35:68:00:4d brd ff:ff:ff:ff:ff:ff 2024-09-30 09:35:25 4: tunl0@NONE: mtu 1480 qdisc noop state DOWN qlen 1000 2024-09-30 09:35:27 link/ipip 0.0.0.0 brd 0.0.0.0 2024-09-30 09:35:29 5: sit0@NONE: mtu 1480 qdisc noop state DOWN qlen 1000 2024-09-30 09:35:31 link/sit 0.0.0.0 brd 0.0.0.0 2024-09-30 09:35:33 6: ip6tnl0@NONE: mtu 1452 qdisc noop state DOWN qlen 1000 2024-09-30 09:35:35 link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 2024-09-30 09:35:37 localhost:~# 2024-09-30 09:35:59 no wlan0 2024-09-30 09:36:05 ohh, looks wierd while pasting multi lines in irc 2024-09-30 09:36:17 yeah, no wlan( 2024-09-30 09:36:36 pasting multiline is usually frowned on irc :) 2024-09-30 09:37:25 :( 2024-09-30 09:37:37 pericycle: from which kernel are above lines 2024-09-30 09:38:03 from ncopa's alpine bpif3 default kernel 2024-09-30 09:39:18 actually i don't know how to change the kernel without network support on the board:( 2024-09-30 09:39:26 can xshell transfer file in serial mode? 2024-09-30 09:39:36 and you changed 'dtb' in extlinux.conf 2024-09-30 09:41:07 ok 2024-09-30 09:42:29 it should be k1-x_lpi3a.dtb instead of current 2024-09-30 09:44:08 current is 'fdt /boot/dtbs-spacemit/spacemit/k1-bananapi-f3.dtb' 2024-09-30 09:44:33 change it to 'fdt /boot/dtbs-spacemit/spacemit/k1-x_lpi3a.dtb' 2024-09-30 09:45:19 ok, im trying 2024-09-30 09:50:20 currentlly i just change the `k1-bananapi-f3.dtb` to `k1-x_lpi3a.dtb` but the network function still not work at all 2024-09-30 09:50:51 wlan still not shown 2024-09-30 09:52:55 what shows `ethtool` for eth0 and eth1 2024-09-30 09:53:29 last line, Link detected: 2024-09-30 09:54:49 what's `ethtool` 2024-09-30 09:54:57 command 2024-09-30 09:55:14 no such command 2024-09-30 09:55:49 hm, ncopa removed it from my template 2024-09-30 09:55:57 :( 2024-09-30 09:56:11 sad 2024-09-30 09:56:35 pericycle: if you want I can upload my image ready for 'dd' to sd card and boot 2024-09-30 09:56:55 and I will add lpi3a as boot option 2024-09-30 09:57:12 ohh, that's great 2024-09-30 09:57:34 give me hour or two to add this and test 2024-09-30 09:57:49 ohh, thx a lot 2024-09-30 09:58:13 np, I will tell when finish 2024-09-30 09:59:22 ok 2024-09-30 10:09:00 btw, the lpi3a use the same wifi chip as lpi4a(aic8800)? It need out-of-tree driver to work. 2024-09-30 10:10:21 hm, this means it will not work alpine for now 2024-09-30 10:19:03 pericylcle, https://dev.alpinelinux.org/~mps/riscv64/spacemit-mmc.img.xz 2024-09-30 10:19:27 uncompress and dd to sd card 2024-09-30 10:19:53 (I was faster than expected) 2024-09-30 10:20:27 there are two boot options, lpi3a and bpi-f3 2024-09-30 10:22:05 lindsay: I see aic8800 in kernel tree 2024-09-30 10:25:23 CONFIG_AIC_WLAN_SUPPORT 2024-09-30 10:26:51 CONFIG_AIC8800_WLAN_SUPPORT 2024-09-30 10:29:20 and yes, it is enabled in bianbu kernel 2024-09-30 10:32:58 ncopa: I would like to enable this in linux-spacemit and push (without MR). are you ok with this? 2024-09-30 10:33:16 anyway, you have other my MRs to merge :) 2024-09-30 10:45:19 can you enable them as modules? 2024-09-30 10:45:43 I think yes 2024-09-30 10:59:31 uhm, your new method in APKBUILD looks strange to my eyes 2024-09-30 11:07:17 ncopa: diff would be https://tpaste.us/BMBy 2024-09-30 12:07:30 ok, pushed changes. lets wait till pass builder and test again 2024-09-30 12:09:35 oh, i just finished building it 2024-09-30 12:10:21 the kernel config is a diff from defconfig, so we don't need to keep track of *every* kernel config knob 2024-09-30 12:10:33 we only keep track of the stuff that differs from the default 2024-09-30 12:12:06 https://tpaste.us/pyM4 2024-09-30 12:21:10 ah. anyway diffs are practically same 2024-09-30 13:33:00 ahm, we need firmware for AIC8800_WLAN but we don't have it in alpine. it is not in linux-firmware 2024-09-30 13:48:16 https://github.com/radxa-pkg/aic8800/tree/main/src/SDIO/driver_fw/fw/aic8800