LILYGO T-Display-K230 · hardware note · observed
On 2026‑09‑20 the board reached a root shell and answered questions. Five commands, and each one of them closes something this project had only been able to argue about from source.
the capture
Captured with tools/capture-boot.py over the CH342 bridge. These
are commands run on the board, not on the build host — which is
the entire point, and is why each one was chosen to be unfakeable somewhere
else.
[root@nixos:~]# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdcv_zicbom_zicboz_zicntr_zicsr_zifencei_zihpm_zba_zbb_zbs_svpbmt
mmu : sv39
uarch : thead,c908
mvendorid : 0x5b7
marchid : 0x8000000009140d00
mimpid : 0x50000
[root@nixos:~]# uname -a
Linux nixos 6.6.36 #1-NixOS SMP Tue Jan 1 00:00:00 UTC 1980 riscv64 GNU/Linux
[root@nixos:~]# cat /proc/cmdline
console=ttyS0,115200n8 root=fstab loglevel=4 lsm=landlock,yama,bpf init=/nix/store/2h0xrlf5n74fjjhxqd18y6vl55w4zyrr-nixos-system-nixos-26.11.20260919.20b1ddd/init
[root@nixos:~]# findmnt -no SOURCE,FSTYPE /
/dev/mmcblk1p2 ext4
[root@nixos:~]# nproc; free -m | head -2
1
total used free shared buff/cache available
Mem: 935 136 773 6 101 798
The raw capture, escape sequences and all, is committed at
docs/evidence/hardware-userspace.md. Elided above: the
bracketed‑paste sequences the shell emits around every prompt, and the
empty prompts between commands. No output line is changed.
line by line
virt machine this project boots
under is not a C908. Every claim below inherits this one.
bootargs.txt. Getting it there took a fix in the U‑Boot
environment — the whole story is in the
boot-chain note.
/ is actually mounted fromroot= on that command line, so the initrd resolved the device
through its own fstab and the NIXOS_SD label. Until this boot
every root mount had been done for us by the vendor fallback string; the
label path had never once been exercised.
the finding
The K230D has two C908 cores. Linux sees one. The first instinct — that something in our configuration switched SMP off — is wrong, and it is worth being precise about why, because the wrong diagnosis here costs a day.
CONFIG_SMP=y is set, so the kernel would happily bring up a second hart if one were described to it. Nothing describes one: k230.dtsi declares cpu@0 and stops. The K210 device trees in the same directory do declare a cpu@1, which is a good way to convince yourself K230 support has it too, and a wrong one.scope
A prompt is a prompt. Almost everything this board is for is still dark, and the milestone is worth nothing if it is allowed to imply otherwise.
The RM69A10 init sequence, the DSI timings and the reset polarity are all still transcription from vendor code. See the panel contract for what is written down and what is guessed.
The GT9895 now gets a chance to bind and the probe tooling exists, but nothing on the silicon map beyond the SD card and the console has been exercised on a running Linux.
The sensor binds and the thermal core is present, and between them they do exactly nothing. The thermal note is precise about the gap, and about what to measure first.
root=fstab resolved once. Generation selection does not
exist — the U‑Boot environment loads exactly one kernel by
literal filename — so a bad rebuild is still recovered with a card
reader, not a boot menu.
Transcript: docs/evidence/hardware-userspace.md, captured 2026-09-20 with tools/capture-boot.py over /dev/ttyACM0 at 115200 8N1. The boot chain that preceded it, failures included, is in docs/evidence/hardware-boot.txt.
Device-tree claims: ruyisdk/linux-xuantie-kernel @ 7d4e1f4 — arch/riscv/boot/dts/canaan/k230.dtsi, and the absence of a cpu@1 anywhere under arch/riscv/boot/dts/canaan/ that is not a K210 file.
House rule in force: observations outrank vendor source, and a datasheet grounds nothing. This page is the first one on this site written entirely from observations.