December 3, 2025Dec 3 Thanks @c0rnelius Is there a sustainable way of building working images for kickpi k2b v2?
December 3, 2025Dec 3 49 minutes ago, Nasko said: Is there a sustainable way of building working images for kickpi k2b v2? Short of KIckPi opening a contract with Armbian and providing the units they want worked on. I don't see how?
February 28Feb 28 Quote Hello, Do you still have this Armbian SDK?which includes kickpi-k2b-v2 and v1. https://we.tl/t-wtmI81zB5e, is expired. Thanks.
April 29Apr 29 After long break, I have found some free time to test latest updates that can be found in github It seems that pyavitz made a great progress there with his DTS implementation over Debian. https://github.com/pyavitz/debian-image-builder Now i am able to boot Debian out of the reproduced image. No uboot patching: Here is a copy of my work inside above repository: make config make all board=kickpik2b-v2 sudo dd if=output/kickpik2b-v2/image/sun50i-h618-kickpi-k2b-debian-trixie-6.12.84-arm64-ext4-2026-04-29-1923.img of=/dev/mmcblk0 And boom. Flawless boot into Debian Linux U-Boot SPL 2026.01 (Apr 29 2026 - 18:28:52 +0300) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.12.9(debug):lts-v2.12.9 NOTICE: BL31: Built : 18:28:34, Apr 29 2026 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0cd628, model: KickPi K2B INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: Probing for PMIC on I2C: INFO: PMIC: found AXP313 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. U-Boot 2026.01 (Apr 29 2026 - 18:28:52 +0300) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: KickPi K2B DRAM: 2 GiB Core: 74 devices, 23 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0, mmc@4021000: 2, mmc@4022000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... USB EHCI 1.00 USB OHCI 1.0 USB EHCI 1.00 USB OHCI 1.0 USB EHCI 1.00 USB OHCI 1.0 Bus usb@5101000: 1 USB Device(s) found Bus usb@5101400: 1 USB Device(s) found Bus usb@5200000: 1 USB Device(s) found Bus usb@5200400: 1 USB Device(s) found Bus usb@5310000: 1 USB Device(s) found Bus usb@5310400: 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf KickPi K2B V2 1: Debian Trixie Enter choice: 1: Debian Trixie Retrieving file: /boot/extlinux/../Image Retrieving file: /boot/extlinux/../uInitrd append: earlyprintk console=tty1 console=ttyS0,115200n8 rw root=PARTUUID=e0688e9b-01 rootwait rootfstype=ext4 fsck.repair=yes loglevel=1 net.ifnames=0 video=HDMI-A-1:1920x1080 init=/sbin/init Retrieving file: /boot/extlinux/../allwinner/sun50i-h618-kickpi-k2b.dtb Moving Image from 0x40080000 to 0x40200000, end=0x41930000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: initramfs-6.12.84 Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 11668168 Bytes = 11.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 494df000, end 49fffac8 ... OK Loading Device Tree to 00000000494d2000, end 00000000494de815 ... OK Working FDT set to 494d2000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 257.9-1~deb13u1 Most important part - communication devices are available: Pyavitz did a great job! kickpik2b-v2root~: dmesg | grep -i "eth0\|wlan0" [ 19.638015] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.784938] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:00] driver [MAE0621A-Q2C Gigabit Ethernet] (irq=POLL) [ 19.784980] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found [ 19.784991] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available [ 19.784999] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW [ 19.785390] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode [ 19.826219] [chip1][SKWIFI6621S DBG] skw_ndo_open: dev: wlan0, type: STA [ 19.826262] [chip1][SKWIFI6621S DBG] skw_ndo_set_rx_mode: wlan0, mc: 1, uc: 0 [ 19.826723] [chip1][SKWIFI6621S DBG] skw_ndo_set_rx_mode: wlan0, mc: 2, uc: 0 [ 19.826885] [chip1][SKWIFI6621S DBG] skw_set_power_mgmt: wlan0, enabled: 0, timeout: -1 I haven't tried Armbian yet, but the heavy lifting part is already done. Big kudos to pyavitz @c0rnelius Thanks, Nasko Edited April 29Apr 29 by Nasko
August 13Aug 13 Hi everyone, I wanted to share issues and fixes I encountered while building an image for kickpik2b-v2 using debian-image-builder. 1. Build failure on default 6.12.y (AIC8800) In lib/boards/kickpik2b-v2, FORCE_LINUX_VERSION is set to "6.12.y". During the build, kernel 6.12.103 is selected, but it fails on sources/aic8800/debian/patches/fix-linux-6.13-build.patch. The patch currently guards the netdev structure changes for kernel 6.13+: +#if LINUX_VERSION_CODE >= KERNEL_VERSION (6, 13, 0) + struct net_device *, +#endif However, recent point releases in the 6.12 LTS branch (like 6.12.103) also require this change due to backported kernel API updates. 2. Malformed patch on 6.18.y (UWE5622) When testing FORCE_LINUX_VERSION="6.18.y", the build fails while applying patches/wireless/unisoc/6.18/001-Introduce-uwe5622-driver-for-kernel-6.18.patch: Objective: Integrates the uwe5622 Wi-Fi driver into the kernel 6.18 build tree by appending obj-$(CONFIG_UWE5622) += uwe5622/ to drivers/net/wireless/Makefile and sourcing its new Kconfig from drivers/net/wireless/Kconfig. Issue: Build failed during patch application with a malformed patch error on the new Kconfig chunk. Root Cause: Invalid unified diff chunk header (@@ -0,0,13 @@) missing the required + symbol for inserted lines. Fix: Correcting the chunk header to @@ -0,0 +1,13 @@ solves the issue: Bash sed -i 's/@@ -0,0,13 @@/@@ -0,0 +1,13 @@/g' patches/wireless/unisoc/6.18/001-Introduce-uwe5622-driver-for-kernel-6.18.patch Result: The patch applies cleanly (Patches: Applying, done.), properly linking the uwe5622 sub-directory into drivers/net/wireless/ and building the driver module (CC [M]) on kernel 6.18.44. 3. Build failure on vs6621s wireless driver (Kernel 6.18) Later in the build process on kernel 6.18, the compilation halted on the vs6621s Seekwave driver due to unused variable warnings/errors on newer kernel APIs: Issue: Failed building drivers/net/wireless/vs6621s/seekwaveplatform_lite/sdio/skw_sdio_main.c with error: unused variable ‘host’ [-Wunused-variable]. Root Cause: Incompatibility in the third-party vs6621s driver with Kernel 6.18 MMC/SDIO interface updates. Fix: Since the kickpik2b-v2 hardware does not use the Seekwave chip (it uses AIC8800 or UWE5622), disabling this driver in drivers/net/wireless/Makefile resolves the issue completely. Patch: Created a new patch 002-disable-vs6621s.patch in patches/wireless/unisoc/6.18/: --- a/drivers/net/wireless/Makefile +++ b/drivers/net/wireless/Makefile @@ -23,3 +23,3 @@ obj-$(CONFIG_WLAN_VENDOR_ST) += st/ obj-$(CONFIG_WLAN_VENDOR_TI) += ti/ -obj-$(CONFIG_WLAN_VENDOR_SWT6621S) += vs6621s/ +#obj-$(CONFIG_WLAN_VENDOR_SWT6621S) += vs6621s/ obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/ Result: Kernel, DTB, and all required Wi-Fi/BT modules (aic8800_fdrv.ko, uwe5622_bsp_sdio.ko) compiled 100% successfully. sun50i-h618-kickpi-k2b-debian-trixie-6.18.44-arm64-ext4-2026-08-13-1242.img is booting but no etgernet or wifi.
August 14Aug 14 @Hubert It compiles. No clue if it works? https://github.com/pyavitz/debian-image-builder/commit/32cfcb18e67469a1b0493e6f951375830a63b48f
August 17Aug 17 I can confirm: sun50i-h618-kickpi-k2b-debian-trixie-6.12.103-arm64-ext4-2026-08-17-0923.img eth0 and wlan0 is up.
August 31Aug 31 rev V2.2: Wi-Fi working — the NV firmware needs two symlinks I have a K2B rev V2.2 (DDR3, 4 GB) running Debian 13 with working Wi-Fi, and since this thread lists networking as the remaining blocker, here is what was missing. The DRAM side is already solved by pyavitz's kickpik2b-v2 target, so I will not repeat it — this is only about the Wi-Fi/BT firmware. WI-FI: THE DRIVER ASKS FOR FILENAMES NOBODY SHIPS The SWT6621S driver requests two files that are not in any firmware package, so request_firmware returns -2 and the interface never appears. Both requested names are aliases of files that ARE shipped: cd /lib/firmware ln -sfn SWT6621S_NV_SDIO_SHARE.bin SWT6621S_NV_SDIO.bin ln -sfn SWT6621S_SEEKWAVE_R00000.bin SEEKWAVE_NV_SWT6621S.bin That is the entire fix. wlan0 comes up after a reboot. Why SHARE and not ALONE — worth stating, because picking wrong here is silent. The two files differ by exactly one byte, at offset 0x20: 01 vs 00. SWT6621S_NV_SDIO.ini documents what it means: ;[bit0]0-share,1-stand alone -> BT_ANTENNA_TYPE And the kernel independently reports bt_antenna=0 at boot on this board, i.e. a shared antenna. So SHARE is the match — confirmed twice, not guessed. BLUETOOTH: WORKS, BUT WITH A BORROWED IDENTITY sv6160lite.nvbin is shipped by nobody — not the image, not the builder, not the driver sources. It does exist in armbian/firmware, added for the sibling board K3B, which uses the same SV6160LITE: curl -sfL -o /lib/firmware/sv6160lite.nvbin \ "https://raw.githubusercontent.com/armbian/firmware/master/seekwave/sv6160lite.kickpi%2Ck3b.nvbin" 48 bytes, magic NVDS. The controller then comes up: hci0: BD Address: 60:48:9C:41:28:F1 ACL MTU: 1021:6 SCO MTU: 255:4 UP RUNNING [SKWBT_INFO] btseekwave_download_nv / chip version:0x5302 Two caveats, please read before using this: 1. The BD address comes from K3B's NV file. On one board that is harmless. If several people apply this, every one of those boards ends up with the SAME Bluetooth address — which will collide in the same room. I have not worked out how to generate a per-board NV; if anyone knows the format well enough, that is the missing piece. 2. BR/EDR works, BLE does not. hcitool lescan fails with "Set scan parameters failed: Input/output error". Probably the K3B NV not matching this board exactly. I did not chase it because Bluetooth is not needed for my use case. WI-FI MAC IS NOT IN THE NV FILE Worth knowing since it looks like a firmware problem but is not: the NV file contains no MAC at all — 220 bytes of register pairs, and the .ini has no mac or addr field. So the driver generates a random MAC per boot. If you need a stable one, pin it with a systemd .link file rather than expecting firmware to supply it. ONE THING NOT TO DO Do NOT modprobe -r this driver to reload firmware. The SDIO device is non-removable and the module does not come back — it took a reboot to recover. Reboot instead. SETUP SUMMARY - Board: KICKPI K2B rev V2.2 (label on the PCB), Allwinner H618, 4 GB DDR3 - Built with pyavitz/debian-image-builder, make all board=kickpik2b-v2 - Debian 13 trixie, kernel 6.12.103, u-boot 2026.01 - Running from eMMC, stable under load, Wi-Fi and BR/EDR Bluetooth working
September 2Sep 2 I've ordered one of these to play around with. It will likely be v2.2 I guess. So if I understand correctly armbian images from here won't work (?) : https://armbian.com/boards/kickpik2b due to uboot being incompatible with RAM and/or DTS wrong for v2.2 hardware? So I will have to build a debian image as per @falcon33 post above?
September 2Sep 2 It is actually a multi-layered problem. 1) Different DRAM (u-boot is different on both REVS) 2) Out-of-tree ethernet driver 3) Out-of-tree wireless driver The last good source for those drivers were linux-6.12.y. Armbian last I checked was on 6.18.y and up? I personally don't have time to mess with the drivers to get them up to snuff and even if I did, I'm not sure I could. Plus I only have the REV1. Anyway, that's the gist of it.
September 2Sep 2 OK out of tree but would the radxa aic8800 drivers fix the WiFi? Apparently they work with kernel 7 though I haven't verified this. https://github.com/radxa-pkg/aic8800 Edited September 2Sep 2 by WINEDS
September 10Sep 10 WINEDS said: OK out of tree but would the radxa aic8800 drivers fix the WiFi? Apparently they work with kernel 7 though I haven't verified this. Изменено 2 сентября пользователем WINEDS Maybe, but I would not count on it as a drop-in fix. The Radxa aic8800 tree is for that chip family, while the K2B v2.2 reports this SWT6621S setup, and in the working case above the missing bit was firmware naming, not just driver source. It is still worth testing if the module actually binds to the SDIO device and loads cleanly, but I would first check dmesg for the exact firmware names and chip IDs it asks for. If Radxa’s driver really builds on newer kernels, it may help with the “old 6.12 only” problem, but someone with v2.2 hardware will need to verify it. Classic SBC fun: same board name, surprise silicon lottery.
September 10Sep 10 @c0rnelius great work with the build system. Its up and running now. Like @falcon33I have V2.2. Only bluetooth is not working so far. I'll study his post from August 13. Edit BT working now using the sv6160lite.nvbin firmware @falcon33 linked to. Thanks! Edited September 10Sep 10 by WINEDS
September 12Sep 12 falcon33 писал: rev V2.2: Wi-Fi working, the NV firmware needs two symlinks I have a K2B rev V2.2 (DDR3, 4 GB) running Debian 13 with working Wi-Fi, and since this thread lists networking as the remaining blocker, here is what was missing. The DRAM side is already solved by pyavitz's kickpik2b-v2 target, so I will not repeat it. This is only about the Wi-Fi/BT firmware. WI-FI: THE DRIVER ASKS FOR FILENAMES NOBODY SHIPS The SWT6621S driver requests two files that are not in any firmware package, so request_firmware returns -2 and the interface never appears. Both requested names are aliases of files that ARE shipped: cd /lib/firmware ln -sfn SWT6621S_NV_SDIO_SHARE.bin SWT6621S_NV_SDIO.bin ln -sfn SWT6621S_SEEKWAVE_R00000.bin SEEKWAVE_NV_SWT6621S.bin That is the entire fix. wlan0 comes up after a reboot. Why SHARE and not ALONE is worth stating, because picking the wrong one here fails silently. The two files differ by exactly one byte, at offset 0x20: 01 vs 00. SWT6621S_NV_SDIO.ini documents what it means: ;[bit0]0-share,1-stand alone -> BT_ANTENNA_TYPE And the kernel independently reports bt_antenna=0 at boot on this board, i.e. a shared antenna. So SHARE is the match, confirmed twice, not guessed. BLUETOOTH: WORKS, BUT WITH A BORROWED IDENTITY sv6160lite.nvbin is shipped by nobody, not the image, not the builder, and not the driver sources. It does exist in armbian/firmware, added for the sibling board K3B, which uses the same SV6160LITE: curl -sfL -o /lib/firmware/sv6160lite.nvbin \ "https://raw.githubusercontent.com/armbian/firmware/master/seekwave/sv6160lite.kickpi%2Ck3b.nvbin" 48 bytes, magic NVDS. The controller then comes up: hci0: BD Address: 60:48:9C:41:28:F1 ACL MTU: 1021:6 SCO MTU: 255:4 UP RUNNING [SKWBT_INFO] btseekwave_download_nv / chip version:0x5302 Two caveats, please read before using this: The BD address comes from K3B's NV file. On one board that is harmless. If several people apply this, every one of those boards ends up with the SAME Bluetooth address, which will collide in the same room. I have not worked out how to generate a per-board NV. If anyone knows the format well enough, that is the missing piece. BR/EDR works, BLE does not. hcitool lescan fails with "Set scan parameters failed: Input/output error". Probably the K3B NV not matching this board exactly. I did not chase it because Bluetooth is not needed for my use case. WI-FI MAC IS NOT IN THE NV FILE Worth knowing since it looks like a firmware problem but is not: the NV file contains no MAC at all, just 220 bytes of register pairs, and the .ini has no mac or addr field. So the driver generates a random MAC per boot. If you need a stable one, pin it with a systemd .link file rather than expecting the firmware to supply it. ONE THING NOT TO DO Do NOT modprobe -r this driver to reload firmware. The SDIO device is non-removable and the module does not come back. It took a reboot to recover. Reboot instead. After spending enough time comparing firmware blobs, symlinks, register values, and driver logs, I usually need to look at something completely unrelated for a while https://bizzo-casinos.at/ bizzo casino is one example where the contrast is pretty extreme, with slots using different themes, reel layouts, visual effects, and mechanics, while live games have their own pace and presentation. Even the navigation between categories and tournament sections is a completely different kind of interface problem from digging through kernel messages. SETUP SUMMARY Board: KICKPI K2B rev V2.2 (label on the PCB), Allwinner H618, 4 GB DDR3 Built with pyavitz/debian-image-builder, make all board=kickpik2b-v2 Debian 13 trixie, kernel 6.12.103, u-boot 2026.01 Running from eMMC, stable under load, Wi-Fi and BR/EDR Bluetooth working The two firmware symlinks for Wi-Fi look like a clean workaround, especially with the shared-antenna detail confirmed from both the ini and kernel log. I’d still treat the Bluetooth part as “usable but not solved”, mainly because of the duplicated BD address and broken BLE. If someone has the Seekwave NV format documented, generating a board-specific sv6160lite.nvbin would be the next useful step. Also good warning about not unloading the SDIO driver — that one can save people from a confusing dead-end during testing. Edited September 12Sep 12 by wearylantern15
September 20Sep 20 @c0rnelius I have noticed the SWT6621S wifi module SPAMS dmesg extensively. I tried to suppress this by using conf files in /etc/modprobe.d without success. Changing /debian-image-builder/patches/wireless/vs6621s/vs6621s/swt6621s_wifi/Kconfig line 109 to default SWT6621S_LOG_ERROR suppresses most of the messages after initial boot. DUMP messages are still periodically appear in dmesg though. Commenting out line 347 in /debian-image-builder/patches/wireless/vs6621s/vs6621s/swt6621s_wifi/skw_core.c silences them but this is an ugly hack? Edited September 20Sep 20 by WINEDS
September 20Sep 20 OK I've never done that before. Might need some help with that. I'll do some research thanks.
September 20Sep 20 Really anyone here with a little patch and git know how could attempt to do a PR and add it to the legacy branch, which is still 6.12.y. Everything one would need is sitting in the deb builder and in armbian./build. Not sure Armbian would let you just add it to legacy though? Maybe. Why don't I? I don't want anything to do with supporting the REV2 beyond the efforts I've made. The REV1 was a curious buy, as I was already working on the BPI-M4-Zero and wanted another H618 to work on that had an ETH port. Also, it was only like $25 at the time.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.