Findings

Investigated 2026-09-20 against firmware CanMV-K230-V3P0_rtsmart_localnncase_v2.9.0_20260130 (LilyGO V1.3).

Hardware

Read out of schematic/T-Display K230_V1.0_NEW.pdf in the upstream repo.

U-Boot identifies the board as Model: kendryte k230 canmv v3.0.

Wi-Fi is broken in the shipped firmware

wifi scan returns an empty table. wifi ap <ssid> reports start ap successs! and brings w1 up with an IP, but the BSSID stays 00:00:00:00:00:00 at 0Mbps and no phone, laptop, or other receiver can see the SSID. The radio never transmits.

Root cause is in LilyGO’s BSP, at canmv_k230/src/rtsmart/rtsmart/kernel/bsp/maix3/drivers/extdrv/realtek/platform/rtwlan_bsp/rtwlan_bsp.c:

void Set_WLAN_Power_On(void)
{
}

void Set_WLAN_Power_Off(void)
{
}

The power-on hook is an empty stub, so GPIO45 / IO45_WIFI_EN is never asserted and the RTL8189 stays powered down. realtek_init() registers the SDIO driver and triggers a rescan, but with no chip powered the probe never fires. The RT-Thread WLAN framework registers w0/w1/sta/ap unconditionally, which is why they appear in ifconfig with nothing behind them.

Compounding this, in canmv_k230/src/rtsmart/rtsmart/kernel/bsp/maix3/drivers/Kconfig:

menuconfig RT_USING_REALTEK
    bool "Enable Realtek WiFi Driver"
    default n

The driver is off by default and the board defconfig does not enable it, so it is likely not compiled into the shipped image at all. The boot log contains no RTL8189 probe of any kind — the only SDIO device found is the TF card.

Both need fixing to get Wi-Fi under RT-Smart:

1. RT_USING_REALTEK=y plus REALTEK_SDIO_DEV1 (SDIO1 = mmc1@91581000)
2. Implement Set_WLAN_Power_On() using kd_pin_mode() / kd_pin_write() from drv_gpio.h to drive GPIO45 high, and call it from realtek_init() before the SDIO rescan

The driver itself is otherwise complete — wlan_lib/libwlan_v1_1.a, the SDIO glue in platform/sdio/, and correct SDIO IDs (0x024c/0xf179) are all present.

Under Linux this is likely moot: k230_canmv_v3_defconfig in kendryte/k230_linux_sdk sets BR2_PACKAGE_RTL8189FS=y.

No Ethernet

U-Boot reports Net: No ethernet found. The u0 interface visible in RT-Smart’s ifconfig (MAC 00:e0:4c:…, Realtek) is not the RJ45.

Linux support

kendryte/k230_linux_sdk (dev branch) has k230_canmv_v3_defconfig, matching this board’s U-Boot board name (k230_canmv_v3):

• Kernel: ruyisdk/linux-xuantie-kernel @ 7d4e1f444f461dbe3833bd99a4640e7b6c2cd529, defconfig k230
• BR2_PACKAGE_RTL8189FS=y — the Wi-Fi chip on this board
• DTS: canaan/k230-canmv-v3-lcd, canaan/k230-canmv-v3

Gaps for this board:

• The v3 reference DTS uses display-st7701-480x800.dtsi — an ST7701 480x800 LCD, not the RM69A10 AMOLED. However drivers/gpu/drm/panel/panel-canaan-universal.c is a 395-line generic DSI panel driver configured entirely from the device tree (init command sequence, videomode, reset/power GPIOs, lane count). So the AMOLED should be a new dtsi, not a new driver — transcribe the init sequence from LilyGO’s mpp/kernel/connector/src/rm69a10.c.
• No GT9895 / goodix_berlin in that kernel (it carries the older GT9xx goodix.c). GT9895 is in mainline since ~6.7, so this is a backport onto a 6.6-based tree.

Boot chain

BootROM -> U-Boot SPL (+ DDR PMU training firmware) -> U-Boot 2022.10 -> OpenSBI v0.9 -> payload

Canaan packages these with a custom header and compression (image: uboot load to 20000000 compress =1). For a NixOS port, treat stage 1 as a prebuilt binary input and let Nix own the kernel, initrd, and rootfs.

Shipped image layout (608 MB, MBR):

app.elf is the default boot application; the fast iteration loop is to build a new one and copy it onto part 2, no reflash needed.

Toolchain notes for the NixOS port

• QEMU 11.1.0 has a k230 machine (“RISC-V Board compatible with Kendryte K230 SDK”) — iterate without hardware.
• riscv64-linux is community-tier in nixpkgs with no binary cache; cross compile from x86_64-linux rather than emulating.
• Closest precedent is nixos-licheepi4a (T-Head Xuantie C910, vendor kernel).
• Compose Desktop on riscv64 is unproven but not ruled out. Skiko publishes 32 Maven artifacts and none are riscv64 (Linux natives are arm64/x64 only). However Skia itself supports riscv64 — SkiaSharp added riscv64 builds (PR #3192) and skia-python ships riscv64 wheels — so the gap is Skiko’s build matrix and JNI glue, not a Skia port. Needs a riscv64 OpenJDK (upstream since ~JDK 19) and SKIKO_RENDER_API=SOFTWARE, since the K230’s 2.5D GPU has no Mesa/Vulkan driver. The open question is whether software Skia + a JVM performs acceptably at 568x1232 in 1 GiB of RAM. Measure it on hardware before committing either way.
• Kotlin/Native has no riscv64 target at all, so a KMP-native shell is out regardless; any Kotlin path is Kotlin/JVM.

Corrections

Two claims above were wrong when first written. Recording the correction rather than quietly editing, because both were used to reason about other things.

Wi-Fi is on MMC0, not MMC1

Originally recorded as “RTL8189FTV on SDIO (MMC1, GPIO26-31)”. The two controllers were swapped. Three independent sources agree:

• The schematic ties WIFI_CLK/CMD/D0–D3 to the SoC’s dedicated MMC0 balls, not to IO26–31.
• k230_canmv_v3p0_defconfig sets CONFIG_REALTEK_SDIO_DEV0=y and CONFIG_SDCARD_ON_SDIO_DEV=1.
• U-Boot’s pinmux muxes IO54–59 as MMC1 with the comment // MMC1 -> TFCARD, and leaves IO26–31 as plain GPIO to the expansion header.

So Wi-Fi is &mmc_sd0 and the TF card is &mmc_sd1. This matters directly: the U-Boot environment loads the kernel from mmc ${mmc_boot_dev_num}:1 with mmc_boot_dev_num=1, which is consistent with the card being MMC1 and would have been confusing under the old, wrong mapping.

The Realtek driver IS compiled in

Originally recorded that RT_USING_REALTEK “defaults to n and the board defconfig does not enable it, so it is likely not compiled into the shipped image at all”. The Kconfig default is indeed n — but k230_canmv_v3p0_defconfig sets CONFIG_RT_USING_REALTEK=y. The driver is built.

That strengthens rather than weakens the diagnosis: the radio is silent with the driver present, so the empty Set_WLAN_Power_On() stub is the whole cause, not one of two.

Other device-tree findings

From docs/dts-evidence.md:

• There is no pinctrl in the Linux device tree at all. FPIOA muxing lives in U-Boot’s k230_canmv_v3p0.dts and is inherited. A board .dts cannot set pin functions.
• The upstream LT9611 HDMI node collides with our touch controller. k230-canmv-v3.dts gives it reset-gpios = <&gpio0_ports 24> and interrupts = <23 …> — GT9895’s RST and INT. The I2C addresses do not collide (0x3b vs 0x5d); the GPIOs do.
• panel-canaan-universal only pulses reset in probe(). The reset block in prepare() is commented out while unprepare() drives reset and enable low, so any modeset or suspend cycle leaves the panel held in reset. Likely a prerequisite patch rather than polish.
• The RM69A10 runs at ~39.6 Hz, not the 60 its enum name suggests — 39.6 MHz over 788×1268, consistent with the vendor’s own 475.2 Mbps/lane figure.