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 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 >> >>
