On Fri, Jan 16, 2026 at 05:27:27PM -0700, Dave Polaschek wrote: > 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!
Not sure if the panel will work... IIRC patrick@ had to do some special things to get the panel working on the existing iMX machines.. > > -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
