On Sat, Jan 17, 2026 at 12:12:12AM +0000, 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. >
great, congratulations! > 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 >
