moved

I know this is going into the wrong section of the Rockchip forum but I don't see a parent category for anything like "Rockchip - Other". I can outline the issue in this thread, but I would rather have this post get moderated and get directed into the right spot to ask about specifically the Turing RK-1 or more generally "weird boards that have RK3588s that aren't already listed".

@Dravens Wayland compositing was broken on this Panthor/Mali-G610 stack. KWin-Wayland crashed when I tried it, and I never really looked into it any further. X11 is the session I ran with, and what the desktop hooks use. Nested Wayland works ok. I ship `cage`/`gamescope` running as a client inside the X11 desktop. This app gets a Wayland socket and PanVK Vulkan, no conflict with X11 alongside it (that's what my gaming/kiosk modes use). TLDR: Full Wayland has a known unfixed crash on this GPU stack. Checked the image, and the ophub kernel this build ships (6.1.141-rk3588-ophub) already has it compiled in (`binder.ko` in modules.builtin, so `CONFIG_ANDROID_BINDER_IPC=y`). So nothing needs rebuilding on my side. ashmem isn't needed either, Waydroid uses memfd since 1.2.1. Which means you can just try it: install `weston` + waydroid, run `weston --xwayland`, set `WAYLAND_DISPLAY`, and launch waydroid into it. Ready-made scripts: [waydroid-x11](https://github.com/mid-kid/waydroid-x11), [waywes](https://github.com/KSMaan45/waywes). Note it's Weston, not the cage/gamescope I ship. Warning on the GPU though: [waydroid#760](https://github.com/waydroid/waydroid/issues/760) is a Rock-5b (same RK3588/Mali-G610) that only boots with GPU disabled, [#776](https://github.com/waydroid/waydroid/issues/776) is "rockchip-rk3588 GPU unsupported", and [#2087](https://github.com/waydroid/waydroid/issues/2087) reports Panfrost/Panthor perf way below host. That's upstream Waydroid's passthrough, not something I can fix here. Expect software rendering... which could make other things run kinda rough.

@AurealNix - I realised I meant to say "NVMe is recognised now" so was getting a little ahead of myself so felt i should at least give the SSD a bit more exercise. cue: f3write/f3read on the entire 256GB + rinse/repeat a few times worked ok with nothing appearing in the dmesg to indicate it trips up etc. Regarding running rootfs on I'll see if I can squeeze that in (maybe Tuesda) as i will need to dd my sd and then image onto the NVMe and tweak /boot/boot.cmd /boot/orangepiEnv.txt accordingly - I can't just use your image on the NVMe as it starts at 2GB and then stretches out at first boot. If this is what you are looking to do/get-tested or maybe something else ? Also (low priority request), if you could add/install iproute2 onto the minimal image that would be handy! Cheers

@JamesCL One more thing, only if you're up for it (zero pressure, as always): I'd love to know how both drives hold up under a real data load — sustained writes, and whether anything corrupts. The clean tool for this is f3 (it writes known patterns and verifies them on read-back, so it catches even a single flipped bit). On the eMMC — keep it small. Your root fills the whole module (57 GB of 58), so there's little free space, and filling the live root filesystem completely would be a bad idea. A 5 GB run is plenty to prove integrity: sudo apt install f3 cd ~ && f3write --end-at=5 . # 5 × 1 GB files, watch the speed it reports f3read . # re-reads and verifies every bit sudo dmesg | grep -iE "mmc2|error|fail" rm ~/*.h2w # cleanup On the Intel NVMe — go big. That's where a long sustained run really tells us something. No need to format — f3 just writes files into whatever's mounted, so we can use the existing partition's free space (non-destructive): lsblk # find the NVMe partition (nvme0n1p1) sudo mount /dev/nvme0n1p1 /mnt # mount what's already there — no formatting df -h /mnt # how much free space? cd /mnt && sudo f3write --end-at=100 . && sudo f3read . # or drop --end-at to just fill the free space sudo dmesg | grep -iE "nvme|pcie|error|fail" sudo rm /mnt/*.h2w && cd ~ && sudo umount /mnt # cleanup (If there's less than 100 GB free, no problem — f3 fills whatever is available and stops; even 20-30 GB is a solid sustained run.) The --end-at numbers are just suggestions — check free space with df -h first and dial them down to whatever fits on each drive. A smaller run still proves integrity; it just exercises the drive for less time. The point is 0 corrupted sectors, not the size. What we're looking for: 0 corrupted sectors and a quiet dmesg on both. The speeds are a nice bonus — the eMMC at HS200 should read 100+ MB/s, and the NVMe is capped by the M.2 slot being PCIe 2.0 ×1, so ~350-400 MB/s is the by-design ceiling; if f3 reports that range with 0 corrupted, the link is running as well as this SoC allows. A clean eMMC run is the last box to tick before I write the "install to eMMC" guide around your method. @bickns you can try too.