On Tue, May 26, 2026 at 03:51:11PM -0600, Dave Polaschek wrote: > Nice! The Pocket Reform is now booting OpenBSD 7.9. The NVMe isn’t recognized > and audio doesn’t work, but otherwise it sounds like it’s in pretty good > shape. > > https://mastodon.social/@mntmn/116642900024741191 > > -DaveP >
Cool! I'm still waiting for my pocket 3588 upgrade board :) I was talking with minute on irc about trying to get the rk3588 video working during u-boot on the reform classic; apparently it's a little different than the pocket. I'll see how far they got. You can sorta get it working with a bunch of individual i2c read/write commands in uboot already :) -ml > On Wed, Apr 1, 2026, at 17:43, 0x4E0x650x6F wrote: > > Hello, > > > > Here are my findings after 2 weeks of dtb hammering. > > > > ## CM3588 NAS / RK3588 PCIe bring-up findings on OpenBSD > > > > I’ve been debugging NVMe instability on a FriendlyElec CM3588 NAS > > running OpenBSD/arm64. > > The board has 4 M.2 NVMe sockets. The main symptom is that one or more > > NVMe devices enumerate, > > but access to some paths stalls the system, especially during early > > probing or when softraid is enabled. > > > > ### Hardware / controller mapping > > > > From Linux DTS comments, board behavior, and pinctrl/reset mapping, the > > socket-to-controller mapping appears to be: > > > > | Socket | Controller | Address | Notes | > > | ------ | -----------: | ---------- | ------------------ | > > | 1 | controller 0 | `fe150000` | consistently works | > > | 2 | controller 2 | `fe170000` | problematic | > > | 3 | controller 1 | `fe160000` | consistently works | > > | 4 | controller 3 | `fe180000` | most problematic | > > > > The reset pin mapping extracted from the DTB is: > > > > | Socket | Controller | pinctrl group | reset pin | | > > | ------ | ---------- | ------------- | --------- | - | > > | 1 | `fe150000` | `pcie3x4-rst` | GPIO4_B6 | | > > | 2 | `fe170000` | `pcie2-0-rst` | GPIO4_B4 | | > > | 3 | `fe160000` | `pcie3x2-rst` | GPIO4_B3 | | > > | 4 | `fe180000` | `pcie2-1-rst` | GPIO4_A2 | | > > > > ### Strong observed pattern > > > > The stable controllers are: > > > > * `fe150000` (socket 1) > > * `fe160000` (socket 3) > > > > The unstable controllers are: > > > > * `fe170000` (socket 2) > > * `fe180000` (socket 4) > > > > So the problem clusters around the “lane 1” paths rather than affecting > > all four sockets equally. > > > > ### Firmware observations > > > > With the original bootloader, U-Boot identified as NanoPC-T6, which was > > clearly wrong for this board. > > > > With Armbian/mainline-style U-Boot, the board identity became correct > > and all 4 NVMe devices could be seen by U-Boot: > > > > * `nvme scan` > > * `nvme info` > > > > showed all four Samsung drives. > > > > This means the board and routing are capable of bringing up all four > > links under firmware. > > > > ### OpenBSD behavior > > > > Under OpenBSD: > > > > * sockets 1 and 3 are reliably usable > > * socket 2 can sometimes be made to enumerate depending on DT changes > > * socket 4 (`fe180000`) is the main failure path > > > > Typical failure mode for socket 4: > > > > * device enumerates > > * NVMe attaches > > * then the system stalls when the device is actually accessed > > * boot usually only succeeds with `disable softraid` > > > > That suggests “link up” is not the real problem anymore; the problem is > > what happens after enumeration. > > > > ### DT findings > > > > 1. `rockchip,pipe-grf` matters > > > > Adding `rockchip,pipe-grf` to controller nodes changed behavior > > significantly and made some previously failing paths work. > > That suggests the GRF hookup is functionally required, not optional. > > > > 2. `data-lanes` changes behavior globally > > > > Changing the PCIe3 PHY `data-lanes` from the Linux/mainline-style split > > ordering to a sequential ordering changed which sockets came up: > > > > * one ordering gave only sockets 1 and 3 (data-lanes = <1 3 2 4> ) > > * another ordering gave sockets 1, 2, and 3 (data-lanes = <1 2 3 4> ) > > * socket 4 remained the main outlier > > > > ``` > > usb5 at ohci0: USB revision 1.0 > > uhub5 at usb5 configuration 1 interface 0 "Generic OHCI root hub" rev > > 1.00/1.00 addr 1 > > usb6 at ohci1: USB revision 1.0 > > uhub6 at usb6 configuration 1 interface 0 "Generic OHCI root hub" rev > > 1.00/1.00 addr 1 > > pci0 at dwpcie0 > > ppb0 at pci0 dev 0 function 0 "Rockchip RK3588" rev 0x00 > > pci1 at ppb0 bus 49 > > nvme0 at pci1 dev 0 function 0 "Samsung PM9C1a" rev 0x00: msix, NVMe 2.0 > > nvme0: Samsung SSD 990 EVO Plus 4TB, firmware 2B2QKXG7, serial > > S7U9NU0YA03521K < nvme socket 4 > > scsibus0 at nvme0: 2 targets, initiator 0 > > sd0 at scsibus0 targ 1 lun 0: <NVMe, Samsung SSD 990, 2B2Q> > > sd0: 3815447MB, 512 bytes/sector, 7814037168 sectors > > pci2 at dwpcie1 > > ppb1 at pci2 dev 0 function 0 "Rockchip RK3588" rev 0x00 > > pci3 at ppb1 bus 65 > > rge0 at pci3 dev 0 function 0 "Realtek RTL8125" rev 0x05: msix: > > RTL8125B, address 00:00:00:00:00:00 > > pci4 at dwpcie2 > > ppb2 at pci4 dev 0 function 0 "Rockchip RK3588" rev 0x00 > > pci5 at ppb2 bus 1 > > nvme1 at pci5 dev 0 function 0 "Samsung PM9C1a" rev 0x00: msix, NVMe 2.0 > > nvme1: Samsung SSD 990 EVO Plus 4TB, firmware 2B2QKXG7, serial > > S7U9NU0YA09134R <- nvme socket 1 > > scsibus1 at nvme1: 2 targets, initiator 0 > > sd1 at scsibus1 targ 1 lun 0: <NVMe, Samsung SSD 990, 2B2Q> > > sd1: 3815447MB, 512 bytes/sector, 7814037168 sectors > > pci6 at dwpcie3 > > ppb3 at pci6 dev 0 function 0 "Rockchip RK3588" rev 0x00 > > pci7 at ppb3 bus 17 > > nvme2 at pci7 dev 0 function 0 "Samsung PM9C1a" rev 0x00: msix, NVMe 2.0 > > nvme2: Samsung SSD 990 EVO Plus 4TB, firmware 2B2QKXG7, serial > > S7U9NU0YA09309A <- nvme socket 3 > > scsibus2 at nvme2: 2 targets, initiator 0 > > sd2 at scsibus2 targ 1 lun 0: <NVMe, Samsung SSD 990, 2B2Q> > > sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors > > pci8 at dwpcie4 > > ppb4 at pci8 dev 0 function 0 "Rockchip RK3588" rev 0x00 > > pci9 at ppb4 bus 33 > > nvme3 at pci9 dev 0 function 0 "Samsung PM9C1a" rev 0x00: msix, NVMe 2.0 > > nvme3: Samsung SSD 990 EVO Plus 4TB, firmware 2B2QKXG7, serial > > S7U9NU0YA03531D <- nvme socket 2 > > scsibus3 at nvme3: 2 targets, initiator 0 > > sd3 at scsibus3 targ 1 lun 0: <NVMe, Samsung SSD 990, 2B2Q> > > sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors > > scsibus4 at sdmmc0: 2 targets, initiator 0 > > sd4 at scsibus4 targ 1 lun 0: <Apacer, SD8GB, 0030> removable > > sd4: 7384MB, 512 bytes/sector, 15122432 sectors > > scsibus5 at sdmmc1: 2 targets, initiator 0 > > sd5 at scsibus5 targ 1 lun 0: <SD/MMC, A3A561, 0000> > > sd5: 59000MB, 512 bytes/sector, 120832000 sectors > > vscsi0 at root > > scsibus6 at vscsi0: 256 targets > > ``` > > > > This suggests the `data-lanes` property is affecting the global PHY > > split/routing behavior, > > but OpenBSD is not "realizing" the intended RK3588 topology the same > > way Linux does, > > this might be the reason behind the diff results by re-ordering the > > values in the data-lanes. > > > > 3. OpenBSD DT pinctrl skeleton exists but some content is missing (Not > > sure the true effect of this) > > > > The corresponding PCIe pinctrl structure exists in the OpenBSD DTB, but > > parts of it appear empty, > > while vendor/Linux-style DTBs populate the pinctrl groups with actual > > pin definitions. > > That may contribute to incomplete sideband/reset setup. (?! unsure) > > > > ### Linux upstream findings that appear directly relevant > > > > Two Linux changes look highly relevant to this board: > > > > 1. CM3588 NAS regulators: > > Linux added a fix titled “Enable all PCIe regulators on CM3588 NAS” > > because some SSDs could > > still enumerate even with regulators not fully enabled, but then > > would hang on access. > > That seems matche the OpenBSD symptom very closely. > > > > 2. RK3588 PCIe bifurcation: > > Linux also fixed RK3588 PCIe3 PHY bifurcation programming, > > specifically the GRF programming behind the lane split handling. > > CM3588 NAS was explicitly called out as one of the boards affected > > by that issue. > > > > (https://github.com/torvalds/linux/commit/f8020dfb311d2b6cf657668792aaa5fa8863a7dd) > > > > ### Current interpretation > > > > At this point, my working theory is that the issue might not basic > > enumeration, > > but incomplete RK3588-specific runtime support for the problematic > > lane/controller paths, especially `fe180000`. > > > > The evidence now suggests: > > > > * firmware can bring up all 4 links > > * U-Boot can enumerate all 4 NVMe devices > > * OpenBSD still fails when using the socket-4 / `fe180000` path > > * regulator enable state and RK3588 PCIe3/GRF lane handling are likely > > involved > > * DT-only changes improve behavior, but do not fully solve it, its able > > to boot with > > softraid disabled and even get the sector and basic device info but > > after the boot is complet > > the device is "Non-functional" a simple disklable sd0 hangs.. > > > > ### Minimal reproducible summary > > > > * Board: FriendlyElec CM3588 NAS > > * SoC: RK3588 > > * 4 identical Samsung 990 EVO Plus 4TB NVMe drives > > * U-Boot: Armbian/mainline-style U-Boot with correct CM3588 NAS identity > > * Result: U-Boot sees all 4 NVMe devices > > * OpenBSD result: > > > > * sockets 1 and 3 usable > > * socket 2 variable depending on DT changes > > * socket 4 (`fe180000`) enumerates then destabilizes access / boot > > * system often only boots with `disable softraid` > > > > NOTE: > > I tested this with a decompliled version from openbsd ports and made a > > few adjustments, if > > i can provide it if any one is interested. > > > > ### Info request > > > > Any one has any sugestions / information that were i could understand > > the following: > > > > * RK3588 PCIe3 PHY lane split / bifurcation handling > > * GRF programming for lane-1 paths > > * regulator handling for CM3588 NAS M.2 slots > > * controller/runtime handling for `fe170000` / `fe180000` after > > link-up, not just at attach time. > > > > Best Regards > > Tiago > > > > On Saturday, 17 January 2026 at 01:53, Dave Polaschek > > <[email protected]> wrote: > > > >> On Fri, Jan 16, 2026, at 18:27, Mike Larkin wrote: > >> > 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.. > >> > >> Yeah, it's a portrait panel being used landscape, if nothing else. I was > >> planning to try and install 7.8 on the iMX version I have now, but after > >> having to send it to Germany for warranty repairs, and then fiddle with > >> the backplate to get WiFi that could stay connected long enough to do an > >> "apt update," I figure I'll just wait and see what I can find when the > >> RK3588 arrives. > >> > >> But I figure with this latest info, I've got at least one fewer roadblock > >> in the way, and I'd rather have it as an OpenBSD machine than Debian for a > >> few reasons, and it's a lot easier to switch OSes before I start using it > >> as a daily driver. > >> > >> >> -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 > >> > >>
