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