Thanks for sharing this info. I’m supposed to be receiving my RK3588 upgrade board for my MNT Pocket Reform in early February, and using this, maybe I’ll get it running OpenBSD sooner rather than later. Hope so!
-DaveP On Fri, Jan 16, 2026, at 17:12, 0x4E0x650x6F wrote: > Hello OpenBSD arm64 team, > > I wanted to share some notes from a successful OpenBSD/arm64 > bring-up on a FriendlyElec CM3588 Plus (NanoPC-T6, RK3588, 32 GB LPDDR5). > This took a bit of digging, and I think one detail in particular may > be useful to others working with Rockchip boards. > > Summary > OpenBSD 7.8 boots reliably from eMMC via U-Boot + EFI once disk layout and > bootloader offsets are handled correctly. > The system now boots cleanly with no SD card and no manual U-Boot interaction. > > Key finding (important) > On RK3588, U-Boot must be located at sector 64 (32 KiB offset). > If the EFI/MSDOS partition or GPT header is created too early on the disk, > it overwrites the expected U-Boot location. > > In that case: > > SPL runs > U-Boot is not found > The system falls back to recovery / mask-like behaviour > > The fix was: > > 1. Ensure the first partition starts *after* sector 64 > 2. Explicitly write U-Boot with: > > ``` > dd if=u-boot-rockchip.bin of=/dev/rsdXc bs=512 seek=64 conv=fsync > ``` > > Once this is done, the boot chain works reliably: > ROM → SPL → U-Boot → EFI → OpenBSD BOOTAA64.EFI → kernel. > > DTB > The DTB shipped in the OpenBSD install sets: > > ``` > rk3588-friendlyelec-cm3588-nas.dtb > ``` > > is the correct match for the CM3588 Plus. > Vendor DTS files differ between CM3588 and CM3588-Plus (rev06 vs rev09), > and using the wrong one causes subtle issues (USB, clocks, PHYs). > > eMMC interference: > I also ran into a hang around USB init (“ohci0 at mainbus0”). > This turned out not to be a USB driver issue, but leftover vendor > data on eMMC interfering with boot. > Zeroing the first 1 GiB of eMMC resolved it: > > ``` > dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=1024 > ``` > > After that, the installer proceeded normally. > > I’m happy to provide more detailed notes, disk layouts, > or testing if useful. > Thanks for the excellent arm64 support once the boot > geometry was understood, everything fell into place nicely. > > MY "hat" is officially off for the amazing work on this OS.... > > PS: > The dmesg was already sent I will try to tune some things that > I still haven't tested yet specifically the nvme sockets. > > Thanks Mike Larkin again for your input. > > Best regards, > Tiago > > > > Sent with Proton Mail secure email. > > On Thursday, 15 January 2026 at 12:15, 0x4E0x650x6F > <[email protected]> wrote: > >> Hi all, >> >> Thanks for the response here's where I'm at. >> >> Summary: >> CM3588-Plus (RK3588): OpenBSD 7.8 RAMDISK boots via u-boot-rk3588/EFI, >> stalls after ohci0 attach; vendor DT differs for Plus. >> >> Details: >> >> I’m testing OpenBSD/arm64 on a FriendlyElec CM3588-Plus (RK3588, 32GB). >> I can boot the OpenBSD 7.8 RAMDISK kernel via SD card using OpenBSD’s >> u-boot-rk3588 package and EFI (BOOTAA64.EFI), but the kernel consistently >> stalls during early device attach. >> >> Hardware >> Board: FriendlyElec CM3588-Plus >> SoC: RK3588 >> RAM: 32GB >> Serial console: UART2 (serial@feb50000), 1,500,000 8N1 (DT stdout-path uses >> serial2:1500000n8) >> Boot path / versions >> SD card: miniroot78.img (dd) >> U-Boot: u-boot-rk3588 (U-Boot 2025.07; boots via bootflow scan / efi_mgr) >> EFI loader: OpenBSD/arm64 BOOTAA64 1.22 >> Kernel: OpenBSD 7.8 (RAMDISK) #38 ... >> >> Boot log excerpt shows normal early init (PSCI/GIC/EFI, memory, SCMI, clock, >> GPIO, etc.) then USB host attach, then stall. >> >> Last lines printed: >> xhci0 at mainbus0, xHCI 1.10 >> usb0 at xhci0: USB revision 3.0 >> uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" ... >> ehci0 at mainbus0 >> usb1 at ehci0: USB revision 2.0 >> uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" ... >> ohci0 at mainbus0 >> >> After this: >> no further output on serial >> no panic/backtrace >> no watchdog reset >> >> UKC attempt >> I booted with UKC (boot -c) and issued: >> disable rkusbphy0 >> disable rkusbphy1 >> disable rkusbphy2 >> disable rkusbphy3 >> disable dwc3 >> disable usbdrd >> quit >> >> UKC produced no confirmation output, and the same devices still attached >> (rkusbphy0-3, xhci0/ehci0/ohci0) and stalled at the same point. >> >> DTB / board variant note || doubts >> >> OpenBSD provides rk3588-friendlyelec-cm3588-nas.dtb (dtb-6.14 / 7.8). >> However FriendlyElec’s vendor kernel uses different DT sources for CM3588 vs >> CM3588-Plus: >> CM3588: rk3588-nanopi6-rev09.dts >> CM3588-Plus: rk3588-nanopi6-rev06.dts >> >> Diffing OpenBSD cm3588-nas DT against the vendor CM3588-Plus DT shows >> substantial USB-related differences (DWC3 node structure/compatibles, >> clocks/clock-names, power-domain phandles, explicit reset lines, EHCI/OHCI >> companion+PHY wiring), so the shipped DTB may not match CM3588-Plus >> USB/PHY/power wiring. (????) >> >> I can provide full serial logs and the relevant DT diff hunks if needed. >> (after a very long or deal not sure if I bricked the device or not last >> night but I plan on keep hitting this thing until (hopefully until it runs). >> >> >> Best Regards >> Tiago. >> >> >> Sent with Proton Mail secure email. >> >> >> On Thursday, 8 January 2026 at 06:09, Mike Larkin [email protected] wrote: >> >> > On Wed, Jan 07, 2026 at 05:02:24PM +0000, 0x4E0x650x6F wrote: >> > >> > > Hi All, >> > > >> > > I finally decided to migrate to OpenBSD recently, >> > > and I was thinking if i could also use openbsd >> > > on CM3588 Plus (its a NAS board), uses rockchip >> > > rk3588. >> > > I noticed that a device with the same chip is >> > > supported I trying to find any documentation / help >> > > that could give me some guidance. >> > > >> > > I would be willing to assist to the best of my abilities, >> > > I have a device that is not in active use that, >> > > i could use as a test platform. >> > > >> > > Best Regards >> > > Tiago Carvalho. >> > >> > Looks like a generic cm3588 board, you could try the rock5a DTB or >> > something >> > similar. probably would get you reasonably far then tweak. >> > >> > unless you already have the DTB, say, from linux... >> > >> > -ml
